Symmetrisches NAT und VPNs: die Zuordnung messen, nicht das Etikett
Endpunktabhängige Zuordnung betrifft die Peer-Erkennung, nicht einen normalen Client-Server-Tunnel. Messen Sie den Port und nutzen Sie dann ein Relay, wenn der direkte Pfad scheitert.
Ein Support-Thread endet mit dem Urteil „symmetrisches NAT, das VPN wird hier nicht funktionieren“, und danach wird der Client dreimal ohne Grund neu installiert. Das Etikett richtet Schaden an, weil es eine Frage beantwortet, die niemand gestellt hat. Ein Client, der nach außen zu einem festen Server verbindet, erzeugt eine Zuordnung in dem Moment, in dem er das erste Paket sendet, und die Antwort darf zurück, nach Regeln, die nahezu jedes Netzwerk umsetzt. Was endpunktabhängige Zuordnung wirklich erschwert, sind zwei Peers, die gleichzeitig zueinander gelangen wollen, und das ist ein anderer Test.
Zwei Fragen verstecken sich hinter einem Etikett
Die erste Frage ist, ob ein Host hinter diesem Netzwerk eine Sitzung zu einer bekannten öffentlichen Adresse und einem Port öffnen kann. Für einen Tunnel-Client ist das der Normalfall, und die Antwort ist fast immer ja. Der Router vermerkt die interne Quelle, vergibt einen externen Port und lässt die Antwort durch, weil sie zu einer Sitzung gehört, die von innen begonnen wurde.
Die zweite Frage ist, ob zwei Hosts hinter verschiedenen Netzwerken einen gemeinsamen Pfad finden und ohne Server dazwischen zueinander senden können. Das hängt davon ab, wie jedes Netzwerk diese externen Ports vergibt, und nur dort spielt das Verhalten der Zuordnung eine Rolle.
Beides zu verwechseln erzeugt die klassische Fehldiagnose: Eine Peer-to-Peer-Funktion scheitert, jemand lässt einen NAT-Typ-Test laufen, sieht die schlechteste Kategorie und schließt daraus, dass der gewöhnliche Tunnel ebenfalls nicht funktionieren kann. Der Tunnel war nie das, was scheiterte.
Zuordnung und Filterung sind getrennte Eigenschaften
Die RFC-Terminologie ist präziser als die Namen, die Anbieter verwenden, und es lohnt sich, sie ins Ticket zu übernehmen, weil sie Streit entscheidet. Zuordnung ist, wie der externe Port vergeben wird. Filterung ist, welche eingehenden Pakete durchgelassen werden. Ein Netzwerk kann beim einen streng und beim anderen liberal sein, und diese Kombination ist es, die ein Peer-to-Peer-Protokoll überstehen muss.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
Die dritte Zeile ist das, was die meisten Consumer-Router und Mobilfunknetze unter symmetrisch verstehen. Beachten Sie, dass das Etikett nur die Vergabe beschreibt. Ein Netzwerk mit dieser Zuordnung und liberaler Filterung kann eingehende Pakete an den gerade vergebenen Port dennoch annehmen, weshalb Lochstanzen bei einigen gelingt und bei anderen scheitert.
Filterung hat ihre eigenen drei Fälle und ihren eigenen Namen für jeden. „symmetrisches NAT“ ins Ticket zu schreiben, wenn „adress- und portabhängige Filterung“ gemeint ist, schickt die nächste Person in das falsche Kapitel des Handbuchs. Die beiden verhalten sich im Test unterschiedlich, der Fehler ist also nicht akademisch.
Messen Sie die Zuordnung, statt sie zu benennen
Sie können den vergebenen Port direkt von der Serverseite jedes UDP-Dienstes beobachten, den Sie kontrollieren. Starten Sie einen Mitschnitt auf dem öffentlichen Host, senden Sie vom Client und lesen Sie den Quellport, mit dem das Paket ankam:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820
Die Endpunkt-Zeile ist die nützlichste der drei, weil WireGuard die letzte Adresse und den letzten Port speichert, die er von jedem Peer empfangen hat. Vergleichen Sie diesen Port mit dem, den der Client zu nutzen glaubt. Sie werden sich unterscheiden, sobald irgendeine Übersetzung stattfindet, und die wichtige Frage ist, ob der Wert stabil bleibt.
Wiederholen Sie die Beobachtung gegen einen zweiten Zielport oder einen zweiten Server und vergleichen Sie erneut. Ändert sich der externe Port je Ziel, ist die Zuordnung adress- und portabhängig. Bleibt er gleich, gibt das Netzwerk Ihnen eine Zuordnung, und die Erkennung hat eine Chance.
STUN-basierte Werkzeuge melden dieselbe Klassifikation in einem Schritt, und sie sind in Ordnung, wenn das Netzwerk ausgehendes UDP zu einem öffentlichen STUN-Server erlaubt. Wenn nicht, funktioniert die obige Mitschnittmethode weiterhin und verlangt nichts außer einem Host, den Sie bereits kontrollieren.
Wählen Sie eine Reparatur, die zum Fehler passt
Scheitert eine Peer-to-Peer-Funktion, sind die unterstützten Antworten ein Relay, ein Vermittlungsdienst, den beide Peers erreichen, oder eine andere Topologie. TURN existiert genau dafür, und ein Produkt, das sein eigenes Relay mitbringt, sagt Ihnen damit, dass es manche Netzwerke für feindlich hält.
Scheitert eine gewöhnliche Tunnelverbindung, ist das Verhalten der Zuordnung nicht Ihr Problem, und nichts des Obigen trifft zu. Prüfen Sie, ob der Client tatsächlich sendet, ob der Server das Paket sieht und ob die Antwort zurückkommt. Diese Reihenfolge sind drei Beobachtungen, und sie erfordert kein Wissen über die NAT-Kategorie des Routers.
Was nicht funktioniert, ist, lokale Portänderungen zu streuen, bis sich etwas verbindet. Den Quellport des Clients zu ändern, ändert nicht, wie das Netzwerk Zuordnungen vergibt. Ein zufälliger Erfolg beim fünften Versuch ist ein falsch positiver Befund, und er wird monatelang als Lösung zitiert.
Halten Sie die Architektur fest, nicht das Urteil
Eine brauchbare Notiz sagt, welches Protokoll, in welche Richtung die Sitzung beginnt, ob ein Relay im Pfad liegt und was auf der Leitung beobachtet wurde. „symmetrisches NAT, funktioniert nicht“ ist unbrauchbar, weil es gleichzeitig falsch über den Tunnel und nichtssagend über den Peer-Pfad ist.
Nehmen Sie die gemessene Portstabilität und das Filterverhalten auf, wenn Sie beides getestet haben. Diese zwei Fakten lassen jemand anderen vorhersagen, ob eine neue Funktion in jenem Netzwerk funktioniert, ohne die ganze Untersuchung zu wiederholen. Sie altern auch besser als eine Anbieterkategorie, die auf jeder Hilfeseite etwas leicht anderes bedeutet.
Halten Sie schließlich die RFC-4787-Terminologie bereit, wenn Sie das aufschreiben. Die genauen Begriffe zu verwenden kostet einen Satz und verhindert, dass der nächste Leser dieselbe Fehldiagnose wiederholt, und genau darum geht es beim Schreiben der Notiz.