Wie Sie einen VPN-Server wiederherstellen, ohne Identitäten zu duplizieren

Sie haben die Sicherung wiederhergestellt, der Dienst startete, und ein Client verband sich beim ersten Versuch. Dieser Erfolg ist die Falle. Eine Wiederherstellung liefert die Dateien zurück, die der Server zum Zeitpunkt des Snapshots hatte, nicht den Zugriffsstatus, der sich seither geändert hat, und wenn der alte Endpunkt noch erreichbar ist, haben Sie jetzt zwei Maschinen, die auf eine Identität antworten. Die Lösung ist keine bessere Sicherung; sie besteht darin, zu entscheiden, was der wiederhergestellte Host sein darf, bevor er einen einzigen Handshake beantwortet.

Eine Sicherung liefert Dateien zurück, nicht Befugnis

Der Snapshot enthält die Serverkonfiguration, die privaten Schlüssel, die Zertifizierungsstelle, die Peer-Liste und die Firewallregeln, wie sie beim Lauf der Sicherung waren. Was sich danach änderte, kann er nicht enthalten: das Gerät, das Sie widerrufen haben, den Schlüssel, den Sie neu ausgestellt haben, den Peer, den Sie beim Verkauf eines Laptops entfernt haben, das Subnetz, das Sie verschoben haben. Wiederherstellen spult die Dateien auf diesen Moment zurück. Die Entscheidungen, die Menschen seither getroffen haben, spult es nicht zurück.

Der Schaden entsteht genau aus dieser Lücke. Ein gestohlener Laptop, zwei Wochen nach der Sicherung widerrufen, legt ein Zertifikat vor, das noch gegen die ältere CRL im wiederhergestellten Baum geprüft wird, und der Server akzeptiert ein Gerät, das Sie außer Betrieb genommen haben. WireGuard ist direkter: Ein Peer ist autorisiert, weil er gelistet ist, also ist ein nach dem Snapshot gelöschter Peer einfach wieder da. Niemand hat diesen Zugriff erneut genehmigt. Die alte Datei tat es.

Serveridentität und Clientidentität scheitern auf unterschiedliche Weise

Bei WireGuard ist die Identität des Servers der private Schlüssel in wg0.conf, das Kopieren dieser Datei auf einen zweiten erreichbaren Host erzeugt also zwei Server mit derselben Identität und ohne Kenntnis voneinander. Jeder führt seine eigene Peer-Liste. Entfernen Sie einen Peer auf dem neuen Host, akzeptiert ihn der alte weiterhin; prüfen Sie wg show auf einem, und Sie sehen die halbe Wahrheit. Clients wechseln auch nicht von selbst: Ein Profil trägt einen Endpoint, also spricht ein Gerät weiter mit der Adresse, mit der es konfiguriert wurde, was der Host sein kann, den Sie außer Betrieb nehmen wollten.

OpenVPN dupliziert auf derselben Ebene mit einem Serverzertifikat, seinem privaten Schlüssel und dem statischen Schlüssel tls-auth oder tls-crypt. Kopieren Sie alle drei, und ein Client kann die Instanzen nicht unterscheiden; sind beide erreichbar, kann ein Wiederverbinden auf einer davon landen, und jede Protokolldatei erzählt eine Teilgeschichte. Die Zertifizierungsstelle ist die tiefere Kopie. Ein wiederhergestellter easy-rsa-Baum ist eine zweite Wahrheitsquelle, die ein gültiges Zertifikat für jeden Namen ausstellen kann, den Sie ihr geben.

Auch Clients werden dupliziert, meist während der Migration selbst. Ein Profil «nur zum Testen» auf ein Ersatzgerät zu kopieren, erzeugt ein zweites Gerät mit demselben Schlüssel und Common Name. Mit duplicate-cn können beide Sitzungen gleichzeitig bestehen, und eine statische Adresszuweisung in ccd oder ifconfig-pool-persist kann mit dem ursprünglichen Gerät kollidieren. Das sind zwei Maschinen mit einer Identität, und nichts in der Serverkonfiguration unterscheidet sie.

Wählen Sie einen von drei Zuständen für den alten Endpunkt

