In Bezug auf NAT-Analyse

Ich habe den Stun-Client von http://www.stunprotocol.org/ heruntergeladen und versucht, den NAT-Typ mit dem Befehl stunclient --mode full stun.stunprotocol.org --verbosity 9 herauszufinden und ich habe die folgende Antwort.In Bezug auf NAT-Analyse

config.fBehaviorTest = true 
config.fFilteringTest = true 
config.timeoutSeconds = 0 
config.uMaxAttempts = 0 
config.addrServer = 52.86.10.164:3478 
socketconfig.addrLocal = 0.0.0.0:0 
Sending message to 52.86.10.164:3478 
Got response (68 bytes) from 52.86.10.164:3478 on inter 
Other address is 52.201.75.212:3479 

Sending message to 52.201.75.212:3478 
Got response (68 bytes) from 52.201.75.212:3478 on inte 
Sending message to 52.201.75.212:3479 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.201.75.212:3479 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Binding test: success 
Local address: 10.64.60.58:58841 
Mapped address: 125.19.34.60:24604 
Behavior test: fail 
Filtering test: success 
Nat filtering: Address and Port Dependent Filtering

Ich arbeite in einem Unternehmen und deshalb aus Sicherheitsgründen, NAT-Typ „Adresse und Port abhängige Filterung“ scheint möglich.

Aber als ein allgemeines Phänomen scheint mir, dass für Peer-to-Peer-Verbindungen, die meiste Zeit, NAT-Typ wird "Address und Port Dependent Filtering" und daher wiederum Server für jede Medienkommunikation erforderlich ist.

Wie auch immer, bei Google nach webrtc suchen, zeigt es, dass 90% der Peer-to-Peer-Kommunikation durch Stun-Server selbst etabliert (durch Lochung etc.). Dies bedeutet, dass der NAT-Typ in diesem Fall zum Herstellen der Verbindung vollständig unterstützt wird.

Haben Experten eine Meinung zu den NAT-Analysen, die für die Peer-to-Peer-Kommunikation zu berücksichtigen sind?

Quelle

2016-09-20 ashishgupta_mca

Das Stunclient-Programm könnte ein bisschen mehr Protokollierung verwenden, um anzuzeigen, was es tut. Da ich etwas über den Code weiß, hier ist, wie ich es interpretiere.

Stunclient führt zwei verschiedene Tests durch. Die ersten sind die "Mapping-Verhalten" -Tests, die am wichtigsten sind, um zu verstehen, wie sich Ihre NAT/Firewall auf die P2P-Konnektivität auswirkt. Der andere Satz sind die "Filtertests", die ein Indikator dafür sind, wie "offen" Ihr NAT in Bezug auf den Empfang von Verkehr von anderen IP/Port-Kombinationen ist.

Ihr Verhaltenstest "fehlgeschlagen". Was dies wahrscheinlich bedeutet, basiert auf Ihrer Protokollausgabe:

Test 1: Wählen Sie in diesem Fall einen zufälligen Port, 58841. Führen Sie von diesem lokalen Port aus einen grundlegenden Bindungstest mit stun.stunprotocol.org:3478 durch. Dies ist der Punkt, an dem der Client eine Antwort erhält, bei der der Server die zugeordnete Adresse angibt (125.19.34.60:24604) und die Stun-IP für nachfolgende Verhaltens- und Filterungstests bei 52.201.75.212 liegt.

Test 2: Derselbe lokale Port, 58851. Senden Sie eine Bindungsanforderung an den alternativen IP- und primären Port (52.201.75.212:3478). In Ihrem Fall scheint es, dass die Antwort, die zurückkam, wahrscheinlich eine andere IP oder ein anderer Port war. Und in diesem Fall war "Test 3" erforderlich.

Test 3: Derselbe lokale Port, 58851. Senden Sie eine Bindungsanforderung an den alternativen IP- und alternativen Port (52.201.75.212:3479), damit zwischen "adressabhängigen" und "adress- und portabhängigen Mappings" unterschieden werden kann. Und das ist der interessante Teil - Sie haben nie eine Antwort bekommen. Obwohl mit beiden IP-Adressen an Port 3478 kommuniziert werden konnte, kam der Test als gescheitert zurück.

