wg-quick bricht DNS beim Verbinden: den Setup-Fehler lesen

Der Tunnel kommt hoch, der Handshake schließt ab, und die Namensauflösung stoppt. In der Peer-Konfiguration hat sich nichts geändert, weil die DNS-Zeile nie Teil der Peer-Konfiguration war. Sie gehört zum Setup-Helfer, was bedeutet, dass der Fehler in der Resolver-Umgebung des Hosts liegt und nicht in den Schlüsseln von WireGuard.

Lesen Sie die erste Meldung, die der Helfer ausgegeben hat, nicht die letzte, dann wird der Unterschied zwischen einem fehlenden Werkzeug und einem unerreichbaren Server offensichtlich.

Die DNS-Zeile ist eine Funktion des Helfers

Die Kernfelder der Konfiguration beschreiben Peers, Schlüssel und erlaubte Adressen. Die Namensauflösung wird obendrauf von dem Skript ergänzt, das die Schnittstelle hochbringt, und jede Implementierung macht das anders. Ein Desktop-Client kann DNS über seinen eigenen Dienst verwalten, ein Distributionsskript kann eines von mehreren Resolver-Werkzeugen aufrufen, und ein Container tut vielleicht weder das eine noch das andere. Die Konfigurationsdatei kann Ihnen nicht sagen, welcher dieser Wege im Spiel ist.

Deshalb kann eine Konfigurationsdatei für das Protokoll gültig sein und trotzdem beim Setup scheitern: Der Fehler gehört zu einem Hook, den das Protokoll nie sieht.

Ein erweitertes Feld in eine Kernkonfiguration zu schreiben und zu erwarten, dass das Protokollwerkzeug es akzeptiert, erzeugt dieselbe Verwirrung aus der umgekehrten Richtung. Die beiden Parser lesen verschiedene Dateien.

Zu wissen, welcher läuft, ist der erste Diagnoseschritt, und er ist meist im getippten Befehl sichtbar und nicht in der Konfigurationsdatei.

Lesen Sie den ersten Fehler, den der Helfer ausgibt

Bringen Sie die Schnittstelle im Vordergrund hoch und lesen Sie die Ausgabe der Reihe nach. Ein fehlendes Resolver-Werkzeug, ein gescheiterter Hook und ein unerreichbarer Server stoppen denselben Befehl an verschiedenen Stellen, und jede Ursache hat ihre eigene Reparatur.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

Der erste Befehl meldet den Fortschritt des Setups, der zweite zeigt, welche Server die Schnittstelle jetzt beansprucht, und der dritte zeigt, ob die Resolver-Adresse tatsächlich durch den Tunnel erreichbar ist. Ein Resolver, der konfiguriert, aber nicht routbar ist, erzeugt Zeitüberschreitungen statt Konfigurationsfehler, weshalb die beiden Prüfungen zusammengehören. Nur die Statusausgabe zu lesen führt zu einem selbstsicheren und falschen Schluss.

Wenn das Setup abgeschlossen ist und die Namensauflösung weiterhin scheitert, vergleichen Sie den vom Helfer installierten Resolver mit dem, den das Netzwerk vorher nutzte. Ein privater Resolver braucht eine Route durch den Tunnel, und eine Konfiguration, die ihn auflistet, ohne sein Präfix abzudecken, lässt jede Abfrage warten.

Welchen Resolver der Host tatsächlich hat

Moderne Linux-Hosts betreiben häufig einen lokalen Stub-Resolver, sodass die Adresse, die der Helfer installiert, von diesem Stub verbraucht wird und nicht direkt von Anwendungen. Eine generierte Datei von Hand zu bearbeiten, kann zu funktionieren scheinen, bis zur nächsten Wiederverbindung, wenn der Helfer sie neu schreibt.

Nutzen Sie die unterstützte Integration für die Distribution und lassen Sie eine Komponente den Resolver-Zustand besitzen. Zwei Besitzer erzeugen dasselbe Rennen wie zwei Besitzer einer Schnittstellenadresse, und das Symptom ist ein Host, der nach jeder Änderung einige Minuten lang korrekt auflöst.

Interne Namen verdienen eine eigene Prüfung. Ein öffentlicher Resolver kann das allgemeine Surfen wiederherstellen, während jeder Firmenname scheitert, was das Gegenteil dessen ist, wofür der Tunnel gedacht war. Fragen Sie den vorgesehenen Server nach dem internen Namen, bevor Sie schließen, dass DNS repariert ist.

Bereinigung ist genauso wichtig wie das Setup

Nehmen Sie die Schnittstelle herunter und prüfen Sie den Resolver-Zustand erneut. Ein Helfer, der die vorherige Konfiguration wiederherstellt, hinterlässt einen nutzbaren Host; einer, der seine eigenen Server zurücklässt, erzeugt den nächsten Fehler, oft Stunden später, wenn der Tunnel längst weg ist.

Veralteter Zustand ist leicht zu erkennen, sobald man danach sucht. Eine Resolver-Liste kann auf eine Adresse an einer Schnittstelle zeigen, die es nicht mehr gibt, und eine Suchdomäne kann ein Netzwerk überleben, das Sie heute Morgen verlassen haben. Beides macht die nächste Verbindung unvorhersehbar, und keines davon erscheint in der eigenen Statusausgabe des Tunnels. Die Prüfung dauert zehn Sekunden und spart der nächsten Person eine Stunde.

Halten Sie die Diagnose von der Reparatur getrennt. Wenn jedes Ziel scheitert und nicht nur Namensabfragen, sind Routen und Weiterleitung die Verdächtigen, und die DNS-Zeile ist eine Ablenkung. Das wg-quick-Handbuch dokumentiert, welche Felder es behandelt und welche zum Protokoll gehören, und diese Grenze ist die ganze Antwort auf die meisten dieser Berichte.