Einen VPN-Server auf eine neue öffentliche IP umziehen: was zuerst zu prüfen ist

Eine Adresse neu zuzuweisen dauert eine Minute. Die Woche danach ist der Punkt, an dem der Umzug bricht, und selten dort, wo die Konsole des Anbieters es nahelegt. Eine neue öffentliche IP wird an vier Stellen referenziert: der Socket, auf dem der Daemon lauscht, der Vertrauensanker, den Clients prüfen, jede Regel, die die alte Adresse nennt, und der DNS-Eintrag, der sie zusammenhält. Zwei Umzüge sehen im Kontrollpanel identisch aus, verhalten sich aber völlig unterschiedlich: die Adresse auf der Maschine neu zuzuweisen, die Sie betreiben, oder einen zweiten Endpunkt aufzustellen und Clients dorthin zu bewegen. Die Prüfungen unten stellen die billigen Fehler nach vorn, und jeder Abschnitt nennt, für welchen Umzug er gilt.

Tausch an Ort und Stelle und parallele Umstellung sind verschiedene Aufgaben

Ein Tausch an Ort und Stelle behält Host, Schlüssel, Routingtabelle und Benutzerliste; nur die Adresse ändert sich. Das macht eine Neuzuweisung einer Floating-IP, und bei mehreren Anbietern merkt der Gast nichts davon, weil die Übersetzung vor der Instanz passiert. Ein Rebuild oder eine Neuzuweisung durch den Anbieter ist härter: der Gast sieht die Änderung, und alles, was den alten Wert zwischengespeichert hat, erfährt sie im selben Moment.

Ein paralleler Endpunkt ist ein zweiter Host, der dieselbe Aufgabe erledigt. Bauen Sie ihn, testen Sie ihn mit einem Profil, und lassen Sie den alten antworten, bis der neue sich über einen echten Pfad beweist. Der Preis ist Zustand. Ohne gemeinsame Peer-Einträge, Widerrufe und Protokollierung haben Sie zwei Netze, die zufällig denselben Namen teilen.

Finden Sie jede Stelle, an der die alte Adresse niedergeschrieben ist

Beginnen Sie mit einer Textsuche, denn Konfigurationsdateien sind die leichte Hälfte. Durchsuchen Sie die Daemon-Konfiguration, Firewall-Fragmente, Monitoring-Ziele und jedes erzeugte Client-Bundle auf der Platte. Schließen Sie die IPv6-Adresse ein, wenn Sie eine veröffentlichen; ein Umzug, der nur dem A-Eintrag folgt, lässt Dual-Stack-Clients auf dem alten Pfad.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Gehen Sie dann den Kernel durch, denn ein laufendes System hält die Adresse an Stellen, die keine Datei erwähnt. Eine statische Quell-NAT-Regel, ein ipset-Eintrag, eine Bind-Adresse und ein conntrack-Eintrag überleben die Konfigurationsänderung, die sie entfernt hat, und manche überleben einen Neustart, weil sie aus einem gespeicherten Regelsatz zurückkamen. Eine Ebene höher liegen Anbieter-Sicherheitsgruppen, Load-Balancer-Ziele und Monitoring-Prüfungen gar nicht auf Ihrem Dateisystem.

Schreiben Sie das Inventar auf, bevor Sie etwas ändern; es dient zugleich als Rollback-Skript.

Hostname-Clients erholen sich; Literal-IP-Clients verstummen

Wenn Clients den Server über einen Hostnamen erreichen, ist die Umstellung vor allem ein DNS-Problem, und die TTL, die Sie gestern gesetzt haben, entscheidet, wie schlimm es wird. Resolver cachen, Stub-Resolver cachen noch einmal, und viele Clients schlagen den Namen nur bei einer neuen Verbindung nach, sodass ein bestehender Tunnel seine Anfangsadresse behält.

Ist der Endpunkt eine Literaladresse, wird nichts neu aufgelöst, und nichts protokolliert eine Beschwerde. WireGuard speichert eine aufgelöste Socket-Adresse: Endpoint = vpn.example.net:51820 wird in dem Moment zu einer IP, in dem wg-quick up läuft, und bleibt diese IP, bis Sie sie ändern. OpenVPN ist nachsichtiger: es löst den Hostnamen remote beim Verbinden auf und versucht mit resolv-retry infinite beim Wiederverbinden erneut DNS. Mit einer Literal-IP wählen beide weiter eine Maschine, die es nicht mehr gibt.

