Habe eine Frage. Ein Socket zum Server wurde vom Client aus geöffnet - im "Stream" können Daten in beide Richtungen gesendet werden. Wie ist das jetzt, wenn der Client hinter einer NAT sitzt? Kommen Bytes vom Server dann durch die NAT beim Client an? Auch ohne dass der Client vorher irgendwas durch den Stream anfragt? Ich kann die Situation grad nicht auf die Schnelle nachstellen. Aber ich denke es geht schon, wenn der Socket mal offen ist, oder? War doch scho immer so...? Weiß das jemand? Falls es eine Rolle spielt: C#, TcpListener & TcpClient Gruß, tsx
Die NAT Manipulation ist für CLient und Server komplett transparent (das ist ja schon seit Urzeiten bei jeder Internetverbindung so, die lokal virtuell von 192.168.x.y. ausgeht, aber beim Server als globale IP Adresse ankommt). Solange die Verbindung offen ist, wird eine sauber programmierte Infrastruktur (also die dazwischen liegenden Router) das mapping nicht anrühren. Probleme kannst Du dann kriegen, wenn mehrere zusammengehörige HTTP requests von verschiedenen mappings vorgenommen werden. Das hängt davon ab, wie strikt die Website damit umgeht.
Tim S. schrieb: > Kommen Bytes > vom Server dann durch die NAT beim Client an? Auch ohne dass der Client > vorher irgendwas durch den Stream anfragt? Warum sollte ein Server etwas senden ohne das ein Client etwas angefragt hat? Und woher sol NATer wissen an welchen Client er das Paket senden soll?
Max M. schrieb: > Warum sollte ein Server etwas senden ohne das ein Client etwas angefragt > hat? Beispiel hierfür ist IMAP IDLE. Da baut der Mail-Client eine Verbindung zur Server auf, hält die permanent offen und nichts passiert. Wenn der Server irgendwann einmal eine Mail für ihn hat, dann kommt plötzlich etwas rein.
A. K. schrieb: > Da baut der Mail-Client eine Verbindung > zur Server auf EBEND! Merkst du was? Und damit weiss der NATer auch bescheid.
Tim S. schrieb: > Ein Socket zum Server wurde vom Client aus geöffnet - im "Stream" können > Daten in beide Richtungen gesendet werden. > > Wie ist das jetzt, wenn der Client hinter einer NAT sitzt? Kommen Bytes > vom Server dann durch die NAT beim Client an? Auch ohne dass der Client > vorher irgendwas durch den Stream anfragt? Schauen wir auf ein SNAT, wie es jeder "Router" macht: Alice hat in ihrem Home-LAN die IP-Adresse 192.168.0.10 und möchte den Google-Server Bob mit der IP-Adresse 172.217.20.195 über ihren SNAT-Router Klaus ansprechen, der auf Alice' Computer als Standard-Gateway konfiguriert ist und seinerseits zwei IP-Adressen hat: die 192.168.0.254 in Alice' LAN, sowie im externen Internet die von Alice' Provider zugewiesene Adresse 80.128.1.1. Jetzt schickt Alice' Rechner ein Datenpaket an Bob; das Datenpaket hat als Quelladresse die von Alice' Computer und als Zieladresse jene von Bob. Aber die Adresse von Alice' Computer ist ja in ihrem LAN! Deswegen schreibt der NAT-Gateway Klaus die Quelladresse des Pakets um, ersetzt die Adresse von Alice' Computer durch seine eigene externe IP-Adresse, merkt sich diese Verbindung in seiner NAT-Tabelle und schickt das Paket weiter zu Bob. Bob bekommt jetzt ein Datenpaket mit Klaus' externer IP-Adresse als Quell- und seiner, Bobs, eigenen IP-Adresse als Zieladresse. Damit die Antwort ihren Rückweg findet, muß Bob die Quell- und Zieladressen des Pakets nun gegeneinander vertauschen; Bobs Antwortpaket hat nun als Quelladresse die externe IP-Adresse von Klaus und als Quelladresse die IP-Adresse von Bob. Dieses Antwortpaket von Bob kommt nun bei Klaus an. Wenn es vorher keine Verbindung gegeben hätte, würde Klaus das Paket einfach verwerfen, aber unser Klaus ist ja kein kleines Dummerchen und hat sich die Verbindung oben ja in seiner NAT-Tabelle gemerkt. Klaus erinnert sich daran, daß Alice ein Paket an Bob geschickt hatte und daß dieses an ihn adressierte, aber nicht für ihn bestimmte Paket wohl die Antwort auf Alice' Paket ist. Deswegen ersetzt Klaus jetzt die Zieladresse in Bobs Antwortpaket durch die gemerkte Quelladresse von Alice' Computer. Er leitet Bobs Paket dann in Alice' LAN weiter, wo Alice' Computer Bobs Antwort empfängt. Lange Rede, kurzer Sinn: solange der NAT-Gateway sich die Verbindung von Alice zu Bob gemerkt hat -- also nach dem Verbindungsaufbau -- kann die Verbindung als bestehend betrachtet werden. Wer dann zuerst Daten sendet, spielt dann keine Rolle mehr. Oder, anders gesagt: wenn es sich um einen Stream handelt, also um eine TCP-Verbindung, dann findet zum Aufbau ein Three-Way-Handshake statt, und dadurch kennt der NAT-Gateway die Verbindung. Bei UDP, das keinen Auf- und Abbau einer Verbindung, sondern nur einzelne Datenpakete kennt, kann das natürlich nicht funktionieren: da müßte Alice immer erst etwas zu Bob schicken, damit Klaus weiß, daß Alice mit Bob kommuniziert.
Sheeva P. schrieb: > Lange Rede, kurzer Sinn: solange der NAT-Gateway sich die Verbindung von > Alice zu Bob gemerkt hat -- also nach dem Verbindungsaufbau -- kann die > Verbindung als bestehend betrachtet werden. Achja, genau - da war ja was. Ich hatte nicht bedacht, dass die NAT sich genau diesen Fall merkt - bzw. wollte ich auf Nummer sicher gehen, bevor ich jetzt drauf loß programmiere... Sheeva P. schrieb: > Wer dann zuerst Daten sendet, spielt dann keine Rolle mehr. Genau das ist mein Ziel, dankeschön. tsx
:
Bearbeitet durch User
Max M. schrieb: > A. K. schrieb: >> Da baut der Mail-Client eine Verbindung >> zur Server auf > > EBEND! Merkst du was? Du hast offenbar die Frage nicht verstanden... > Und damit weiss der NATer auch bescheid. ... aber immerhin trotzdem die richtige Antwort gegeben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.