schau ruhig bei wikipedia mal die begriffe nach.

wenn du deinen rechnern feste ip-adressen gibst, brauchst du natürlich keinen DHCP-server. der ist hilfreich, wenn du öfter auf lanparties bist und zu hause dein profil neu konfigurieren musst (und z.b. keine zweite netzwerkkarte hast) - das ist aber nicht der primäre nutzen auch wenn du mal gäste hast (lanparty, einer mit laptop), dann können diese direkt loslegen. das ganze kann aber auch ein nachteil sein, etwa wenn jemand in dein WLAN eindringt - über den DHCP bekommt er sofort eine IP und muss nicht selbst den adressbereich und die belegten adressen herausfinden.

manche router ermöglichen es auch auch, nur hosts mit bestimmten MAC-adressen den zugang zu erlauben - möglicherweise auch in kombination mit DHCP, d.h. dass nur bekannte MAC-adressen reinkommen UND dynamisch die daten bekommen.

port forwarding sollte man aus sicherheitsgründen besser nur bei statischen ip-adressen zulassen, daher musst du da auch die genaue adresse eingeben. über die erkennung von MAC-adressen kann der DHCP-server aber hosts immer die selbe ip-adresse zuweisen, so dass port forwarding unter angabe einer festen adresse trotzdem auch im zusammenspiel mit DHCP funktionieren kann.

die lease time ist die zeit, nach der DHCP-daten verworfen und neu angefordert werden. in einem "stabilen" netz macht eine größere leasetime sinn. ändern sich einstellungen oft, z.b. am ersten abend oder generell auf einer lanparty, dann macht eine geringe (und ggf. stetig erhöhte) lease time sinn, um änderungen schnell automatisch an die clients weiterzugeben.

die "Static DNS" sowie WINS sind die einträge, die du auch z.b. unter windows machen kannst. solltest du leer lassen, zwei DNS-server sollte der router selbst dynamisch von deinem ISP beziehen.

UPnP erlaubt speziell in diesem zusammenhang u.a. das automatische freischalten von ports durch eine anwendung, so kann glaube ich azureus entsprechend selbst ports öffnen.

Ports definieren - ich sag mal vorsichtig JA.
Willkürlich - NEIN.

Athlon

das mit den ports ist so: es funktioniert, sagen wir im LAN, so wie du es dir wahrscheinlich denkst. der router nimmt aber den platz eines rechners im internet an und ist quasi für den rest im internet ein rechner, dessen bestimmte ports angesprochen werden sollen. der router selbst ist quasi (u.a.) ein multiplexer für mehrere rechner (oder eben auch nur einen). damit die daten an port 1234 aber an einem rechner ankommen, muss der router, der sie empfängt, sie auch weiterleiten. damit er weiß wohin, gibt es eben das port-forwarding.

wenn nun aber z.b. vier rechner im LAN hinter dem router sind, können nicht alle port 1234 verwenden. wenn diese rechner alle bswp. einen webserver betreiben, könnten sie das jeweils auf port 80 tun und sind darüber im LAN, eindeutig identifiziert durch die kombination aus ip-adresse und port, zu erreichen. damit alle vier webserver aber aus dem internet - über die eine ip-adresse und die eine range von ports des routers - zu erreichen sind, behilft man sich momentan mit NAT (network address translation). dabei werden nun vier - natürlich verschiedene - ports am router geöffnet und der datenverkehr je nach routerkonfiguration weitergereicht, also etwa 8001->pc1, 8002->pc2, etc. dabei ist es auch unerheblich, auf welchem port die webserver auf den rechnern laufen, hauptsache die zuordnungen nach dem schema port-am-router<->server-ip&server-port stimmen.

wenn rechner nun von innen nach außen wollen, etwa zum surfen, dann müssen gewöhnlich ja auch daten - in diesem fall die HTML-dokumente, bilder usw. - auch wieder zurück zum anfragenden rechner. dies löst der router mittels NAT über eine (weitere) interne tabelle. geht eine HTTP-anfrage von pc1 auf dessen lokalem port 12000 (vollkommen egal) an port 80 auf www.web.com raus, so versendet der router das paket auf einem von ihm gewählten (router-)lokalen port, z.b. 6789 an www.web.com:80. kommt nun vom webserver was zurück, entsprechend der anfrage also an port 6789, kann der router nachsehen, von welchem rechner im LAN ursprünglich die anfrage kam. andere rechner, die ins web wollen, werden dann von anderen router-ports rausgeschickt und wieder empfangen. so behält der router den überblick, was woher kam. wenn er nur alles an www.web.com:80 auf einem lokalen port weiterleitet, weiß er ja nicht, "wer was bestellt hat".