Was Leute in die Irre führt, ist das Spiegelbild. Ein Client, der schon auf die neue Adresse zeigt, während der alte Listener noch antwortet, besteht jeden Test, den Sie von Ihrem Schreibtisch aus fahren. Ich bin darauf hereingefallen: der neue Endpunkt kam auf einem Telefon beim ersten Versuch hoch, und ein Client mit veraltetem Profil tauchte erst auf, als der alte Listener viel später abgeschaltet wurde.

Vertrauen zieht nicht mit der Adresse um

WireGuard trennt Identität von Erreichbarkeit, was einen Adressumzug fast kostenlos macht. Peers werden über den öffentlichen Schlüssel identifiziert, und der Endpunkt ist nur der Ort, an den Pakete gerade gehen; ein Host aktualisiert den Endpunkt eines Peers aus der Quelladresse des zuletzt authentifizierten Pakets. Ein inaktiver Peer braucht trotzdem einen Grund, mit dem neuen Ort zu sprechen, und er erfährt die Adresse erst, wenn seine Sitzung altert und die Handshake-Wiederholungen an einer sichtbaren Stelle scheitern. Der WireGuard-Schnellstart behandelt das Endpunkt-Feld.

TLS-basierte Server sind der umgekehrte Fall. Das Zertifikat ist an einen Namen gebunden, und ein Client, der eine Adresse wählt, vergleicht das Gewählte mit den Subject Alternative Names. Verbinden Sie per IP zu einem Zertifikat, das nur ein DNS-SAN trägt, und die Prüfung scheitert: der vom Client verwendete Name steht nicht im Zertifikat. Neuausstellung mit einem IP-SAN repariert diese eine Verbindung und macht den nächsten Umzug schlimmer. Einen Hostnamen im Profil zu behalten und verify-x509-name stehen zu lassen hält die Prüfung streng, während sich die Adresse darunter ändert.

Prüfen Sie dann, woran der Daemon gebunden ist; ein an die alte Adresse gehefteter Socket scheitert still. Ein OpenVPN-Server, der mit local 203.0.113.10 startet, kommt nicht hoch, sobald die Adresse weg ist, während ein Listener auf 0.0.0.0 der Änderung kostenlos folgt. NAT teilt sich genauso: MASQUERADE folgt, welche Adresse die Kiste jetzt hat, und ein statisches SNAT --to-source 203.0.113.10 schreibt weiter auf eine Adresse um, die Sie nicht mehr besitzen, sodass Rückverkehr verschwindet. Kommt die neue Adresse mit einem anderen Upstream-Gateway, prüfen Sie rp_filter: Reverse-Path-Filterung verwirft Rückverkehr, der auf einer Schnittstelle ankommt, die der Kernel nicht erwartet hat.

Reihenfolge der Umstellung und der Nachweis, dass sie funktioniert hat

Senken Sie die TTL einen Tag vorher, stellen Sie den neuen Listener auf, und beweisen Sie ihn mit einem Profil, das nur Sie haben. Ein Test aus demselben Netz heraus beweist fast nichts, also nehmen Sie ein Telefon im Mobilfunknetz und testen Sie etwas, das der Tunnel tragen soll, statt eines Ping zum Endpunkt.

Beobachten Sie beide Adressen über das Fenster. wg show all latest-handshakes auf dem neuen Host oder die OpenVPN-Statusdatei sagt Ihnen, wie viele Peers tatsächlich umgezogen sind. Wenn der neue Endpunkt die erwarteten Peers hat und der alte nur Nachzügler, ziehen Sie den alten Listener außer Betrieb, entfernen Sie die veraltete NAT-Regel und streichen Sie die Adresse aus der Anbieter-Firewall. Den alten Listener zu entfernen ist der Schritt, der übersprungen wird, und er schließt die Lücke, in der ein veraltetes Profil noch das alte Netz erreicht.

Legen Sie den Rollback-Auslöser vorher schriftlich fest: wenn der neue Endpunkt nach dem vereinbarten Fenster keinen Handshake von einem einzigen echten Client hat, stellen Sie die alte Adresse wieder her und verteilen Sie keine Profile mehr. Fahren Sie die Suche danach erneut und bestätigen Sie, dass kein Listener noch an eine ausgemusterte Adresse gebunden ist. Zwei Dinge tragen in den nächsten Umzug hinein: ein Hostname im Clientprofil, damit die nächste Änderung eine DNS-Bearbeitung ist, und das Inventar neben den Wiederherstellungsnotizen des Servers.