Hairpin-NAT: Warum der VPN-Endpunkt von innen scheitert

Ein VPN-Server, der aus einem Mobilfunknetz antwortet und vom Sofa aus scheitert, ist meist kein Zertifikatsproblem. Der Client im LAN bittet den Router, ein Paket zu übersetzen, dessen Ziel die eigene öffentliche Adresse des Routers ist, was bedeutet, dass das Paket hinausgehen und direkt wieder hereinkommen muss. Dieses Manöver heißt Hairpinning, und viele Router implementieren es entweder gar nicht oder nur, wenn ein Kontrollkästchen aktiviert ist. Dass der Test von außen gelingt, macht die Sache verwirrend, denn er beweist, dass Listener und Weiterleitungsregel in Ordnung sind.

Das Paket geht hinaus und kommt wieder herein

Verfolgen Sie das Paket. Der Client löst den öffentlichen Namen auf, verbindet sich mit der öffentlichen Adresse, und das Destination-NAT des Routers schreibt das Ziel auf den internen Server um. Die Antwort des Servers ist an die LAN-Adresse des Clients adressiert, also geht sie über die LAN-Schnittstelle des Routers zurück, ohne jemals die NAT-Regel zu durchlaufen, die die Quelle zurückübersetzt hätte.

Nun empfängt der Client ein Paket von einer Adresse, an die er nie etwas gesendet hat, und verwirft es. Diese Asymmetrie ist der ganze Fehler.

RFC 4787 beschreibt das Verhalten, das von einem NAT in diesem Fall erwartet wird, und die Kurzfassung lautet, dass es in der Praxis optional ist, selbst wo es theoretisch festgelegt ist. Manche Router nennen die Einstellung NAT loopback, andere Hairpin-NAT oder NAT-Reflection, und manche bieten gar nichts an. Ein Router ohne diese Funktion ist nicht falsch konfiguriert; er tut das Übliche, und die Lösung gehört woandershin. Schließen Sie aus einem gescheiterten lokalen Test nicht, dass die öffentliche Weiterleitungsregel falsch ist.

Prüfung 1: Testen Sie die beiden Wege getrennt

Verbinden Sie sich von außerhalb des LAN mit demselben Profil, das ein echter Nutzer verwenden würde, und bestätigen Sie, dass die Sitzung zustande kommt. Verbinden Sie sich von innen mit demselben Profil zur öffentlichen Adresse und notieren Sie den genauen Fehler und die Uhrzeit.

Ein präziser lokaler Test behält den Hostnamen und überschreibt nur die Adresse: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ schickt die Anfrage an die öffentliche Adresse und präsentiert weiterhin den richtigen Servernamen. Das trennt ein Namensauflösungsproblem von einem Übersetzungsproblem, die leicht zu verwechseln sind, wenn derselbe Name aus einem Café funktioniert. Notieren Sie, ob der Client beim TCP-Verbindungsaufbau oder erst später bei TLS scheitert, denn das erste deutet auf Übersetzung, das zweite auf Identität.

Prüfung 2: Lesen Sie, was der Server sieht

Die nützlichste Beobachtung ist die Sicht des Servers. Starten Sie einen Mitschnitt auf dem VPN-Host, gefiltert auf die LAN-Adresse des Clients und die LAN-Adresse des Routers, und wiederholen Sie dann den lokalen Versuch. Kommt nichts an, hat das Paket die Übersetzung nicht überlebt.

Kommt eine Verbindung von der LAN-Adresse des Routers statt von der des Clients, findet Hairpinning statt und die Quelle wurde umgeschrieben. Das ist eine funktionierende Konfiguration, kein Fehler.

Prüfung 3: Beheben Sie es, ohne den äußeren Weg anzutasten

Es gibt drei unterstützte Formen, in aufsteigendem Umfang der Wirkung. Die engste ist geteiltes DNS: Veröffentlichen Sie einen internen Eintrag, sodass derselbe Servername für Clients im LAN auf die interne Adresse auflöst, was den öffentlichen Weg völlig vermeidet. Die nächste ist, die dokumentierte Loopback- oder Reflection-Option des Routers zu aktivieren, falls vorhanden, und sie nur auf diesen Dienst anzuwenden. Die weiteste ist eine Source-NAT-Regel auf dem Router, die LAN-Verkehr zum Server umschreibt, damit die Antwort über den Router zurückkommt; auf einem Linux-Router ist das eine MASQUERADE-Regel in POSTROUTING, die auf Adresse und Port des Servers passt. Alle drei lassen den externen Weg unberührt, und genau diese Eigenschaft gilt es zu erhalten.

Erweitern Sie keine unzusammenhängende Portweiterleitung, damit der lokale Weg dem externen ähnelt, und verschieben Sie den Dienst nicht auf einen anderen Port, um das Problem zu umgehen. Beide Änderungen verändern, was die Außenwelt erreichen kann, um etwas zu reparieren, das nur die Innenwelt sieht.

Geteiltes DNS hat eine Falle, die es wert ist, benannt zu werden. Ein Hostname durch eine beliebige IP zu ersetzen ändert, was der Client validiert, also muss der interne Eintrag weiterhin zum Namen im Zertifikat passen.

Prüfung 4: Prüfen Sie danach beide Wege

Wiederholen Sie den externen Versuch von außerhalb des LAN, wiederholen Sie den internen Versuch mit demselben Profil, und bestätigen Sie, dass das Serverprotokoll zwei getrennte erfolgreiche Sitzungen zeigt statt eines Erfolgs und einer Stille. Prüfen Sie dann, ob andere Clients den Listener noch erreichen und ob die Routen zu privaten Ressourcen unverändert sind.

Halten Sie die Notiz kurz: welche Adresse jeder Client nutzte, was der Server sah und welche der drei Korrekturen angewandt wurde. Die Hairpinning-Anforderungen aus RFC 4787 sind die Referenz dafür, was hier von einem NAT erwartet wird, und sie erklären, warum ein Router ohne die Funktion sich normal verhält. Ein lokaler Fehler, den die Außenwelt nicht reproduzieren kann, ist eine Übersetzungsfrage, bis das Gegenteil bewiesen ist, also testen Sie ihn als solche.