L2TP/IPsec durch NAT: was wirklich bricht und warum

Die Behauptung, NAT breche L2TP/IPsec, ist halb wahr und damit nutzlos. Adressübersetzung ist normal, NAT-Traversal existiert genau dafür, sie zu überleben, und Millionen Clients verbinden sich täglich hinter einem Router. Was bricht, ist eine bestimmte Phase einer bestimmten Aushandlung: IKE bekommt nie eine Antwort, der gekapselte Tunnel wird von einer Regel verworfen, die nur ein Protokoll erlaubt, oder das Übersetzungs-Mapping läuft ab, während der Tunnel inaktiv ist. Sobald Sie wissen, in welcher Phase Sie sind, ist die Lösung meist eine einzelne Regel oder ein Keepalive statt eines neuen VPN-Designs.

Der Mythos ist die falsche Frage

Die nützliche Frage ist nicht „bricht NAT das“, sondern „welcher Teil der Aushandlung wird übersetzt, und was macht das übersetzende Gerät damit“. L2TP/IPsec ist ein geschichtetes Protokoll: IKE verhandelt, ESP schützt, und L2TP trägt PPP innerhalb dieses Schutzes. Adressübersetzung wirkt auf jede Schicht anders, und die Fehlersignaturen lassen sich unterscheiden, wenn man die Aushandlungsphase betrachtet statt den Fehlerdialog.

Ein Router, der erfolgreich im Web surft, beweist nur, dass TCP mit Quellport-Übersetzung funktioniert. Er sagt nichts über UDP 500, UDP 4500 oder Protokoll 50, und genau diese drei Dinge braucht dieses Deployment.

Phase 1: IKE muss überhaupt eine Antwort bekommen

Die erste Aushandlung geht auf UDP 500 an die antwortende Seite. Kommt keine Antwort zurück, spielt alles andere keine Rolle: der vorab geteilte Schlüssel, der Vorschlag und die Anmeldedaten bleiben ungelesen. Beobachten Sie Anfrage und Antwort, statt aus dem Timeout des Clients zu schließen:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Eine Anfrage ohne Antwort bedeutet meist, dass eine Firewall oder der Upstream-Carrier das Paket verwirft, nicht dass der Server es abgelehnt hat. Eine Antwort mit einer Notify-Nutzlast, die einen Vorschlag oder ein Zertifikatsproblem nennt, bedeutet, dass die Pakete angekommen sind und die Aushandlung am Inhalt gescheitert ist, was eine ganz andere Reparatur ist.

Sitzen beide Seiten hinter einer Übersetzung, muss der Initiator nur die antwortende Seite erreichen, daher funktionieren die meisten clientseitigen Deployments ab Phase 1. Server-Hosting ist der Punkt, an dem das eingehende Problem beginnt, und deshalb sollten die beiden Situationen nie als eine diskutiert werden.

Phase 2: Kapselung ändert, was die Firewall sieht

ESP ist ein IP-Protokoll, kein TCP- oder UDP-Port, und gewöhnliche Port-Adressübersetzung hat kein Portfeld, das sie umschreiben könnte. Deshalb verschiebt NAT-Traversal die geschützte Nutzlast in UDP 4500: Die Kapselung gibt dem übersetzenden Gerät etwas, das es zu übersetzen weiß. Sobald das geschieht, wird eine Firewallregel, die nur für UDP 500 geschrieben wurde, die Aushandlung erlauben und den Tunnel verwerfen, was zu dem verwirrenden Ergebnis führt, dass das Protokoll eine erfolgreiche Phase 1 und keinen Verkehr zeigt.

Die IKE-Aushandlung selbst kann nach erkanntem NAT ebenfalls auf UDP 4500 wechseln, was Leute überrascht, die 500 und sonst nichts freigegeben haben. Erlauben Sie beide Ports in beide Richtungen auf dem Pfad, und bedenken Sie, dass eine zustandsbehaftete Firewall den Fluss nur hält, solange sie Verkehr sieht.

