VPN-Anbieter wechseln: den Hostnamen planen, nicht nur die IP
Ein neuer DNS-Eintrag verschiebt keine bestehenden Sitzungen. Planen Sie, wer den Namen kontrolliert, wann jeder Client ihn auflöst und wie Sie den alten Endpunkt außer Betrieb nehmen.
Ihr DNS-Eintrag ist korrekt, der Ersatz ist gesund, und trotzdem wählen manche Clients stundenlang die alte Adresse. Einige scheitern sofort an einem Namen, der sich auflösen lässt und nie antwortet. Beide Ergebnisse kommen aus einer Lücke: Ein Hostname ändert, wonach ein Client sucht, nicht wann er danach sucht, und nicht, worauf er sich verlässt, wenn die Antwort eintrifft.
Das Symptom: ein korrekter Eintrag, veraltete Tunnel
Ein Profil, das einen Namen speichert, ist kein Client, der ihn ständig auflöst. Die meisten lösen einmal auf, beim Anwenden der Konfiguration oder wenn der Tunnel hochkommt, und verwenden diese Adresse dann bis zum Ende der Sitzung weiter. Ein langer TTL obendrauf ist der Grund, warum die Umstellung um Wiederverbindungen herum geplant werden muss und nicht um die DNS-Bearbeitung.
Keines der beiden Verhaltensweisen ist ein Defekt, und genau das macht das Symptom verwirrend. Der Client arbeitet mit einer Antwort, die er früher erhalten hat, und nichts auf der Serverseite zeigt, welche Antwort das war. Planen Sie die Wiederverbindung ins Wartungsfenster ein und sagen Sie den Nutzern, was sie sehen werden, oder verbringen Sie das Fenster mit der Beantwortung von Tickets. Eine Warteschlange identischer Meldungen ist das übliche Ergebnis.
Wer den Namen kontrolliert und was der Client prüft
Die Kontrolle über die Zone entscheidet, wie schnell eine Migration laufen kann. Behalten Sie den Eintrag bei einem Registrar, bei dem Sie sich anmelden können, und notieren Sie, wer ihn sonst ändern kann.
Vertrauen folgt nicht dem Namen. Ein TLS-basierter Client kann eine Zertifikatsidentität oder einen festgelegten Namen prüfen, während WireGuard den öffentlichen Schlüssel des Peers authentifiziert und den Hostnamen völlig ignoriert. Dieser Unterschied entscheidet, ob eine DNS-Bearbeitung reicht oder ob jedes Profil einen neuen Fingerabdruck braucht. Eine Eintragsänderung sollte niemals einen Endpunkt autorisieren, den niemand genehmigt hat.
Halten Sie Verwaltungs- und Wiederherstellungszugriff vom öffentlichen Clientnamen fern. Ein Hosting-Konto zu verlieren sollte Sie nicht auch den Eintrag kosten, der Clients umleitet. Bewahren Sie den Wiederherstellungspfad an einem Ort auf, der nicht von dem Anbieter abhängt, den Sie verlassen.
Wann jeder Client den Namen erneut liest
Der Auflösungszeitpunkt ist eine Eigenschaft des einzelnen Clients, prüfen Sie also die Implementierung, die Sie tatsächlich ausliefern, bevor Sie ein Umstellungsfenster versprechen. wg-quick löst den Endpunkt auf, wenn die Schnittstelle hochkommt, und behält diese Adresse, bis der Tunnel neu startet. Ein OpenVPN-Client sucht den Namen beim Verbinden, und ob er bei einer Wiederverbindung erneut nachsieht, hängt von seinen Optionen ab.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Mobile Clients sind die übliche Überraschung, weil sie eine aufgelöste Adresse über Schlaf oder einen Netzwerkwechsel hinweg halten können. Veröffentlichen Sie A- und AAAA-Einträge nur, wenn der Ersatz in beiden Familien antwortet. Eine Adresse, die in einer Familie antwortet, beweist nichts über die andere, und ein toter AAAA-Eintrag fügt jedem Versuch eine Zeitüberschreitung hinzu. Dokumentieren Sie das Auflösungsverhalten für jeden Client, den Sie unterstützen, und testen Sie dann auf den Geräten, die Menschen tatsächlich benutzen.
Eine Wiederverbindung ist bei den meisten Clients eine Benutzeraktion, und der Server kann sie nicht erzwingen. Nehmen Sie diesen Schritt in die Wartungsnotiz auf, mit einer Zeile dazu, was der Nutzer sehen wird, wenn er passiert.
Auf Basis von Belegen umstellen und dann den alten Endpunkt stilllegen
Beweisen Sie vor dem Umschalten jede Schicht am Ersatz: Der Listener antwortet, die Firewall lässt den Port durch, Routen kehren richtig zurück, der Name löst sich zur neuen Adresse auf, und eine bekannte Identität wird akzeptiert. Ein Listener, der eine Verbindung annimmt, ist nicht dasselbe wie einer, der einen Handshake abschließt, testen Sie also den Handshake und nicht den Port. Halten Sie die aktuelle Sperrliste neben der Konfiguration, denn eine wiederhergestellte Sicherung erzeugt die Peer-Liste so, wie sie war, und würde Zugriff wieder öffnen, den Sie bereits geschlossen haben. Notieren Sie, mit welcher Identität Sie getestet haben, denn „es funktioniert“ ist kein Beleg, den jemand wiederholen kann.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakesWährend der Umstellung beobachten Sie Verbindungsversuche an beiden Endpunkten für dieselbe Identität. Ein Client, der sich noch gegen die alte Adresse authentifiziert, ist ein Profil oder eine zwischengespeicherte Antwort, die sich nie bewegt hat. Legen Sie den alten Endpunkt nach einem datierten Plan still, denn zwei Dienste, die eine Identität akzeptieren, lassen zwei Türen offen.
Der Umstellungstest ist eine Anwendungssitzung über den neuen Endpunkt, kein Ping. Sobald diese Sitzung funktioniert und der alte Endpunkt über einen vollen Wiederverbindungszyklus keine autorisierten Versuche protokolliert, ist der Umzug abgeschlossen.