WireGuard: keine Route zum Peer nach einem Subnetzwechsel — zwei Auswege

Der Handshake ist frisch in wg show, der Endpunkt stimmt, die Schlüssel wurden nie geändert — und ping meldet weiterhin keine Route zum Peer. Sie haben das Tunnel-Subnetz vor einer Stunde geändert. Dieses Symptom ist die Signatur einer Präfix-Abweichung und kein Schlüsselproblem: WireGuard hat den Handshake abgeschlossen und dann die Daten verworfen, weil eine Quelladresse nicht mehr zu dem passt, was der empfangende Peer akzeptiert. Es gibt zwei vernünftige Wege, einen Subnetzwechsel umzusetzen, und sie scheitern an unterschiedlichen Stellen.

Zwei Wege, die Änderung umzusetzen, und was jeder kostet

Option A ist Umnummerierung an Ort und Stelle: Schnittstellenadresse, Peer-Bereiche, Routen und jede Kopie der Konfiguration bearbeiten, dann neu laden. Option B ist, eine zweite Schnittstelle auf dem neuen Präfix neben der alten aufzubauen, Peers hinüberzuziehen und die alte Schnittstelle zu entfernen, sobald der Verkehr tatsächlich umgezogen ist.

Der halb angewandte Zustand macht Option A gefährlich, weil er nicht kaputt aussieht. Die Schnittstelle kommt hoch, der Handshake gelingt, und nur der Datenpfad scheitert. Option B kostet mehr Arbeit, hält aber einen funktionierenden Pfad am Leben, während Sie jede Referenz finden.

Was sich auf Ihrer Seite gemeinsam bewegen muss

Vier Dinge auf dem lokalen Host beschreiben dasselbe Subnetz, und eine Änderung an einem ist eine Änderung an allen: die Adresse der Schnittstelle, die AllowedIPs jedes Peers, die Route, die das System für diese Ziele nutzt, und was auch immer der Manager in Ihrem Namen installiert. Mit wg-quick werden die letzten beiden bei jedem Hochfahren der Schnittstelle aus der Konfiguration erzeugt, sodass eine veraltete Kopie das alte Präfix still wiederherstellt.

Vergleichen Sie das Konfigurierte mit dem Aktiven, statt einem von beiden zu vertrauen:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

Die Routenabfrage ist der Schritt, den Leute überspringen. Sie beantwortet, was der Kernel für ein Ziel tatsächlich täte, einschließlich einer spezifischeren Route, die ein Manager oder eine Container-Laufzeit hinterlassen hat. Meldet sie eine andere Schnittstelle als den Tunnel, ist nicht die Konfiguration das Problem.

Wenden Sie bei einer laufenden Schnittstelle die bearbeitete Datei an, ohne den Tunnel abzureißen:

wg syncconf wg0 <(wg-quick strip wg0)

Das aktualisiert Peers und Bereiche an Ort und Stelle. Es aktualisiert nicht die Schnittstellenadresse oder die Routen, weil das keine WireGuard-Einstellungen sind — eine Umnummerierung braucht also weiterhin eine neu erstellte Schnittstelle oder eine mit ip geänderte Adresse und danach eine erneute Prüfung des Routings.

Was sich am fernen Ende gemeinsam bewegen muss

Hier stirbt ein Subnetzwechsel normalerweise. AllowedIPs ist nicht nur ein Routing-Hinweis; es ist auch die Liste der Quelladressen, die ein Peer vortragen darf. Wenn Sie Clients umnummerieren und die AllowedIPs des Servers auf dem alten Präfix lassen, nimmt der Server den Handshake an, empfängt die verschlüsselten Pakete und verwirft sie, weil die innere Quelle zu keinem Bereich passt, den er mit diesem Peer verbindet. Es wird kein Fehler protokolliert, und der Client sieht einen Timeout.

