Rekursives Routing: Wenn der Tunnel seine eigenen Pakete abfängt

Der Tunnel kommt hoch, das Protokoll zeigt einen abgeschlossenen Handshake, und eine Sekunde später stirbt dieselbe Sitzung und verbindet sich in einer Schleife neu. Dieses Muster hat eine bestimmte Ursache: Die Route zum Server zeigt jetzt in den Tunnel hinein, also werden die Pakete, die den Tunnel tragen, durch den Tunnel geschickt. An der Authentifizierung hat sich nichts geändert, deshalb bringt das erneute Eingeben der Zugangsdaten nichts. Vergleichen Sie den äußeren Pfad vor und nach der Routenänderung, dann wird die Rekursion sichtbar.

Prüfen Sie zuerst den äußeren Pfad

Es sind zwei Pakete im Spiel, nicht eines. Das innere Paket gehört zur Anwendung und sollte verschlüsselt sein, während das äußere Paket an den Server adressiert ist und ihn über einen Pfad erreichen muss, der nicht vom Tunnel abhängt.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Fragen Sie den Kernel nach der Route zur Adresse des Servers, nachdem der Tunnel steht, und erneut, nachdem sich die Standardroute geändert hat. Ein nächster Hop, der auf dem Tunnelgerät landet, ist die Rekursion, und sie ist ohne jeden Paketmitschnitt sichtbar. Eine Bindung an die Schnittstelle, Markierungen oder ein Netzwerk-Namensraum können eine einfache Abfrage unvollständig machen, also nutzen Sie den Kontext, den der Client selbst verwendet. Wenn die Antwort richtig aussieht, die Sitzung aber weiter schleift, lesen Sie die Regeln der Routing-Richtlinie und nicht nur die Haupttabelle.

Warum die Sitzung einen Moment überlebt

Der Handshake ist abgeschlossen, bevor die neue Route installiert wird, deshalb sehen die ersten Sekunden gesund aus. Sobald der Client die Standardroute hinzufügt, folgt das nächste äußere Paket ihr in die Schnittstelle hinein, über die dieses äußere Paket reisen muss. Der Server sieht nichts, der Client sendet erneut, und der Versuch läuft entweder ab oder beendet die Sitzung und beginnt von vorn.

Diese Reihenfolge erklärt, warum ein Tunnel auf einem Laptop funktionieren und auf einem Router scheitern kann und warum der Fehler oft mit dem Verkehr beginnt und nicht beim Verbindungsaufbau. Sie erklärt auch die Schleife: Jeder Neustart stellt die Sitzung her, bevor die Route das unmöglich macht.

Finden Sie heraus, wem die Ausnahme für den Endpunkt gehört

Unterstützte Clients richten ihre eigene Ausnahme ein: eine Host-Route zum Server über das ursprüngliche Gateway oder eine Markierung, die den äußeren Socket aus dem Tunnel heraushält. Die Frage ist, ob etwas anderes sie entfernt oder überschrieben hat.

Prüfen Sie bei routenbasiertem IPsec die Richtlinienselektoren, die entscheiden, welche Pakete in den Tunnel gelangen, und stellen Sie sicher, dass die Peer-Adresse davon ausgenommen ist. Bei WireGuard halten die Firewall-Markierung der Schnittstelle und ihre Richtlinienregeln die Transportpakete außerhalb des Tunnels, sodass eine manuell hinzugefügte Standardroute diese Anordnung zerstören kann. Ein zweites VPN-Profil oder ein Verwaltungsskript, das die Standardroute umschreibt, ist ein häufiger Übeltäter. Breite Umgehungsregeln, die einzeln hinzugefügt werden, sind das übliche Ergebnis, und sie verwandeln einen Routingfehler in eine Tabelle, die niemand pflegen kann.

Prüfen Sie nach einem Netzwerkwechsel erneut

Eine Host-Route über ein WLAN-Gateway ist korrekt, bis die Maschine in ein anderes Netz wechselt. Dann kehrt dasselbe Symptom ohne jede Konfigurationsänderung zurück.

Notieren Sie die Adresse des Endpunkts, die Route vor und nach dem Verbinden und die Schnittstelle, die jede von ihnen verwendet hat. Diese drei Fakten trennen meist einen Client-Fehler von einer Überschreibung, und sie überleben die Person, die sie gesammelt hat.

Verbinden Sie sich im neuen Netz erneut und wiederholen Sie die Abfrage. Fehlt die Ausnahme wieder, gehört die Korrektur in das Profil, das sie besitzt, und nicht in einen einmaligen Befehl, der während einer Störung eingetippt wurde.