NAT und Konnektivität

Wie der Agent einen direkten Pfad durch NAT findet, warum manche Tunnel auf einem Relay bleiben und was Sie in diesem Fall ändern können.

Fast jede Maschine befindet sich hinter einem NAT und hat keinen offenen eingehenden Port. Zwei solche Maschinen können trotzdem direkt miteinander kommunizieren, weil beide im selben Moment eine Verbindung nach außen aufbauen und ihre NATs das Paket der Gegenseite jeweils für die Antwort auf ein bereits gesendetes Paket halten. Dieses Verfahren heißt Hole Punching, und ICE automatisiert es.

Der Tunnel wartet nicht auf ICE. Er startet über ein SXAccess-Relay und wechselt auf einen direkten Pfad, sobald einer gefunden wird.

Wie ein Tunnel ausgehandelt wird

1
Angebote über Discovery austauschen
Die beiden Agenten tauschen über den Discovery-Dienst ein Angebot und eine Antwort aus, jeweils mit dem Schlüssel des anderen versiegelt. Discovery leitet Nachrichten weiter, die er nicht lesen kann.
2
Über das Relay starten
Der Tunnel wird sofort über ein SXAccess-Relay aufgebaut, sodass Daten fließen, während die Suche nach einem direkten Pfad weiterläuft. Das Relay leitet Chiffrat weiter, das es nicht öffnen kann.
3
Kandidaten sammeln
Parallel dazu ermittelt jeder Agent alle Adressen, unter denen er erreichbar sein könnte: seine LAN-Adressen (Host-Kandidaten) und die öffentliche Adresse samt Port, die ein STUN-Server meldet (Server-Reflexive). Eine TURN-Adresse (Relayed) kommt nur hinzu, wenn eines der beiden Geräte kein SXAccess-Relay hat. Auch die Kandidaten werden über Discovery übermittelt.
4
Jedes Paar prüfen
Beide Seiten senden gleichzeitig Verbindungsprüfungen über die Kandidatenpaare. Das erste Paar, das in beiden Richtungen antwortet, gewinnt.
5
Zum erfolgreichen Paar wechseln
Der Tunnel wechselt vom Relay auf das erfolgreiche Paar. Geht dieser Pfad später verloren, läuft der Datenverkehr wieder über das Relay, und die Agenten suchen erneut nach einem direkten Pfad.

Was einen direkten Pfad verhindert

Situation	Wirkung	Was hilft
Symmetrisches NAT auf beiden Seiten	Jede ausgehende Verbindung erhält einen anderen externen Port; der reflexive Kandidat ist daher schon veraltet, wenn das Gegenüber ihn nutzt.	Lokal lässt sich nichts tun; der Tunnel bleibt auf dem Relay. Mobilfunknetze verhalten sich oft so.
Carrier-Grade-NAT (CGNAT)	Die Maschine hat keine eigene öffentliche Adresse, und das NAT des Providers wählt ihren externen Port. Vergibt dieses NAT für jede Verbindung einen neuen Port, wie ein symmetrisches NAT, kommt kein direktes Paar zustande.	Das Relay übernimmt den Tunnel, wenn kein Paar durchkommt.
Ausgehendes UDP blockiert	Kein Kandidat lässt sich bestätigen.	Ausgehendes UDP erlauben oder das Relay in Kauf nehmen, das über TLS auf TCP 443 läuft.
Beide Geräte im selben LAN	Gelingt in der Regel sofort über Host-Kandidaten.	Nichts nötig - dieser Pfad verlässt das Gebäude nie.
Ein Gerät hat eine öffentliche Adresse	Gelingt fast immer.	Routing-Geräte und Server nach Möglichkeit mit einer öffentlichen Adresse betreiben.

Den Verbindungsstatus auswerten

sxaccess info -d zeigt für jedes Gerät den Path (P2P für direkt, Relayed für über ein Relay), die erfolgreichen Candidates (lokaler und entfernter Kandidatentyp), die Umlaufzeit (Round trip) und den letzten Handshake (Last handshake). sxaccess info --filter-by-connection-type Relayed listet nur die Geräte auf, deren Tunnel über ein Relay läuft.

Öffnen Sie in der SXAccess-App die Seite Devices. Unter Path sehen Sie für jedes Gerät, ob sein Tunnel direkt oder über ein Relay läuft: unter macOS und Windows in einer eigenen Spalte, auf iPhone und Android in den Details des Geräts.

Ein Tunnel über ein Relay ist vollständig Ende-zu-Ende verschlüsselt - das Relay leitet Chiffrat weiter, das es nicht öffnen kann. Ein solcher Tunnel kostet Latenz und Bandbreite, aber keine Vertraulichkeit.

shell - prüfen

sxaccess info -dsxaccess info --filter-by-connection-type Relayed

Zum Vergleich halten Sie mit SX_RELAY_ONLY=true alle Tunnel dieses Geräts auf dem Relay. reconfigure startet einen laufenden Agenten von selbst neu. Der Befehl ersetzt außerdem die gesamte Dienstumgebung des Agenten: Nennen Sie jede bisher gesetzte Variable im selben --service-env, durch Kommas getrennt. Zum Zurücksetzen führen Sie reconfigure erneut ohne SX_RELAY_ONLY aus.

shell - alle Tunnel auf dem Relay halten, zum Vergleich

sudo sxaccess agent reconfigure --service-env SX_RELAY_ONLY=true

Dem Agenten ein NAT mitteilen, das er nicht sieht

Eine Cloud-Instanz hinter einem 1:1-NAT, etwa mit einer AWS Elastic IP, kennt nur ihre private Adresse. --external-ip-map <öffentlich>/<private-ip-oder-schnittstelle>, eine Option von sxaccess start auf Support-Ebene, legt die Zuordnung fest, und der Agent kündigt statt der privaten die öffentliche Adresse an. Das hilft, wenn STUN nicht verfügbar ist oder wenn die Instanz eingehendes UDP an ihrer öffentlichen Adresse annimmt. Auf einem verbundenen Gerät gibt start This device is already connected aus und ändert nichts; der Befehl unten trennt das Gerät deshalb zuerst. Führen Sie es als eine Zeile aus: Eine Verbindung über SXAccess, etwa eine SSH-Sitzung zu dieser Maschine, bricht ab, bis start fertig ist. In einer Sitzung über sxaccess shell klappt das nicht: Beim Stoppen schließt der Agent diese Sitzung und beendet den Befehl. Nutzen Sie dafür die Konsole oder eine OpenSSH-Sitzung.

shell - eine bekannte öffentliche Adresse ankündigen

sxaccess stop && sxaccess start --external-ip-map 203.0.113.10/10.0.0.4