Protokoll 50 ist auf Pfaden ohne Übersetzung weiterhin wichtig, und auf Pfaden, auf denen eine Middlebox dafür konfiguriert ist. Wenn Sie per Ausschluss diagnostizieren, deaktivieren Sie die Hypothese, statt Regeln in Bündeln hinzuzufügen: erlauben Sie 500, 4500 und ESP, bestätigen Sie, dass der Tunnel hochkommt, und entfernen Sie dann, was sich als unnötig erwies. Eine Regel, die niemand erklären kann, ist eine Regel, die niemand entfernt, wenn sie zur Ursache des nächsten Ausfalls wird. Schreiben Sie die Eingrenzung zusammen mit der behobenen Phase ins Änderungsprotokoll, damit der nächste Engineer mit Ihren Belegen beginnt und nicht mit derselben Faustregel.

Phase 3: Das Mapping läuft ab und der Tunnel stirbt

Ein übersetzendes Gerät hält Zustand für die Flüsse, die es weiterleitet, und dieser Zustand hat eine Lebensdauer. Ein L2TP/IPsec-Tunnel überträgt wenig Verkehr, wenn ihn niemand nutzt, daher kann ein inaktiver Tunnel sein Mapping überleben und aufhören, Rückverkehr zu empfangen. Der Client bleibt überzeugt, verbunden zu sein, der Server sieht nichts, und das erste Symptom ist meist ein Anwendungs-Timeout statt eines VPN-Fehlers.

Dead-Peer-Erkennung und NAT-Keepalives gibt es dafür, und beide Seiten müssen bereit sein, sie zu senden. Steht Ihr Server hinter einer Übersetzung, ist die Windows-seitige Anforderung eine dokumentierte Registrierungseinstellung, die den Server UDP-Kapselung für seine eigenen ausgehenden Pakete annehmen lässt; ohne sie sendet die antwortende Seite ESP, welches das übersetzende Gerät nicht zurückmappen kann. Das ist ein Serverkonfigurationsproblem, kein Clientproblem.

Ein Wechsel der WAN-Adresse erzeugt dasselbe Ergebnis aus anderer Richtung: Das Mapping wird um eine neue Adresse herum neu aufgebaut, und die alte Sicherheitsassoziation zeigt nun auf ein Tupel, das nicht mehr existiert. Das Wiederverbindungsverhalten gehört zur Client-Implementierung, weshalb „nach dem Router-Neustart neu verbinden“ bei einem Client funktioniert und bei einem anderen einen manuellen Schalter braucht.

Hosting hinter Carrier-Grade-NAT ist ein anderes Problem

Wenn Sie einen L2TP/IPsec-Server zu Hause hosten und von außen erreichen wollen, ist die Anforderung unaufgeforderte eingehende Erreichbarkeit, und das ist nicht, was NAT-Traversal bietet. Ein Carrier-Grade-NAT vor Ihrem Router bedeutet, dass es keinen Port gibt, den Sie weiterleiten können, um erreichbar zu werden, weil die öffentliche Adresse geteilt wird und das Mapping nur ausgehend ist.

Kein IPsec-Pass-Through-Kästchen ändert das, und keine Client-Konfiguration gleicht es aus. Die unterstützten Antworten sind eine tatsächlich erreichbare Adresse, ein gehosteter Endpunkt oder eine Architektur, in der jeder Teilnehmer eine ausgehende Verbindung herstellt. Die UDP-Kapselungsspezifikation löst das Übersetzungsproblem für Flüsse, die existieren; sie schafft keinen eingehenden Pfad, wo der Carrier keinen anbietet.

Vergleichen Sie also Netzwerke, statt zu raten. Nehmen Sie dasselbe Gerät und Profil in ein anderes erlaubtes Netzwerk und beobachten Sie, welche Phase dort scheitert. Funktioniert es anderswo, liegt der Unterschied im Pfad, und das grenzt die Suche auf die drei Phasen oben ein statt auf die gesamte Konfiguration.