und wenn du nun von außen daten empfangen können willst, sei es instant-messaging, bittorrent oder sonstwas, dann musst du eben eine verknüpfung zwischen einem oder mehreren im internet sichtbaren router-port(s) und dem jeweiligen PC und dessen port(s) herstellen.

dass du in (besseren) programmen selbst festlegen kannst, auf welchen ports daten getauscht werden sollen, liegt eben daran, dass man meist durch firewalls, router o.ä. beschränkungen unterliegt, die man so manchmal umgehen kann. zudem macht es z.b. auch sinn, eine server-software wie SSH, VNC oder auch FTP aus sicherheitsgründen nicht auf dem standard-port laufen zu lassen, um scannern und sniffern nicht so leicht ins netz zu gehen.

alles klar?

Zitat von »Y0Gi«

... sowie WINS sind die einträge, die du auch z.b. unter windows machen kannst.

... da frag ich mich jetzt nur, was ein (IP-)Router mit einer WINS-Adresse am Hut hat.

Und falls es "nur" für den DHCP sein sollte - Was nutzt der WINS ohne Angabe des Knotentyps (und ggf. NetBios-Bereichskennung)?

mfg, Thomas

Zitat von »Tom«

... da frag ich mich jetzt nur, was ein (IP-)Router mit einer WINS-Adresse am Hut hat.

Und falls es "nur" für den DHCP sein sollte - Was nutzt der WINS ohne Angabe des Knotentyps (und ggf. NetBios-Bereichskennung)?

ich denke schon, dass das sinn macht. der DHCP gibt eben die IP des WINS zusammen mit der der gateways und DNS-server sowie der dem anfragenden host zugewiesenen ip-adresse und subnetzmaske einfach weiter, damit man nicht auf den DHCP verzichten muss, wenn man unbedingt nen WINS angegeben haben will.

übrigens hast du mich anders zitiert, als es gemeint war. die "einträge, die du auch z.b. unter windows machen kannst." bezieht sich neben WINS auf auf ip, maske, gateways und DNS-server.

Zitat von »Y0Gi«

ich denke schon, dass das sinn macht. der DHCP gibt eben die IP des WINS zusammen mit der der gateways und DNS-server sowie der dem anfragenden host zugewiesenen ip-adresse und subnetzmaske einfach weiter, damit man nicht auf den DHCP verzichten muss, wenn man unbedingt nen WINS angegeben haben will.

Ja, wenn man ein uraltes NT4/LanManager2(OS/2)/Samba1 -Netz betreibt, mag das in dieser (rudimentären) Form Sinn machen.
Wer heute einen WINS betreibt, kann da auch gleich noch einen (caching) DNS und einen "echten" DHCP drauf machen.

BTW: Ich mache Alles per DHCP, weil ich garkeine Lust habe wegen einer kleinen Routen-Änderung "von PC zu PC zu hüpfen".
Und wer eine feste IP-Adresse braucht, bekommt eine Reservierung.
Solange man mit den Grundfunktionen (Host-Adresse, DNS, Gateway) leben kann, sind die Mini-DHCPs durchaus empfehlenswert.

Zitat

übrigens hast du mich anders zitiert, als es gemeint war. die "einträge, die du auch z.b. unter windows machen kannst." bezieht sich neben WINS auf auf ip, maske, gateways und DNS-server.

Das war nicht meine Absicht.
Wenn Du die WINS-Einstellungen unter NT 5.x genauer betrachtest, siehst Du dort noch ein paar Radio-Buttons (NetBIOS over TCP/IP) - die dazugehörigen Einstellungen fehlen hier.
Bevor man irgendwas "nur zur Hälfte" macht, sollte man es besser weglassen. Dieser Eintrag ist einfach nur Featuritis, und verlängert nur die Liste unsinniger Router-Gimmicks.

mfg, Thomas

P.S.: Nochwas zu diesem Thread:
UPnP wäre die allererste Funktion, die abstellen würde - das gilt auch für den Host-Prozess in WindowsXP.

Nachtrag - an die Schnell-Klicker: [glow=red,2,300]nicht den PnP-Service abstellen![/glow]