Anwendung von NAT Traversal zur Verbindung von Nutzern im passiven Modus

Dieser Artikel ist eine freie Übersetzung eines der Einträge im Blog der Entwickler von DC++.

Mit Erlaubnis des Autors (auch zur Veranschaulichung und aus Interesse) habe ich ihn mit Links versehen und um einige persönliche Erkenntnisse ergänzt.

Einführung

Derzeit muss mindestens ein Benutzer der beiden verbundenen Teilnehmer im aktiven Modus sein. Der "NAT-Umgehungsmechanismus" ist hilfreich, wenn der aktive Modus bei keiner der Parteien eingerichtet ist. Dies geschieht normalerweise aufgrund von Einschränkungen beim eingehenden Verbindungen durch eine Firewall oder ein NAT-Gerät.

Wenn beide Clients im aktiven Modus

sendet der initiierende Client einen Befehl mit seiner eigenen IP-Adresse und Port $ConnectToMe an den anderen Client. Mit diesen Informationen stellt der empfangende Client eine Verbindung zum Initiator her.

Falls einer der Clients im passiven Modus

sendet der passive Client über den Hub den Befehl A $RevConnectToMe an den aktiven Clienten , der dann mit dem Befehl $ConnectToMe antwortet. BAls Server

funktioniert hier der DC-Hub S Wenn beide Clients im passiven Modus am

ADC-Hub verbunden sind, während sie sich hinter unterschiedlichen NATs befinden

sind die Clients mit dem Hub verbunden A und B So sieht die Verbindung mit dem Hub aus der Sicht des Clients aus S.

Der Hub akzeptiert Verbindungen am Port 1511. Der Client A

stellt aus seinem privaten Netzwerk aus einen ausgehenden Verbindung über Port 50758 her. Der Hub sieht die Adresse des NAT-Geräts, arbeitet mit ihm und leitet den Clients entsprechend ihren IDs weiter. A sendet an den Server

den Kunden zurückzuführen sind, nicht verfügbar ist. A eine Nachricht mit der Bitte, eine Verbindung zu einem Client herzustellen S Da er sich ebenfalls im passiven Modus befindet, muss der Client B.

Hub: [Outgoing][178.79.159.147:1511] DRCM AAAA BBBB ADCS/0.10 1649612991

, der diesen Befehl erhält, seinen privaten Port mitteilen, der zur Verbindung mit dem Hub über NAT verwendet wird. BNach Erhalt dieser Informationen versucht der Client

Hub: [Incoming][178.79.159.147:1511] DNAT BBBB AAAA ADCS/0.10 59566 1649612991

sofort, eine Verbindung zum anderen Client herzustellen A und gibt seinen eigenen privaten Port bekannt. B Was ist das Interessante daran? Es geht darum, den Endpunkt derselben Verbindung zu verschieben, indem eine neue Verbindung zu einer öffentlichen Adresse über einen bereits verwendeten privaten Port hergestellt wird.

Hub:		[Outgoing][178.79.159.147:1511]	 	D<b>RNT</b> AAAA BBBB ADCS/0.10 <b>50758</b> 1649612991

Bingo!

Natürlich hat das NAT des Clients

voll das Recht, die erste Verbindungsanfrage des Clients abzulehnen B , aber bereits die eigene Anfrage wird in das "Loch" gelenkt, das durch diese Verbindung geschaffen wird, und die Verbindung wird tatsächlich hergestellt. AEine Abbildung, die zu dem gesamten Prozess passt, mit der Einschränkung, dass

Eine Illustration, die zu dem gesamten Prozess passt, mit dem Vorbehalt, dass wird das Protokoll verwendet keine öffentlichen Ports, die von der Sitzung geöffnet werden NAT‒S, sowie private Adressen.

Epilog

Zum Zeitpunkt des Schreibens des (ursprünglichen) Artikels arbeiten etwa die Hälfte der DC-Clients im passiven Modus. Das bedeutet, dass ein Viertel aller möglichen Verbindungen nicht hergestellt werden kann.

In Zukunft wird DC++ in der Lage sein, NAT zu 'umgehen', indem es bestehende Verbindungen nutzt A‒S und B‒S zur Herstellung einer direkten Client-zu-Client-Verbindung, selbst wenn A und B sie sich im passiven Modus befinden.

Quelle: habr.com