WireGuard-Host-Präfix: Warum eine Adresse funktioniert und die übrigen nicht

Der Tunnel steht, der Handshake läuft alle zwei Minuten, und genau eine Adresse auf der anderen Seite antwortet. Pings auf die Tunneladresse des Peers funktionieren; alles dahinter nicht. Jemand liest die Interface-Konfiguration, sieht ein Host-Präfix und schließt daraus, dass die Maske falsch ist. Sie auf ein /24 zu erweitern behebt den Ping für eine Weile und bricht dann etwas anderes. Das Präfix war nie die Ursache, und die fehlende Route ist nicht die, die die Maske steuert.

Was das Interface-Präfix tatsächlich erzeugt

Unter Linux erzeugt das Zuweisen einer Adresse an ein Interface eine verbundene Route für dieses Präfix. Weist du ein Host-Präfix zu, deckt die verbundene Route eine Adresse ab. Weist du ein /24 zu, deckt sie 256 ab, und jede davon gilt nun über diesen Link als erreichbar.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Ein Host-Präfix ist für einen Punkt-zu-Punkt-Tunnel eine völlig normale Wahl, denn am anderen Ende gibt es genau einen Peer. Der dritte Befehl ist derjenige, der die Frage des Nutzers beantwortet: Er sagt, welches Interface der Kernel für dieses Ziel verwenden würde, und er zeigt nichts Nützliches, wenn keine Route passt.

Das ist die ganze Erklärung für das Symptom. Eine Adresse antwortet, weil für sie eine verbundene Route existiert oder weil die erlaubte Liste des Peers sie zufällig enthält. Für alles andere gibt es keine Route, und es wird verworfen, bevor WireGuard überhaupt beteiligt ist. Der Tunnel ist dabei durchgehend gesund, weshalb der Handshake-Zähler weiter beruhigend aussieht.

AllowedIPs sind zwei Regeln unter einem Namen

Die erlaubte Liste pro Peer in WireGuard erledigt zwei Aufgaben gleichzeitig, und die Konfigurationssyntax lässt sie wie eine aussehen. Eingehend legt sie fest, welche Quelladressen ein Peer präsentieren darf. Ausgehend wählt sie aus, an welchen Peer ein Paket geht, indem sie die spezifischste Übereinstimmung sucht.

Keine der beiden Aufgaben ist Routing. Der Kernel muss weiterhin entscheiden, dass ein Paket auf das Tunnel-Interface gehört, bevor WireGuard es überhaupt ansieht, und diese Entscheidung kommt aus der Routing-Tabelle. Ein Peer-Eintrag mit einer breiten erlaubten Liste installiert nicht von selbst eine Route.

Deshalb kann eine Konfiguration vollständig aussehen und sich asymmetrisch verhalten. Der Client sendet zur Gegenseite, weil eine Route existiert, und Antworten kommen nie an, weil die erlaubte Liste der Gegenseite die Quelle des Clients nicht zulässt oder die Gegenseite keinen Rückweg hat. Beide Richtungen sind getrennte Entscheidungen mit getrennten Fehlerbildern. Aufzuschreiben, welche man gerade testet, ist die halbe Diagnose.

Woher die Route kommt

Wenn du wg-quick verwendest, werden die Routen für dich aus der erlaubten Liste jedes Peers erzeugt, es sei denn, du hast Table = off gesetzt und die Kontrolle selbst übernommen. Das ist das dokumentierte Verhalten des Werkzeugs, und es ist der Grund, warum eine Konfiguration ohne ausdrückliche Routenanweisungen trotzdem funktioniert.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Vergleiche die erlaubte Liste mit den tatsächlich vorhandenen Routen. Ein Peer, der ein ganzes Subnetz erlaubt, aber nur eine Host-Route erzeugt hat, bedeutet, dass der Helfer nie lief, oder dass du das Interface direkt mit wg und ip verwaltest; dann erzeugt nichts Routen für dich.

Wenn du es von Hand verwaltest, ist die Route eine Zeile und ihre Form ausdrücklich: das Ziel über das Interface, ohne Gateway, weil der Link Punkt-zu-Punkt ist. Sie hinzuzufügen ist kein Notbehelf für ein schlechtes Präfix; es ist die fehlende Hälfte eines Entwurfs, der das Routing bewusst selbst übernimmt.

Ein breiteres Präfix fügt den Peer-Eintrag nicht hinzu

Die naheliegende Lösung ist, die Adresse auf ein /24 zu ändern, damit die verbundene Route das LAN des Servers abdeckt. Es scheint zu funktionieren, und der Grund dafür ist, dass die verbundene Route nun passt, nicht dass WireGuard etwas Neues gelernt hätte.

Was du außerdem getan hast: Du beanspruchst den ganzen Bereich als über diesen Link direkt erreichbar, einschließlich Adressen, die zu anderen Peers gehören oder zu einem LAN, das tatsächlich hinter dem Server liegt. Verkehr zu diesen Adressen gelangt nun in den Tunnel, und ob er auf der anderen Seite herauskommt, hängt vom Routing und den erlaubten Listen des Servers ab.

Die Kryptoseite ist in beide Richtungen unberührt. WireGuard braucht weiterhin einen Eintrag in der erlaubten Liste, der das Ziel abdeckt, um einen Peer zu wählen, und die Gegenseite braucht weiterhin einen Eintrag, der deine Quelle abdeckt, um sie zu akzeptieren. Ein breiteres Interface-Präfix kann keines von beidem liefern.

Bestätige beide Richtungen, bevor du etwas änderst

Bearbeite die beiden Enden getrennt und schreibe auf, was jedes sagt. Auf dem Client die Route und der Peer-Eintrag; auf dem Server das Spiegelbild plus sein eigener Rückweg:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Der Mitschnitt ist das, was Streitigkeiten über die Richtung entscheidet. Wenn ausgehende Pakete am Tunnel-Interface erscheinen und der Server nichts protokolliert, verwirft das ferne Ende sie, meist weil deine Quelle außerhalb seiner erlaubten Liste liegt. Wenn überhaupt nichts erscheint, fehlt die Route oder sie zeigt woandershin.

Dann repariere das schmalste Ende. Ein Eintrag in der erlaubten Liste auf Serverseite für deine Client-Adresse und ein Eintrag auf Clientseite für das Ziel-Subnetz ist die normale Form, und sie lässt das Interface-Präfix unangetastet. Erweitere das Präfix nur, wenn der Adressplan wirklich ein gemeinsames Subnetz auf diesem Link will, und tue es als Planänderung statt als Debugging-Schritt.