Eine Wiederherstellung ist erst sicher, wenn das Schicksal des alten Endpunkts entschieden ist. Außer Betrieb nehmen: Der alte Dienst muss den VPN-Port nicht mehr annehmen, bevor der neue Host startet, und wenn Sie die Maschine nicht erreichen, blockieren Sie diesen Port am Netzwerkrand für alles außer Ihrer administrativen Quelle. Denselben Host reparieren: Die Identität wiederzuverwenden ist in Ordnung, weil eine Maschine sie hält, aber zerstören Sie danach die Datenträgerkopie oder das VM-Snapshot des alten Schlüssels, damit er nicht zurückkehren kann. Ein Verfügbarkeitspaar bauen: Zwei Hosts brauchen unterschiedliche Hostidentitäten plus einen gemeinsamen Endpunkt, etwa eine schwebende Adresse, einen Load Balancer oder DNS, den Sie verschieben können. Den privaten Schlüssel zu kopieren ist kein Failover-Design; es sind zwei Server, die einen Namen beanspruchen.

Bestätigen Sie, in welchem Zustand Sie tatsächlich sind, bevor Sie Clients anfassen. Der alte Host, der auf dem VPN-Port antwortet, ist derjenige, der das widerrufene Gerät akzeptieren wird, selbst wenn DNS umgezogen ist. Prüfen Sie Listener und den öffentlichen Schlüssel:

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Gleichen Sie zuerst Peers, Widerrufe und Adressen ab

Listen Sie auf, was die Wiederherstellung behauptet, gegenüber dem, was derzeit autorisiert ist. Bei WireGuard liefert wg show wg0 Schlüssel, Endpunkt, letzten Handshake und Übertragungszähler jedes Peers, genug, um ein Gerät zu erkennen, das Sie nicht mehr besitzen. Entfernen Sie es live mit wg set wg0 peer <key> remove, und bearbeiten Sie dann auch die Konfiguration, sonst kehrt der Peer beim nächsten Start zurück. wg show wg0 allowed-ips legt das zweite Problem offen: zwei Peers auf einer Adresse oder eine Adresse, die Sie bereits neu vergeben haben.

Bei OpenVPN ist die Widerrufsliste eine Datei mit einem Datum, und eine Wiederherstellung kann eine alte zurückbringen. Prüfen Sie sie, bevor Clients sich verbinden:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

Liegt die letzte Aktualisierung vor dem Widerruf, ehrt der Server noch ein Zertifikat, das Sie widerrufen haben. OpenVPN 2.4 und später lesen die CRL-Datei für jede neue Verbindung neu, das Ersetzen der Datei stoppt also neue Sitzungen, aber bestehende Tunnel bleiben bis zur Neuverhandlung; der Standardwert von reneg-sec ist 3600 Sekunden, und ihn zu senken oder den Dienst neu zu starten verschafft Ihnen die Änderung sofort. Ältere Builds übernehmen die Datei möglicherweise nicht so zuverlässig, starten Sie also neu, wenn Sie das Verhalten der Version nicht bestätigen können. Das wg(8)-Handbuch behandelt das Peer-Entfernen und die oben verwendete allowed-ips-Syntax.

Räumen Sie auch statische Zuweisungen für Geräte auf, die nicht mehr existieren. Die Adresse eines ausgemusterten Geräts für ein neues wiederzuverwenden, während das alte Profil noch installiert ist, erzeugt genau das Duplikat, das Sie vermeiden wollen.

Prüfen Sie mit einem Client, den Sie widerrufen haben

Führen Sie die Prüfungen der Reihe nach aus einem Netz außerhalb des Tunnels aus. Zuerst verbindet sich ein autorisiertes Gerät, löst DNS über den gepushten Resolver auf und erreicht eine private Ressource. Dann muss das widerrufene Gerät scheitern, mit seinem bestehenden Profil statt einem neuen. Dann versuchen Sie den alten Endpunkt von außen: Schließt der VPN-Port noch einen Handshake ab, lebt der alte Host, und die Duplizierung ist real, nicht theoretisch.

Starten Sie den wiederhergestellten Host neu und wiederholen Sie die Prüfungen für autorisiert und widerrufen, denn dann gewinnt die Konfigurationsdatei gegen das, was Sie zur Laufzeit geändert haben. Vergleichen Sie den öffentlichen Schlüssel oder den Zertifikat-Fingerabdruck des Hosts mit dem, den die ausgemusterte Maschine verwendete. Übereinstimmende Fingerabdrücke auf zwei laufenden Maschinen bedeuten, dass die Wiederherstellung die Identität geklont hat; übereinstimmende Fingerabdrücke auf einer Maschine sind in Ordnung. Notieren Sie die wiederhergestellten Versionen, die Schlüssel-Fingerabdrücke und die widerrufene Seriennummer oder den Peer-Schlüssel, und machen Sie die nächste Sicherung nach diesem Abgleich, damit sie den Dienst so darstellt, wie er jetzt ist. Der funktionierende Test ist nicht, dass ein Client sich verbindet. Er ist, dass der Client, den Sie entfernt haben, draußen bleibt, während der alte Endpunkt geschlossen bleibt.