WireGuard-Peer verlässt über den falschen WAN: fünf Prüfungen in Reihenfolge

Zwei Uplinks, ein Gateway und ein WireGuard-Peer, dessen Verkehr immer wieder auf der Backup-Leitung auftaucht. Der Handshake bleibt durchweg gesund. Deshalb lässt sich das Symptom leicht als WireGuard-Fehler statt als Routingfehler missdeuten.

Arbeiten Sie die folgenden Prüfungen in Reihenfolge ab. Jede hat eine Abbruchbedingung, und wer vorgreift, erhält meist eine selbstsichere falsche Antwort.

Trennen Sie den Handshake vom weitergeleiteten Fluss

Der verschlüsselte Peer-Austausch hat eine Endpunkt-Route zur öffentlichen Adresse des Servers. Weitergeleiteter Client-Verkehr hat ein anderes Ziel und kann durch Markierungen oder Policy-Regeln ausgewählt werden. Das sind zwei Routingentscheidungen, die sich eine Schnittstelle teilen. Die eine als Beweis über die andere zu behandeln, ist der erste Fehler.

Halten Sie an, sobald Sie sich dabei ertappen, vom Handshake aus zu argumentieren. Er ist nur ein Beweis über den Endpunktpfad.

Lesen Sie die Policy-Regel, nicht die Standardtabelle

Eine Standardtabelle zeigt, was passiert, wenn keine Policy-Regel passt. Auf einem Gateway, das nach Quelle, Markierung oder Ziel routet, lebt die entscheidende Regel woanders. Die einfache Tabelle kann völlig vernünftig aussehen, während die eigentliche Wahl darüber getroffen wird.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Lesen Sie die Policy-Regeln und die Tabellen, auf die sie verweisen. Bestätigen Sie dann, welche Regel zu Ihrem Testfluss passt. Eine Regel, die auf eine Schnittstelle verweist, die den vorgesehenen Uplink nicht mehr trägt, ist ein Befund und kein Detail. Die Routensuche am Ende zeigt die Antwort viel schneller als eine Tabelle zu lesen und zu raten.

Prüfen Sie Markierung und Übersetzung zusammen

Policy-Routing setzt auf einer Paketmarkierung auf, die früher in der Kette gesetzt wurde. Verfehlt die Markierungsregel Ihren Verkehr, fällt der Fluss in die Haupttabelle und verlässt das System über das dortige Standardziel. Weitergeleitete Pakete überspringen oft Ketten, die für lokal erzeugten Verkehr geschrieben wurden.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Die Übersetzung muss zu dem Uplink passen, der den Fluss trägt. Eine Regel, die auf die primäre Adresse übersetzt, während das Paket über die Backup-Leitung hinausgeht, erzeugt Antworten, die an eine Schnittstelle adressiert sind, die der Fluss nie benutzt hat. Prüfen Sie die eigene Schnittstellenbedingung der Übersetzungsregel. Eine unbedingte Regel funktioniert, bis der zweite Uplink genutzt wird, und scheitert dann auf eine Weise, die sporadisch wirkt.

Achten Sie darauf, welche Schnittstelle die Antwort trägt

Zeichnen Sie auf beiden Uplinks auf, während eine Anfrage läuft. Notieren Sie, welche Schnittstelle die Anfrage und welche die Antwort trägt. Asymmetrische Pfade sind viel leichter zu sehen als vorherzusagen.

Kommt die Antwort über den falschen Uplink an, ist das Problem von WireGuard zur Verbindungsverfolgung oder Übersetzung gewandert. Keine Änderung an der Peer-Konfiguration behebt das.

Ändern Sie eine Sache mit einem Rückweg

Halten Sie Konsolen- oder Out-of-Band-Zugang bereit, bevor Sie Policy-Regeln auf einem Gateway bearbeiten. Nehmen Sie eine Änderung vor, testen Sie dasselbe autorisierte Ziel, verbinden Sie sich dann neu und bestätigen Sie, dass der Handshake weiterhin den vorgesehenen Endpunktpfad nutzt. Fügen Sie einen numerischen Test für die zweite Adressfamilie hinzu, denn eine reine v4-Policy lässt denselben Fehler offen.

Halten Sie fest, welcher Uplink von jedem Fluss genutzt wurde. Diese Aufzeichnung macht den nächsten Bericht zu einer Zwei-Minuten-Prüfung statt zu einem ganzen Nachmittag. WireGuards Hinweise zu Namespaces und Routing beschreiben, wie man den Endpunktpfad bewusst vom getunnelten Verkehr trennt, was in der Regel sauberer ist, als einen Workaround mit Standardroute zu kopieren.