Aktualisieren Sie die Empfangsseite also bewusst: Der Peer-Eintrag auf dem Server muss das neue Client-Präfix aufführen, die eigene Rückroute des Servers muss für dieses Präfix auf den Tunnel zeigen, und jedes nachgelagerte Netz hinter dem Server muss den neuen Pfad lernen. Firewall-Regeln, die den alten Bereich genannt haben, brauchen dieselbe Behandlung, ebenso alles, was quellbasierte Auswahl betreibt.

Die Diagnose, die beide Fehler trennt, ist billig. Ein frischer Handshake ohne Daten bedeutet, dass der Tunnel steht und die innere Adressierung nicht übereinstimmt. Gar kein Handshake bedeutet, dass Sie auf Erreichbarkeit oder Schlüssel schauen. Rotieren Sie keine Schlüssel wegen eines Präfixproblems; das setzt das Einzige zurück, was funktioniert hat.

Veraltete Kopien, die Ihre Bearbeitung überleben

Eine Datei zu bearbeiten ist nicht dasselbe wie das laufende System zu ändern, und die Kopien sind zahlreicher, als Leute erwarten: die Unit oder der Manager, dem die Schnittstelle gehört, ein zweites Profil mit demselben Namen in einem anderen Verzeichnis, ein Container mit in ein Image eingebackener Konfiguration, eine Router-Oberfläche mit ihrer eigenen bearbeiteten Version und eine Client-App, die beim Start einen gespeicherten Tunnel erneut importiert. Jede davon kann das alte Präfix wiederherstellen, nachdem Ihre Änderung fertig aussieht.

Auch Namen reisen. Wenn die numerische Route funktioniert, aber der Hostname scheitert, zeigt ein interner DNS-Eintrag oder eine Dienstkonfiguration noch auf die alte Tunneladresse. Korrigieren Sie die Referenz, statt jeden Peer-Bereich zu erweitern, was das eigentliche Problem zudecken und gleichzeitig die Quell-ACL vergrößern würde.

Halten Sie einen Wiederherstellungspfad offen, während Sie arbeiten: ein zweiter Weg auf den Host, eine serielle Konsole oder ein geplantes Zurückrollen der Konfigurationsdateien. Ein Tunnelwechsel, der Sie aus der Maschine aussperrt, die Sie ändern, ist der häufigste Weg, aus dieser Aufgabe einen Abend zu machen.

Die Wahl zwischen beiden und die Prüfung des Schnitts

Wählen Sie A, wenn Ihnen jeder Peer gehört, die Zahl klein ist und eine kurze Ausfallzeit akzeptabel ist. Wählen Sie B, wenn Peers entfernte Hände sind, die Sie nicht kontrollieren, wenn eine Standort-zu-Standort-Verbindung bestehen bleiben muss oder wenn Sie nicht garantieren können, dass jede Kopie in einem Durchgang aktualisiert wird. Fügen Sie in diesem Fall das neue Präfix beiden Schnittstellen hinzu, ziehen Sie Peers einzeln um, beobachten Sie den Verkehr auf der neuen und entfernen Sie erst dann die alte Schnittstelle und ihre Routen.

Unter beiden Optionen ist die Änderung fertig, wenn vier Prüfungen bestehen: der Handshake ist frisch, die Routenabfrage für ein Ziel des neuen Präfixes nennt den Tunnel, eine Nutzlast von ein paar hundert Bytes geht in beide Richtungen über, und dasselbe gilt nach einem Neustart des Hosts oder des Managers. Das wg(8)-Handbuch ist die Referenz dafür, was AllowedIPs in jeder Richtung bedeutet, und es lohnt sich, es erneut zu lesen, bevor Sie einen Bereich erweitern, damit ein Symptom verschwindet.

• Frischer Handshake und keine Daten: Sehen Sie sich die AllowedIPs beim Empfänger an, bevor Sie Schlüssel anfassen.
• Routenabfrage zeigt auf die falsche Schnittstelle: Ein Manager oder Container besitzt die Route, nicht Ihre Datei.
• Numerische Adresse in Ordnung und Hostname kaputt: eine alte Referenz, keine Routing-Schleife.
• Die Änderung ist erst vollständig, wenn ein Neustart weiterhin das neue Präfix nutzt.