Hi Jüki, net verzagen, Netzwerkprotokolle sind nicht wirklich die leichteste Kost. Ich versuche erst einmal so gut ich es kann deine Einzelfragen abzuarbeiten:
-
- Nein, für eine Verbindung werden nicht immer sowohl UDP als auch TCP benötigt. Es gibt Protokolle, die entweder das eine, oder das andere oder auch beides benutzen, je nachdem, wie sie implementiert wurden. HTTP (Webserver) z.B. arbeitet nur über TCP, Streamingprotokolle vornehmlich über UDP, Messagingprotokolle meist über sowohl TCP als auch UDP.
-
- Zu den Ports, ja und nein. Dein PC initiiert wirklich von einem Port jenseits der 1024 eine Verbindung an den Server mit Zielport 80. Was dann passiert hängt stark vom Protokoll ab, bleiben wir einmal bei HTTP. Der Server handelt dann mit deinem Rechner eine Verbindung aus und verweist deinen Rechner an einen (bzw mehrere) hohe Ports des Servers selbst. Der Server von sich aus baut bei HTTP keine Verbindungen zu deinem Rechner auf, ansonsten gäbe es bei HTTP Probleme mit NAT worauf ich später noch zurück komme
-
- Die Ports 21, 25, 110, etc mußt Du NICHT frei geben, es sei denn Du würdest selbst einen entsprechenden Server betreiben. Du willst ja von innen nach außen eine Verbindung zu diesen Servern aufbauen, damit hat NAT keine Probleme, nur wenn jemand von außen nach innen diese Server bei Dir erreichen wollte gäbe es Probleme und Du müsstest freigeben, da komme ich aber später auch nochmal drauf zurück
-
- Zu ICQ kann ich Dir aus dem Stehgreif nichts detailliertes sagen, außer das es sich nicht um ein Trigger- Kommunikationsport-Problem handelt, so ein Problem kennt NAT nicht. Es geht bei Messagingprotokollen darum, daß die entsprechenden Server von sich aus eine Verbindung zu deinem Rechner aufbauen wollen/müssen für bestimmte Funktionen, Du in diesem Fall also selbst eine Art Server anbietest.
-
- Wie Ports zugeteilt werden unterscheidet sich danach, was für einen Dienst Du implementierst. Wenn Du z.B. einen Webserver selbst programmierst, dann bist Du mehr oder weniger festgelegt auf Port 80 oder 8080, da diese Ports von einem Gremium für diese weit verbreiteten Dienste fest gelegt wurden um verbindliche Rahmenbedingungen für die Kommunikation zu schaffen. Programmierst Du eine eigene Anwendung, die es noch nicht gibt, so hast Du eigentlich die freie Wahl welchen Port Du nimmst, solltest aber tunlichst keinen Port nehmen, der schon durch verbreitete Protokolle belegt ist, ergo fallen die ersten 1024 normalerweise weg.
-
- Lehrgänge in denen so etwas unterrichtet wird sind meist wesentlich teurer bezahlt und man darf sich anschließend mit netten Titeln und Zertifikaten schmücken und 50% höhere Beratungshonorare verlangen, also nicht unbedingt etwas, daß man unbedingt braucht, wenn man was ehrliches gelernt hat ;o).
-
So, jetzt aber noch einmal zurück zu ein paar Grundlagen:
Wann muß man bei NAT einen Port freigeben?
Generell immer dann, wenn jemand von außen versucht eine Verbindung zu deinem Rechner aufzubauen, ohne daß diese vorher von innen gestartet wurde.
Hierzu jetzt einen Ausflug wie NAT (Hier speziell SourceNAT (SNAT) noch spezieller masquerading) funktioniert.
Dein Rechner will einen Webserver kontaktieren und sendet im Normalfall (direkte Verbindung ins Netz) ein TCP-Paket von einem hohen Port aus an den Webserver mit Port 80 als Zieladresse. In der Regel nimmt der Server das Paket an und handelt dann mit deinem Rechner eine Verbindung aus. Dabei verweist der Server für die Kommunikation deinen Rechner an einen hohen Port des Servers, um Port 80 für weitere Verbindungsanfragen frei zu machen, da sonst ein Webserver mit vielen Anfragen schnell einen verstopften Port 80 hätte. Dein Client erkennt die ausgehandelte Adresse und die weitere Kommunikation läuft entsprechend über die "Nebenports".
Bei NAT funktioniert das ganze ähnlich, außer daß der Router dazwischen die interne IP des Clients und den von ihm angegebenen Port mit seiner eigenen IP (die des Routers zum Internet) und einem anderen Port ersetzt. Diese Übersetzung merkt er sich in einer Tabelle. Kommen nun Antwortpakete, so erkennt er anhand der Verbindungsdaten durch einen Blick in seine Tabelle, an welchen Rechner im LAN er dieses Paket senden muß. Er erkennt auch die ausgehandelten Ports mit dem Server für den Datenaustausch und berücksichtigt diese intelligent, im Gegensatz zu einem dummen Portfilter, welcher solche einen automatismus nicht kennt. Dies ist das, was man bei Firewalls als "Statefull Packet Inspection" kennt. Die Pakete werden mit Kenntnis des Protokolles nicht nur auf IP-Ebene inspiziert.
Anders sieht dies nun aus bei Protokollen, bei denen ein Server (oder andere Clients) wiederum nach aushandeln einer Verbindung selbsttätig Verbindungen zu deinem Rechner aufbauen will, wie z.B. bei vielen Messagingprotokollen. Wenn hier der Server eine Verbindung öffnen will und diese erreicht den NAT-Router, so schaut er wie üblich in seine NAT-Tabelle, findet aber keine bestehende Übersetzung, zu der das Paket passt. Er weiß also nicht, an welchen Rechner im LAN er dieses Paket schicken soll, da er das Kommunikationsprotokoll nicht kennt und deswegen diesen "Rückkanal" nicht als verwandte (RELATED) Verbindung behandeln kann. Er kennt zwar die Mechanismen von IP, TCP und UDP, nicht jedoch die Protokolleigenheiten von ICQ, eMule, Kazaa und die damit zusammenhängenden Verbindungswirrwarr. Dies muß man ihm mit einem Portmapping abnehmen.
Das ist also der Fall, wann Portmapping oder virtual Server nötig ist: Wenn eine Verbindung von außen zu deinem Rechner aufgebaut werden muß, die nicht zu einer bestehenden Verbindung passt.
Noch eine Anmerkung: Was eventuell ein Problem beim Verständnis ist, sind die verschiedenen Protokollebenen und deren Interaktion. So ist IP ein Protokoll, TCP ein Protokoll, UDP ein Protokoll, ebenso HTTP FTP, etc. Diese arbeiten aber nicht unabhängig, sondern die höheren Protokolle werden über die niederen Protokolle übertragen, sozusagen als Nutzlast. Das IP-Protokoll trägt TCP und UDP, TCP und UDP wiederum tragen z.B. HTTP, welche selbst wiederum auch noch andere Protokolle tragen können. Es ist wie bei diesen russischen Puppen wo eine problemlos mehrere andere enthalten kann und diese immer eine nach der anderen ausgepackt werden.
Ein Gerät auf dem Weg dieser Pakete kennt meist nur die unteren und deren mechanismen (IP, TCP, UDP) nicht jedoch die Eigenarten der darin transportierten Protolle.
xafford
jueki
Andreas42
Tyrfing
