Zwei WireGuard-Peers teilen sich einen Bereich: Wer bekommt das Paket

Zwei Peers listen Bereiche auf, die sich berühren, und der Verkehr erreicht den falschen. Nichts ist beschädigt: WireGuard wählt einen Peer, indem es das Ziel mit den konfigurierten Bereichen abgleicht, und die spezifischste Übereinstimmung gewinnt. Bevor du etwas erweiterst, entscheide, welcher Peer welches Präfix besitzen soll.

Das längste Präfix gewinnt innerhalb von WireGuard

Jeder Peer-Eintrag trägt eine Menge von Zielpräfixen. Wenn ein Paket in die Schnittstelle geroutet wird, sucht die Implementierung den Eintrag mit dem spezifischsten passenden Präfix — dieselbe Regel, die eine Routingtabelle anwendet. Ein /24 schlägt daher ein /16, das es enthält, und der engere Peer erhält den Verkehr.

Road-Warrior-Setups nutzen dies gezielt. Ein Peer besitzt einen breiten Bereich für einen Standort, und einzelne Hosts werden mit /32-Einträgen herausgetrennt, die zu anderen Peers gehören. Das Muster funktioniert, weil die Ausnahmen spezifischer sind, nicht wegen der Reihenfolge.

Halte die Zuständigkeit als Tabelle aus Präfix und Peer fest. Wenn zwei Einträge dasselbe Präfix beschreiben, drückt die Konfiguration keine Absicht mehr aus, sondern ein Rennen.

Das Betriebssystem wählt zuerst die Schnittstelle

WireGuard wählt nur unter den Peers auf einer Schnittstelle. Welche Schnittstelle das Paket erhält, entscheidet sich früher, durch die Routingtabelle des Hosts, und eine zweite Standardroute oder eine veraltete Route kann den Verkehr dorthin schicken, wo die Peer-Liste ihn nie sieht. Deshalb kann eine Diagnose auf Peer-Ebene korrekt sein und den Fehler trotzdem nicht erklären. Prüfe die Route zum Ziel, bevor du die Peer-Konfiguration liest, denn eine Route, die auf die physische Schnittstelle zeigt, umgeht die ganze Frage.

Das Werkzeug installiert diese Routen normalerweise aus den Peer-Bereichen, was bedeutet, dass eine Änderung an der Liste eines Peers Verkehr, der zuvor zu einem anderen gehörte, stillschweigend umleiten kann. Das Bearbeiten eines Peers ist also eine Routenänderung in Verkleidung. Prüfe beides gleichzeitig, sonst reparierst du das eine und brichst das andere.

Eingehende Pakete werden anhand der Quelle geprüft

Die Bereichsliste erfüllt einen doppelten Zweck. Für ausgehenden Verkehr wählt sie einen Peer nach Ziel, für eingehenden Verkehr autorisiert sie eine Quelladresse. Ein Paket, das von einer Adresse außerhalb der Bereiche dieses Peers eintrifft, wird verworfen, bevor eine Firewall es sieht.

Diese Asymmetrie übersieht man leicht, wenn man nur eine Seite der Konfiguration liest. Ein Peer, der ein Subnetz erreichen kann, darf deshalb noch nicht von diesem Subnetz senden, und die beiden Richtungen werden durch unterschiedliche Prüfungen erzwungen.

Enger Quellbesitz macht daraus einen Vorteil. Gib jedem Peer ein /32 für seine eigene Adresse, und die Firewall dahinter hat eine vertrauenswürdige Quelle zum Abgleichen, statt eines gruppenweiten Bereichs, den jedes Mitglied beanspruchen könnte.

Doppelte Bereiche sind kein Failover

Dasselbe Präfix zwei Peers zuzuweisen, schafft weder einen Lastverteiler noch einen Standby-Pfad. Es gibt keine Zustandsprüfung und keine Sitzungsaffinität: Welcher Eintrag gewinnt, entscheidet die interne Reihenfolge der Implementierung, und das ist kein Vertrag, auf den man bauen sollte. Wenn du alternative Ausgänge brauchst, drücke sie dort aus, wo die Auswahl definiert ist. Eine Routing-Richtlinie, eine Metrik oder zwei unterschiedliche Präfixe mit je einem dokumentierten Eigentümer erzeugen Verhalten, das du vorhersagen und testen kannst.

Einen Bereich zu erweitern, um einen unabhängigen Fehler zu beheben, ist der andere häufige Fehler. Er verschiebt Verkehr weg von dem Peer, der funktionierte, und das neue Symptom kommt, bevor das alte verstanden ist.

Prüfe die Auswahl, bevor du bearbeitest

Drei Befehle beantworten die drei Fragen der Reihe nach. Der erste listet die Bereiche auf, die jeder Peer beansprucht. Der zweite zeigt, welche Schnittstelle der Host für ein Ziel verwenden würde. Der dritte zeigt den Live-Peer-Zustand, nachdem Verkehr geflossen ist.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Führe sie vor und nach einer Änderung aus und vergleiche. Wenn sich die Routenausgabe geändert hat, der Verkehr aber weiterhin beim falschen Peer ankommt, überlappen sich die Präfixlisten auf eine Weise, die du noch nicht aufgeschrieben hast. Wenn sich die Routenausgabe nicht geändert hat, war die Peer-Konfiguration nie das, was befragt wurde.

Halte Ziel, gewählte Schnittstelle und gewählten Peer im Ticket fest. Diese Dreiergruppe macht eine Überlappung später überprüfbar und ist weit nützlicher als ein Screenshot der Konfiguration.