Könnte eine von zwei Dinge:

a) Ihre NAT/Firewall ist eigentlich offen für Port 3478, sondern 3479. dies nicht von der Kommandozeile

stunclient 52.201.75.212 3479

Und wenn das erkennen es gelingt, eine gemappte Adresse zu erhalten, dann sofort Folgendes tun:

Versuchen Sie andere Kombinationen dieser beiden IP-Adresse und Anschlüsse.Das resultierende Verhalten könnte Folgendes bedeuten:

b) Ihre NAT/Firewall lehnt Port-Map ab, wenn sowohl die IP-Adresse als auch der Port sich geändert haben. Das bedeutet, dass Ihre Netzwerkumgebung noch restriktiver ist als ein "Adress- und portabhängiges Mapping" -NAT. Häufiger bekannt als symmetrisches NAT.

Wie für die Filterungstests ignorieren Sie einfach dieses Ergebnis. Die Filterungstests versuchen zu erkennen, ob Sie an einen ip: port senden können, aber von einer anderen IP oder einem anderen Port empfangen. 99% der Zeit verbieten NATs dies. Daher führt das Ergebnis fast immer zu "Adress- und Port-abhängiger Filterung". Das Ergebnis des Filterungstests ist nicht sehr bezeichnend dafür, wie Ihr NAT in der P2P-Konnektivität erfolgreich sein wird.

Und nur weil Ihr Unternehmensnetzwerk sehr restriktiv ist, heißt das nicht, dass Sie nicht mit einem Peer in einem anderen Netzwerk kommunizieren können. Wenn er ein NAT mit Endpoint Independent Mapping hat, dann gibt es immer noch eine Chance, dass die P2P-Konnektivität erfolgreich ist.

Ich habe in den letzten Jahren nicht mit NAT-Trends Schritt gehalten, aber 80-90% der Verbindungen, die mit STUN allein Erfolg haben, klingen richtig. Der Rest benötigt eine Relais-Lösung wie TURN.

Quelle

2016-09-21 02:52:32 selbie

Danke Selbie. Aber wie kann der Stunserver "52.201.75.212" von seinem Port "3479" antworten, bis er darauf hört? Wenn einer der Netzwerk-NAT-Typen ein symmetrisches Netzwerk und der andere Netzwerk-NAT-Typ eine endpunktunabhängige Zuordnung ist, ist weiterhin die P2P-Verbindung möglich. Das ist es, was du von deiner Leitung meinst "es bedeutet nicht, dass es dir unmöglich ist, mit einem Peer in einem anderen Netzwerk zu kommunizieren. Wenn er ein besser erzogenes NAT mit endpunktunabhängigem Mapping hat, gibt es immer noch eine Chance P2P-Konnektivität wird erfolgreich sein" .. –

Der STUN-Server überwacht immer beide Ports (3478 und 3479) und beide IP-Adressen. Da das symmetrische NAT (z. B. Ihr Unternehmensnetzwerk) keine vorhersehbare Portzuordnung aufweist, ist es unsicher, ob die von STUN erhaltene Adresse/der Port mit der IP-Adresse des zu verbindenden Peers funktioniert. Das Peer-NAT muss nicht nur Endpunkt Ind sein, sondern die Filterung muss möglicherweise "Adressabhängig" oder besser sein. – selbie

Ich stelle mir vor, Sie wollen zwischen p2p in allen möglichen Szenarien (einschließlich Symmetrie NAT) kommunizieren. Mein Vorschlag: Versuchen Sie es mit WebRTC und verwenden Sie Stun und schalten Sie die Server in Ice Server-Liste. Dadurch erhalten Sie eine große Auswahl an ICE-Kandidaten und webRTC kümmert sich um die Verbindung zu den besten Kandidaten. Dies sollte Sie von Ihrem NAT-Typ Bedenken speichern.

Quelle

2016-12-26 08:42:49

In Bezug auf NAT-Analyse

Antwort

Verwandte Themen