strongSwan ESP-in-UDP: wenn es kein NAT zu erkennen gibt

NAT-Erkennung findet Adressübersetzung, nicht Firewall-Richtlinien. Eine Standortverbindung ohne NAT kann trotzdem eine ausdrückliche ESP-in-UDP-Wahl erfordern.

Die NAT-Erkennung beantwortet eine Frage: Haben sich die Adressen oder Ports unterwegs geändert? Sie beantwortet nicht, ob eine Firewall das IP-Protokoll 50 zulässt. Standort-Gateways ganz ohne Übersetzung können trotzdem hinter einer Richtlinie stehen, die native ESP verwirft, und diese Anforderung muss konfiguriert statt entdeckt werden. Der Mechanismus ist ESP-in-UDP, und das ist eine Entscheidung, kein Rückfall, der von selbst erscheint.

Erkennung ist Arithmetik auf Adressen, keine Firewall-Sonde

IKEv2 trägt NAT-Erkennungsnutzlasten mit Hashes der Quell- und Zieladressen sowie -ports. Jede Seite vergleicht das Empfangene mit dem, was sie lokal sieht, und eine Abweichung sagt ihr, dass etwas das Paket übersetzt hat. Nichts in diesem Austausch prüft, ob ein Router in der Mitte Protokoll 50 weiterleitet.

Die praktische Folge sollte man deutlich sagen. Ein Tunnel, der mit native ESP funktionierte, entdeckt eine neu einschränkende Firewall nicht von selbst, und sein nächster Versuch scheitert in der Datenphase, während IKE weiterhin gelingt. Sie sehen etablierte IKE-Sicherheitsassoziationen und keinen geschützten Datenverkehr, was wie ein Routingfehler aussieht, bis Sie am Draht mitschneiden.

Kapselung ist daher eine Eigenschaft der Verbindung, die Sie konfigurieren, kein Ergebnis, das die Peers aus dem Netzverhalten aushandeln.

Wie encap den Austausch verändert

In einem modernen strongSwan-Betrieb, der über swanctl.conf verwaltet wird, beeinflusst die Einstellung encap = yes an der Verbindung den NAT-Erkennungsaustausch so, dass beide Peers UDP-Kapselung für ESP verwenden. Die geschützten Pakete reisen dann innerhalb von UDP, üblicherweise auf Port 4500, und beide Endpunkte müssen sich auf diese Anordnung einigen.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Dieses Fragment gehört in eine echte Verbindungsdefinition und ist kein vollständiges Standortprofil. Behalten Sie die Peer-Adressen, die Authentifizierung und die Child-Traffic-Selektoren, die Sie bereits fahren; der eine hinzugefügte Schlüssel ändert, wie die geschützten Daten verpackt werden, nicht was sie schützen.

Der strongSwan-Leitfaden zu NAT-traversal beschreibt dieses Verhalten, einschließlich des Zusammenspiels mit Port Floating, wenn MOBIKE verwendet wird.

Verwenden Sie die Einstellung, die zu Ihrem Backend gehört

strongSwan hat zwei Konfigurations-Backends, und der Schlüssel unterscheidet sich zwischen ihnen. Eine swanctl.conf-Verbindung nimmt encap, während eine ältere ipsec.conf-Verbindung forceencaps nimmt. Ein Schlüsselwort des einen Backends in das andere zu setzen, erzeugt eine Konfiguration, die ohne Beschwerde lädt und nichts ändert, was schlimmer ist als ein Fehler.

Prüfen Sie, welcher Daemon tatsächlich läuft, bevor Sie etwas bearbeiten. Auf vielen Distributionen existieren beide Dateien, weil eine ein Überbleibsel einer früheren Migration ist, und die aktive ist die, die die Service-Unit startet. Lesen Sie diese Unit, statt aus Dateizeitstempeln zu raten. Eine fünfsekündige Prüfung hier erspart Stunden des Testens einer Einstellung, die nichts geladen hat.

Wenden Sie die Änderung über den Verbindungseigentümer an und stellen Sie die Assoziation in einem kontrollierten Fenster wieder her. Ein bereits installiertes Child behält seine aktuelle Kapselung, bis es ersetzt wird, eine Dateibearbeitung allein beweist also nicht, dass die neue Anordnung verwendet wird.

Prüfen Sie die verpackten Daten, nicht nur den Port

Schneiden Sie am Gateway mit, während geschützter Verkehr fließt, und vergleichen Sie das dann mit strongSwans eigener Sicht:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP erscheint als IP-Protokoll 50 und sieht ganz anders aus als UDP. Verpacktes ESP erscheint als UDP-Datagramme auf 4500, deren Nutzlast nicht IKE ist. IKE-Verkehr auf demselben Port ist kein Beweis für Kapselung, denn MOBIKE kann IKE dorthin verschieben, während der Datenpfad native bleibt, also lesen Sie die Nutzlast statt die Portnummer.

Behalten Sie auch die Pfad-MTU im Blick. Die Verpackung fügt Overhead hinzu, und ein Pfad, der native ESP trug, kann Anpassungen brauchen, sobald die Pakete wachsen. Erforderliche ICMP-Behandlung sollte bereits Teil des Designs sein; Kapselung beseitigt diese Abhängigkeit nicht.

Akzeptieren Sie die Änderung, wenn frischer Anwendungsverkehr im Tunnel im Mitschnitt an beiden Enden als verpacktes ESP sichtbar ist und wenn der innere Dienst und seine Rückroute weiter funktionieren. Alles darunter ist eine Konfiguration, die in einer Datei richtig aussieht.

Ähnliche Artikel