Was ist so schwer an P2P Lochung?

Question

Ich versuche mit einigen P2P-Netzwerk zu experimentieren. Nach einigen Nachforschungen ist eines der größten Hindernisse, die ich gelernt habe, "Was ist, wenn ein Client hinter einer NAT/Firewall ist", später entdeckte ich über Lochstanzen, aber es ist nicht immer garantiert zu arbeiten.

Soweit ein Ich verstehe, verstehe ich nicht, warum es scheitern könnte, das ist, was ich bisher weiß:

---

Basierend auf dem Diagramm oben, das ist, wie ich verstehe, wie eine erfolgreiche Verbindung kann festgestellt werden.

1. Alice schließt sich das Netzwerk (1) durch Verbindung mit einem Verzeichnis-Server erzeugt wird. Wenn das passiert, erstellt Alice NAT eine Zuordnung von ihrer öffentlichen IP zu ihrer lokalen IP.
2. Der Verzeichnisserver empfängt die Verbindung und speichert Alices öffentliche ip:port im Verzeichnis
3. Bob macht die gleiche (2), schließt sie das Netzwerk und veröffentlicht seine ip:port im Verzeichnis
4. Alice möchte mit bob kommunizieren. Also schaut sie Bob'sip:port aus dem Verzeichnis. (3)
5. Alice sendet Daten über Bobsip:port, die sie vom Server erhielt. (5)
6. Seit Bob auch eine Zuordnung hat von ip:port zu seinem lokalen ist ip:port, leitet der NAT einfach alle Daten auf Bob öffentliche ip:port seinen Computer empfangen.
7. Gleiche Werke für Alice

   ---

   Ich hoffe, dass ich in meiner Erklärung klar war, was ich verstehe. Meine Frage ist, was ist daran so schwer oder unzuverlässig? ich muss eindeutig etwas vermissen. Kannst du mir erklären, was es ist?

Answer 1

Ein Problem ist, dass die NAT-Mappings in Alice NAT-Server entweder nach einer festen Zeit oder nach einem Zeitraum der Inaktivität Timeout wird. Ein zweites mögliches Problem ist, dass der NAT-Server die Einschränkung machen könnte, dass Alices NAT-Zuordnung nur "gut" für von Alice hergestellte TCP-Verbindungen oder Verbindungen zwischen Alice und der ursprünglichen IP, an die sie "angeschlossen" ist. (Mit anderen Worten, direkte Kommunikation zwischen Alice & Bob kann blockiert werden.)

Und so weiter.

Das Problem ist, dass das Verhalten eines NAT-Servers in hohem Maße davon abhängt, wie die Verwaltung/Konfiguration der Organisation Entscheidungen. Viele dieser Entscheidungen können dazu führen, dass Ihr bestimmtes P2P-Nutzungsmuster nicht zuverlässig oder überhaupt nicht funktioniert.

---

Also dann ist meine ganze Idee über Lochen falsch?

Nein. Es bedeutet nur, dass es nicht immer funktioniert.

Answer 2

Firewalls sind in der Regel zustandsbehaftet. Bob (2), der die Kommunikation mit dem externen Verzeichnisserver herstellt, richtet in seinem NAT-Server eine Regel ein, die es Bob und dem Verzeichnisserver ermöglicht, zu kommunizieren. Wenn der NAT-Server Pakete von Alice sieht, werden sie abgelehnt/fallengelassen, weil Bob keine Kommunikation mit Alice hergestellt hat.

Answer 3

Möglicherweise ist das größte Problem in NAT lochpunching Mangel an Portkonsistenz. Damit Ihre Implementierung funktioniert, muss mindestens eine der beiden NATs diese unterstützen.

Port Konsistenz ist, wo die gleiche (local ip, local port) wird auf die gleiche (external ip, external port) unabhängig von der (destination ip, destination port) zugeordnet werden. Ohne dies ist der Port, den der Verzeichnisserver sieht, nicht hilfreich für den Client, da es nicht derselbe Port ist, den die Clients miteinander kommunizieren müssen.

(Beachten Sie, dass dies eine Voraussetzung ist schwächer als port preservation, wo external port == local port.)

Leider sind die meisten NATs sind einige Geschmack von Symmetric NAT für P2P-Kommunikation und tun nicht konsistente Portzuordnungen haben.

Answer 4

Zunächst einmal gibt es 2 Arten von Lochen 1.UDP Lochen 2.TCP Lochen

UDP Lochen Erfolgsquote liegt bei 82% TCP Lochen Erfolgsrate 64% ist Ich habe viele UDP-Lochenexperimente durchgeführt und sie waren meistens alle erfolgreich, aber nicht im Fall von TCP-Lochstanzen.

Der Grund für das Versagen von TCP-Lochung ist nur die Router-NAT-Tabelle. Ich werde versuchen, mein Bestes zu erklären:

Client 1 -> connect (client2) --Internet-- verbinden (client1) < - Client 2

Nun, wenn Client1 ** SYN-Paket * *** erreicht zu client2 und ** client2 ** SYN-Paket wurde nicht freigegeben **, das ROUTER von client2 kann 2 Dinge tun: 1. Senden RST-Paket zurück als Verbindung abgelehnt client1. 2. Paket sofort fallen lassen und keine Antwort an client1 senden.

In diesem Fall wird keine Verbindung hergestellt.

Ich kann nur eine Lösung vorschlagen, dass der Zeitunterschied zwischen Verbindungsaufruf von beiden Clients sehr gering sein sollte.Der Verbindungs ​​Anruf Unterschied sollte

TIP in Milli-Sekunden sein: Wenn Sie in lokalem Netzwerk, Ihre Firewall setzen deaktivieren

für ubuntu user: sudo ufw