WireGuard: Volltunnel – AllowedIPs 0.0.0.0/0 allein reicht nicht

Der Schritt, den alle kennen, ist 0.0.0.0/0, ::/0 in die AllowedIPs eines Peers zu schreiben, und er entscheidet nur, welchen Verkehr der Peer tragen darf. Diese Präfixe erzeugen keine Routen, leiten auf der Gegenseite nichts weiter und lassen den Resolver jeder Anwendung genau dort, wo er war. Vier getrennte Dinge müssen gleichzeitig gelten, damit ein Volltunnel ein Volltunnel ist, und sie lassen sich am besten in der Reihenfolge unten prüfen, weil eine spätere Prüfung eine frühere nicht retten kann. Jede Prüfung unten ist ein Fakt, den man an einer Maschine ablesen kann, keine Einstellung, von der man hofft, dass sie angewendet wurde.

Was das Peer-Präfix auswählt und was nicht

AllowedIPs ist zugleich Selektor und Berechtigung. Es sagt der lokalen Seite, welche Ziele an diesen Peer gesendet werden dürfen, und der empfangenden Seite, welche Quelladressen dieser Peer vorweisen darf. Das ist die ganze Aufgabe. Nichts in dieser Beschreibung legt eine Route auf dem Host an, aktiviert Weiterleitung auf der Gegenseite oder berührt die Namensauflösung.

Deshalb kann eine Konfiguration vollständig aussehen und sich wie ein Split-Tunneling verhalten. Das Präfix besagt, dass der Peer alles annehmen würde; die Routentabelle des Hosts entscheidet, was dort tatsächlich ankommt, und das Gateway entscheidet, ob etwas hinausgeht. Keine dieser drei Entscheidungen liegt im Peer-Abschnitt.

Den Client routen, nicht nur die Peer-Liste

Verwaltungen wie wg-quick programmieren die Routentabelle des Hosts für Sie, weshalb sich zwei identische Konfigurationsdateien unterschiedlich verhalten, je nachdem, wie die Schnittstelle hochkam. Ein minimales Profil ist kurz genug, um es in einem Zug zu lesen:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Zwei Details tragen die Arbeit. Das Feld Address ist ein einzelnes Host-Präfix und kein Subnetz, das der Client zu besitzen glaubt, und die Verwaltung ist es, die die Standard-AllowedIPs in eine echte Standardroute umwandelt. Bringen Sie dieselbe Datei mit ip link und wg setconf hoch, erscheinen überhaupt keine Routen, was wie ein defekter Tunnel aussieht und in Wahrheit ein gesunder ist, bei dem der Routenschritt übersprungen wurde. Das Handbuch zu wg-quick dokumentiert die Weiterleitung und das Table Verhalten, das diese Verwaltungen hinzufügen.

Lesen Sie das Ergebnis statt der Datei: ip route get 1.1.1.1 sollte die Tunnelschnittstelle nennen, und wg show sollte einen frischen Handshake mit einem laufenden Übertragungszähler melden. Ein Handshake ohne Route bedeutet, dass die Verwaltung nie lief, und ein erneutes Bearbeiten des Profils wird das nicht beheben. Starten Sie die Schnittstelle so, wie der Benutzer sie starten wird, sonst misst der Test Ihre Shell statt des Deployments.

Den Endpunkt außerhalb des Tunnels halten

Ein Volltunnel fängt jedes Ziel ab, auch das, mit dem er sprechen muss, um zu existieren. Verwaltungen lösen das, indem sie eine Host-Route für den Endpunkt über das ursprüngliche Gateway hinzufügen, weshalb eine korrekte Konfiguration fast immer genau eine bewusste Ausnahme enthält. Die halbe Konfiguration mit einer Verwaltung und die andere Hälfte von Hand anzuwenden ist der übliche Weg, auf dem diese Ausnahme verloren geht.

Ist der Endpunkt ein Hostname, der sich in mehrere Adressen auflöst, oder in eine Familie, die Sie nicht tragen, altert die Ausnahme schlecht, und der Tunnel kann nach einer Wiederverbindung scheitern, die routinemäßig aussah. Nageln Sie den Endpunkt auf eine Adresse fest, die Sie kontrollieren, oder bestätigen Sie, dass die Verwaltung ihn neu bewertet, und lesen Sie die Host-Route nach jeder Netzwerkänderung erneut.

Derselbe Mechanismus erklärt, warum ein Volltunnel und ein Captive Portal sich streiten. Das Portal erwartet, den Verkehr abzufangen, den Ihr Tunnel jetzt fängt, also bringen Sie den Tunnel in Hotel- und Flughafennetzen nach dem Portal-Login hoch, nie davor.

Weiterleitung und Rückweg am Gateway

Aktivieren Sie am Gateway die Weiterleitung für die Familie, die Sie tragen, erlauben Sie die Forward-Kette in beide Richtungen, wenn Sie übersetzen, und bestätigen Sie den Rückweg mit einer quellenspezifischen Suche. Nichts davon folgt aus einem erfolgreichen Handshake, denn ein Handshake beweist nur, dass die beiden Peers UDP austauschen können. Er sagt nichts darüber, was danach mit dem entkapselten Paket geschieht.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Die Suche läuft am Gateway und nicht am Client, sonst lesen Sie eine andere Routentabelle. Wenn sie die falsche Schnittstelle nennt oder keine Route meldet, dann wird keine Änderung auf der Clientseite einen Internet-Ausgang erzeugen. Wenn das Gateway Client-Adressen auf dem Weg nach draußen übersetzt, hängt die Antwort von diesem Übersetzungszustand ab, also muss die Regel für beide Richtungen des Flusses existieren und nicht nur für die ausgehende.

DNS und der Fehlerzustand, getrennt getestet

Das Protokoll selbst konfiguriert keinen Resolver einer Anwendung. wg-quick wendet die Zeile DNS über die Resolver-Integration der Distribution an, Container und Browser mit eigenen Stapeln ignorieren sie möglicherweise, und ein Name kann daher scheitern, während der Tunnel Pakete einwandfrei trägt. Testen Sie mit einem Hostnamen statt mit einer Adresse, und notieren Sie, welcher Server geantwortet hat, statt anzunehmen, dass es der aus dem Profil war.

Adressfamilien sind ein eigener Test mit eigener Antwort. Eine v4-Standardroute sagt nichts darüber, was die v6-Verbindung einer Anwendung tun wird, und ein Tunnel, der die zweite Familie still verrät, ist schlechter als einer, der laut scheitert. Fragen Sie einen Namen über jede Familie ab, lesen Sie die Schnittstelle, die jede Anfrage benutzt hat, und prüfen Sie die Übersetzungszähler vorher und nachher, denn eine Regel, die auf nichts passt, sieht aus wie eine fehlende Regel.

Testen Sie schließlich den Zustand, den Sie wollen, wenn der Tunnel stoppt. Ein Volltunnel sollte für den Verkehr, den er beansprucht, geschlossen scheitern: Wenn die Schnittstelle ausfällt und Anwendungen still über die physische Verbindung weiterlaufen, ist das Design ein Split-Tunneling mit Extraschritten. Schreiben Sie das beabsichtigte Fehlerverhalten auf, prüfen Sie es bewusst, und schließen Sie mit den vier Antworten ab — welche Verwaltung die Schnittstelle hochbringt, welche Route den Standard trägt, wer am Gateway weiterleitet und übersetzt, und welcher Resolver antwortet.