Das VPN ist umgezogen: Warum Ihr OpenVPN-Client noch die alte IP wählt

Der Anbieter hat Ihre öffentliche Adresse geändert, Sie haben den dynamischen DNS-Eintrag aktualisiert, und der Client kann sich weiterhin nicht verbinden. Von außen sieht es aus, als sei der Eintrag nicht durchgesickert. Meistens ist der Eintrag in Ordnung, und der Client wählt die Adresse, die er vor dem Umzug aufgelöst hat, weil ein laufender Tunnel und ein gespeichertes Profil jeweils ihre eigene Vorstellung davon haben, wo der Server lebt. Drei Schichten müssen übereinstimmen, und sie aktualisieren sich nach unterschiedlichen Zeitplänen.

Schauen Sie, was das Profil wählt, nicht was DNS sagt

Öffnen Sie die Verbindung, die Sie tatsächlich nutzen, und lesen Sie die remote-Zeile. Eine numerische Adresse dort folgt nie einer Hostnamen-Aktualisierung, so korrekt der Eintrag auch wird.

Prüfen Sie dann, ob das Profil, das Sie bearbeitet haben, dasjenige ist, das der Client geladen hat. Importierte Profile sind üblich: Ein Verwalter hat vielleicht vor Monaten eine Kopie gezogen und seine eigene Version behalten, sodass die Datei in Ihrem Download-Ordner und der Eintrag in der App voneinander abweichen können. Vergleichen Sie den Endpunkt in den Verbindungsdetails des Clients, bevor Sie überhaupt DNS debuggen.

Zwei Dateien, ein Endpunkt — das ist hier der übliche Befund.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lesen Sie den nächsten Verbindungsversuch des Clients

Starten Sie die Verbindung mit ausführlicher Protokollierung neu und lesen Sie die Zeile, in der die Adresse genannt wird, die kontaktiert wird. Dieser Wert zählt, nicht das, was Ihr Browser aufgelöst hat.

Ein Resolver-Cache kann die frühere Antwort noch halten, und manche Netze halten sie länger, als die TTL des Eintrags verlangt. Fragen Sie den Resolver, den der Client tatsächlich nutzt, statt einen öffentlichen, den Sie von anderswo getestet haben.

Wenn das Protokoll die neue Adresse zeigt und die Verbindung weiterhin scheitert, hat sich das Problem verschoben: Das Paket geht irgendwohin, und niemand antwortet. Das ist eine Frage von Listener, Firewall oder Portweiterleitung, und sie liegt auf der Serverseite statt im Auflösungspfad des Clients. Halten Sie diese beiden Fehler auseinander, denn einen unerreichbaren Listener als DNS-Problem zu behandeln, schickt Sie zweimal durch dieselbe Schleife.

Wissen Sie, welchen Neustart Sie machen

Nicht alle Neustarts bewahren denselben Zustand, weshalb sich eine Adressänderung je nachdem, wie der Prozess recycelt wird, unterschiedlich verhalten kann. Ein durch ein Signal ausgelöster weicher Neustart behält mehr des Kontexts der vorherigen Sitzung, während ein vollständiges Stoppen und Starten wieder von der Konfiguration beginnt. Wenn Sie testen, ob der Client neu auflöst, wollen Sie den Weg, der von der Konfiguration ausgeht.

Persistenz-Einstellungen zählen ebenfalls, denn sie sollen bewahren, was authentifiziert wurde, statt neuen Adressen nachzujagen.

Der sauberste Test ist ein frischer Start aus dem vorgesehenen Profil, gefolgt von einem Blick auf die Protokollzeile, die den Endpunkt nennt. Alles, was Sie aus einer teilweise bewahrten Sitzung lernen, ist eine Aussage über diese Sitzung.

Die vier Optionen und ihre getrennten Aufgaben

remote mit einem Hostnamen ist die Einstellung, die eine erneute Auflösung überhaupt möglich macht; eine literale Adresse in dieser Zeile schließt sie aus. resolv-retry steuert, was bei einem fehlgeschlagenen Lookup geschieht, und 2.6 setzt es standardmäßig bereits auf unendlich. Es hinzuzufügen ändert also nichts, und es plant nie eine periodische Prüfung auf eine andere Antwort. Wer sagt, es frage neue Adressen ab, hat Wiederherstellung mit Frische verwechselt.

persist-remote-ip geht um Kontinuität statt um Frische: Es verwendet den Endpunkt wieder, der zuletzt authentifiziert hat, über die weichen Neustarts hinweg, die es unterstützt. Während Sie einen Umzug testen, ist das das Gegenteil dessen, was Sie wollen. Deaktivieren Sie es für den Test, wenn Ihr Build es aktiviert, und stellen Sie es wieder her, sobald der neue Endpunkt bewiesen ist. Bleibt es an, kann Ihnen eine erfolgreiche Wiederverbindung nichts über DNS sagen.

float akzeptiert einen authentifizierten Peer, dessen Adresse sich mitten in der Sitzung geändert hat, und nur in Konfigurationen, die das unterstützen. Es aktualisiert DNS nicht und folgt einer Anbieteränderung nicht von selbst. Behandeln Sie es als Resilienzfunktion für Peers, die roamen, nicht als Mechanismus für dynamische Adressen für Server.

Bestätigen Sie den neuen Endpunkt, bevor Sie den Client beschuldigen

Prüfen Sie von außerhalb Ihres Netzes, ob die neue Adresse einen Listener auf dem konfigurierten Port hat und ob die Weiterleitung des Anbieters darauf zeigt. Ein korrekter A-Eintrag für eine Maschine ohne offenen Port erzeugt genau das Symptom, das Leute dem Caching zuschreiben.

Verbinden Sie sich dann erneut und prüfen Sie zwei Dinge: Der Client hat sich gegen das erwartete Serverzertifikat authentifiziert, und die Sitzung erreicht die Ressource, die Sie beabsichtigt haben. Eine Adressänderung senkt die Identitätsanforderungen nicht, und eine Verbindung, die zum falschen Endpunkt gelingt, ist schlimmer als eine, die scheitert. Das OpenVPN-2.6-Handbuch listet alle vier Optionen mit ihrem eigenen Geltungsbereich, und das ist die Checkliste, die neben dem Profil liegen sollte.

Halten Sie einen außerbandigen Weg zum Server bereit, bevor Sie den Tunnel neu starten, der Ihren Verwaltungszugang trägt. Diese eine Vorsichtsmaßnahme verhindert die meisten Vorfälle, die dieses Szenario erzeugt.