XFRM-Standardroute verschluckte IKE und ESP: den äußeren Pfad erhalten

Der Verkehr ist geschützt, der Tunnel steht, und dann stirbt er bei der nächsten Schlüsselerneuerung. Eine Standardroute über die XFRM-Schnittstelle beschrieb den Verkehr, den Sie schützen wollten. Sie verschluckte auch die Pakete, die nötig sind, um ihn weiter zu schützen.

Die beiden beteiligten Ziele sind nicht austauschbar. Das Routing muss das ausdrücklich sagen.

Wohin die Peer-Suche tatsächlich geht

Halten Sie die aktiven Regeln fest, die Tabelle mit der XFRM-Route und die öffentliche Peer-Adresse. Schauen Sie dann auf den Pfad, den die äußere Verbindung mit ihrer echten Quelle und Markierung nehmen würde. Ein allgemeines Ziel sagt nichts über diesen Steuerpfad. Nur die tatsächliche Quelle und Markierung geben eine brauchbare Antwort.

Auch eine erfolgreiche Erstverbindung beweist wenig. Der Fehler zeigt sich oft erst, nachdem eine Ruteninstallation die Antwort geändert hat. Der Start gelingt, die erste Erneuerung dann nicht mehr.

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

Löst sich die Suche nach dem Peer in die XFRM-Schnittstelle auf, werden die äußeren Pakete in den Tunnel geroutet, den sie selbst aufbauen. Das ist die Schleife, sichtbar in einem Befehl.

Ausschlussoptionen auf einem modernen Gateway

Die strongSwan-Dokumentation zu routenbasiertem VPN nennt zwei praktische Antworten. Die eine markiert IKE und ESP, damit die Regel auf die XFRM-Tabelle nicht auf sie passt. Die andere lässt eine Peer-Route oder einen Ausschluss stehen, den die Suche noch erreicht.

Nehmen Sie die, die Ihr Regelsatz ohne Nebenwirkungen ausdrücken kann. Eine Markierung ist sauber, wenn der Rest des Stapels bereits Markierungen verwendet. Sie ist gefährlich, wenn dieselbe Maske in einer anderen Regel etwas anderes bedeutet. Beide Pakettypen brauchen die Behandlung ohnehin.

Nur IKE zu markieren lässt die Datenpakete auf dem eingefangenen Pfad. Das ergibt einen Tunnel, der einen Handshake macht und danach nichts trägt.

Die Markierung ist ein Bit im fwmark des Pakets, das sonst nichts auf dem Gateway beansprucht: 0x1 mit Maske 0x1 ist die übliche Wahl, und sie muss an zwei Stellen gesetzt werden, damit der Ausschluss funktioniert. Charon braucht sie auf dem IKE-Socket, und die eingehenden und ausgehenden Markierungseinstellungen der Child-Verbindung brauchen denselben Wert, damit auch gekapselte Pakete markiert hinausgehen. Eine Maske von 0x1 statt 0xffffffff lässt die übrigen Bits frei, was zählt, wenn ein anderes Subsystem auf demselben Host bereits Pakete markiert. Sind beide gesetzt, wird die Regel als Ausschluss geschrieben, sodass markierte Pakete die Tabelle mit der XFRM-Route überspringen und in die Haupttabelle durchfallen:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

Lesen Sie dann die Antwort mit angewendeter Markierung. Ohne sie untersuchen Sie den Pfad, den geschützter Verkehr nimmt, also das Gegenteil der Frage dieses Abschnitts.

Was die automatische Installation über den Build annimmt

Automatische Ruteninstallation für eine XFRM-Schnittstelle hängt von der strongSwan-Version und ihrer Konfiguration ab. Schnittstellen-ID, installierte Richtlinie und Assoziation müssen alle auf die vorgesehenen Objekte verweisen. Eine Abweichung zeigt sich als Route, die still auf etwas Reales zeigt.

Eine Tabellennummer oder eine Markierungsmaske von einem anderen Gateway zu kopieren, ist der Anfang von Kollisionen. Prüfen Sie zuerst, was sie bereits nutzt. Eine Kollision betrifft Verkehr weit über den Tunnel hinaus, den Sie ändern wollten, und das Symptom zeigt selten auf die Kopie.

Peer-Adressänderungen gehören ins Design. Eine Host-Route für die gestrige Adresse ist kein Plan zur Endpunkt-Wiederherstellung, während eine Markierung diese Änderung übersteht.

Beobachten Sie die erste Erneuerung

Prüfen Sie den äußeren Pfad, nachdem die geschützten Routen installiert sind, nicht davor. Beobachten Sie dann die nächste Erneuerung und einen Anwendungsaustausch. Der Fehler zeigt sich meist an diesem Übergang und nicht beim Start.

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Die geschützte Standardroute vorübergehend zu entfernen, stellt die Verbindung meist wieder her. Das Ergebnis ist diagnostisch, nicht endgültig.

Das Ziel ist eine stabile Trennung zwischen innerem Verkehr und den äußeren Paketen, die ihn tragen. Schreiben Sie den gewählten Mechanismus und seine Tabelle oder Markierung in die Gateway-Notizen. Sonst führt die nächste Person, die die Regeln anfasst, die Schleife wieder ein.