WireGuard nutzt nach DNS-Änderungen weiterhin den alten Endpunkt

Der Tunnel leitete keinen Verkehr mehr weiter, nachdem sich der DNS-Eintrag des Servers verschoben hatte, und der Name wird vom selben Rechner aus korrekt aufgelöst. Diese beiden Tatsachen widersprechen sich nicht. Eine WireGuard-Konfiguration enthält einen Endpunkt, und das Werkzeug löst den Namen in dem Moment auf, in dem es diese Konfiguration anwendet, sodass die laufende Schnittstelle weiter die Adresse verwenden kann, die sie vor Stunden ermittelt hat. Prüfen Sie, was die Schnittstelle verwendet, bevor Sie Schlüssel ersetzen oder den Tunnelbereich anfassen.

Der Name wird einmal aufgelöst, nicht fortlaufend

Die WireGuard-Grundkonfiguration nimmt einen Endpunkt als Adresse und Port, und das Werkzeug, das eine Schnittstelle hochzieht, löst zu diesem Zeitpunkt einen Hostnamen auf. Nichts im Basisprotokoll fragt DNS nach einem Zeitplan ab, und eine Client-Anwendung kann obendrauf ein eigenes Aktualisierungsverhalten legen. Das Auflösen von Adresse, Adressfamilie und Port neben dem Namen macht die Lücke sichtbar. Ohne diesen Eintrag wirkt die Konfiguration korrekt, während die Schnittstelle mit etwas anderem spricht.

Es gibt eine echte automatische Aktualisierung, und sie ist wissenswert, weil sie wie eine DNS-Aktualisierung aussieht, ohne eine zu sein. Ein Peer-Endpunkt kann sich verschieben, wenn korrekt authentifizierter Verkehr von einer neuen Adresse eintrifft, was Roaming und keine Namensauflösung ist. Er folgt dem Peer, kann also keinen unabhängigen neuen Server entdecken, den der alte Endpunkt nie kontaktiert hat.

Vergleichen Sie den Eintrag mit der verwendeten Adresse

Fragen Sie den dokumentierten Namen über den Resolver ab, den der Client verwendet, und fragen Sie dann die Schnittstelle, welchen Endpunkt sie hält. Die beiden Antworten sind der Vergleich, der den Rest dieser Seite entscheidet:

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

Die Handbuchseite zu wg(8) dokumentiert die Unterbefehle show, die diese Zeilen verwenden. Vergleichen Sie auch die Adressfamilie und nicht nur die Adresse, denn ein Eintrag, der einen IPv6-Eintrag dazubekommen hat, ist ein anderer Vergleich als einer, dessen IPv4-Adresse sich geändert hat. Weicht der Endpunkt vom Eintrag ab, läuft die Schnittstelle mit veralteten Informationen, und der Name war nie das Problem. Stimmen sie überein und schlägt der Tunnel weiterhin fehl, gehen Sie zum Listener und den Regeln statt zum Profil.

Der Zeitstempel des Handshakes steht in diesem Block, weil der Endpunkt allein nicht sagt, ob der Peer erreichbar ist. Ein veralteter Zeitstempel neben einem korrekten Endpunkt ist ein Pfadproblem, kein Auflösungsproblem, und dieser Unterschied ändert, was Sie als Nächstes anfassen.

Starten Sie über den Manager der Schnittstelle neu

Sobald der Endpunkt als veraltet bestätigt ist, aktualisieren Sie ihn über den Mechanismus, dem die Schnittstelle gehört, statt die laufende Konfiguration zu bearbeiten. Bei einer von wg-quick gestarteten Schnittstelle ist das ein Down und Up, bei einer systemd-Unit ein Neustart, und bei einer Schnittstelle, die einem Manager gehört, eine Änderung in diesem Manager, weil eine Bearbeitung zur Laufzeit beim nächsten Anwenden überschrieben wird:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

Bestätigen Sie dann, dass der ersetzende Listener und seine Identität der beabsichtigte Dienst sind. Ein DNS-Umzug ist keine Identitätsänderung, also sollte er nie der Anlass sein, einem Schlüssel zu vertrauen, den Sie nicht geprüft haben. Meldet die Schnittstelle jetzt die neue Adresse und entsteht weiterhin kein Handshake, ist der Fehler auf den neuen Netzwerkpfad oder Listener gewandert, was Fortschritt und nicht derselbe Fehler zweimal ist.

Erst der Handshake, dann der Datenpfad

Trennen Sie die beiden Ergebnisse, bevor Sie eine Prüfliste wählen. Ein Handshake, der unter einer fehlschlagenden Anwendung gelingt, ist ein Datenpfadproblem: Routen, erlaubte Präfixe oder DNS innerhalb des Tunnels. Ein Handshake, der nie stattfindet, ist ein Erreichbarkeits- oder Identitätsproblem am Endpunkt. Beides zu vermischen ergibt einen Bericht, den niemand reproduzieren kann, und ein Änderungsprotokoll mit drei unabhängigen Bearbeitungen.

Notieren Sie den Namen, die aufgelöste Adresse, den verwendeten Endpunkt und ob der Handshake abgeschlossen wurde. Diese vier Fakten beantworten die Frage, die dieser Fehler immer wieder stellt, und machen den nächsten Fall zu einer Zwei-Minuten-Prüfung. Namenspflege und Client-Einführung bleiben getrennte Aufgaben: den Eintrag zu korrigieren führt die Einführung nicht aus, und die Schnittstelle neu zu starten repariert keinen Eintrag, der noch falsch ist.