Suchergebnisse

Das Problem ist SPI. Anders ausgedrückt gehört nicht nur das Port-Mapping zu einer TCP-Verbindung über ein NAT, sondern auch die jeweils zugehörige IP-Adresse. Daher gilt: Zitat von Wikipedia: „All TCP NAT traversal and Hole Punching techniques have to solve the port prediction problem.“ Die Serververbindung dient nur dem Austausch der Verbindungsdaten. Dadurch kennen Peer A und B die öffentliche IP-Adresse des jeweils anderen. Gegeben seien also die Peers A und B sowie der Server S. S kennt jew…

connect() bzw. das .NET-Pendant Socket.Connect() funktioniert immer. Manchmal bekommt es jedoch keine Antwort von der Gegenstelle - dann bleibt es beim SYN, dem ersten Schritt des Handshakes --> Ziel erreicht, SYN gesendet und das lokale NAT ist offen. Der Trick ist, den Socket erneut zu verwenden, bevor der Timeout für das Portmapping im NAT abläuft, der die halboffene Verbindung wieder einkassieren würde.

Beim Öffnen einer Verbindung entsteht ein lokaler Endpunkt, ein Paar aus IP-Adresse und Port. Auf diesem Port musst du lauschen. Verbinde z.B. zu 1.2.3.4:80 (Remote-Endpunkt). Dein Rechner (mit IP w.x.y.z) belegt dabei einen zufälligen Port, z.B. 2304. Der lokale Endpunkt ist dann w.x.y.z:2304. Lade mal eine Webseite und rufe in einer Konsole netstat -an auf, dann siehst du, was ich meine: Quellcode (2 Zeilen) Edit: Hier ein Beispiel: VB.NET-Quellcode (26 Zeilen)

Zitat von MSDN: „If you are using a connection-oriented protocol and did not call Bind before calling Connect, the underlying service provider will assign the local network address and port number.“ Heißt im Umkehrschluss: Du kannst den lokalen Port festlegen. Das nützt dir aber nichts, weil du den NAT-Port trotzdem nicht kennst. NAT ersetzt nicht nur die IP, sondern auch den Port. Das ist übrigens der Grund, warum Menschen, die das OSI-Modell verstehen, NAT nicht mögen: Es greift unberechtigter…