ESP ist IP-Protokoll 50, nicht TCP-Port 50: Was Sie erlauben müssen
Protokollnummern und Portnummern sind verschiedene Namensräume. Eine Regel für TCP-Port 50 erlaubt nichts, und NAT-Traversal verschiebt ESP nach UDP 4500.
Firewall-Formulare fragen nach einem TCP-Port, und der naheliegende Eintrag ist 50. Dieser Eintrag erlaubt nichts, denn ESP ist die IP-Protokollnummer 50, und Protokollnummern sind keine Ports. Die beiden Namensräume teilen sich kleine ganze Zahlen und sonst nichts, und der Fehler bleibt unsichtbar, bis IKE fertig ist und der geschützte Verkehr nie ankommt.
Zwei Namensräume, die sich kleine Zahlen teilen
Ein IP-Header trägt ein Protokollfeld, das benennt, was als Nächstes kommt: 6 für TCP, 17 für UDP, 1 für ICMP, 50 für ESP, 51 für AH. Ein TCP- oder UDP-Header trägt Portnummern, die einen Prozess auf dem Zielhost auswählen. Protokoll 50 und TCP-Port 50 sind unverwandte Werte, die ein Dialogfeld austauschbar aussehen lassen kann.
Deshalb kann eine Portweiterleitungsregel natives ESP nicht ausdrücken. Es gibt keinen ESP-Zielport zum Weiterleiten, und ein Gerät, das nur Portregeln versteht, hat für dieses Paket überhaupt kein Vokabular. Die korrekte Regel benennt stattdessen das IP-Protokoll. Jeder Portdialog ist das falsche Werkzeug für dieses Paket.
Die Verwechslung hat eine zweite Hälfte. Wenn das Paket verschlüsselt ist, ist alles darin undurchsichtig, einschließlich des TCP-Headers der ursprünglichen Verbindung. Eine Firewall, die Ports in diesem Paket prüft, betrachtet den äußeren Header, der im nativen Fall keine Ports zum Prüfen hat.
Natives ESP, dann die gekapselte Alternative
Natives ESP wird direkt als IP-Protokoll übertragen, was gleichermaßen effizient wie unpraktisch ist. Effizient, weil es keinen zusätzlichen Header gibt, und unpraktisch, weil jedes Gerät, das Adressen und Ports übersetzt, es nicht verfolgen kann. NAT-Traversal existiert, um das zu lösen, indem es das ESP-Paket in UDP einwickelt, damit der Übersetzer Ports zum Umschreiben hat.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
Die beiden Formen sind alternative Bereitstellungen desselben Datenkanals, keine Schichten eines Kanals. Natives ESP zu erlauben erlaubt nicht die gekapselte Form, und UDP 4500 zu erlauben erlaubt keinen nativen Verkehr, also muss ein Regelsatz zur Bereitstellung passen, statt beide versehentlich abzudecken.
Auch die Erkennung ist hier wichtig. Die Endpunkte entscheiden während der Aushandlung zwischen den Formen, und der Wechsel geschieht meist, wenn ein NAT zwischen ihnen erkannt wird. Ein Pfad, der sich nach dem Aufbau des Tunnels ändert, kann den Verkehr daher in einen Namensraum verschieben, den Ihre Regeln nie abdeckten.
Lesen Sie, welche Form die Verbindung tatsächlich nutzt
Fragen Sie den Endpunkt, statt aus der Firewall zu raten. Unter Linux meldet der Zustandseintrag, ob die Assoziation UDP-Kapselung verwendet und welche Ports beteiligt sind. Ein Mitschnitt beantwortet dieselbe Frage vom Draht aus, und beides ist schneller, als einen Regelsatz zu lesen und zu hoffen.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'Der erste Befehl zeigt einen Kapselungstyp, wenn NAT-Traversal im Einsatz ist, und nichts, wenn nicht. Der zweite zeigt, welche der beiden Formen tatsächlich die Schnittstelle passiert, und das beendet Diskussionen über eine Konfiguration, die auf dem Papier richtig aussieht.
Gegenbeweise gehören in denselben Schritt. Eine Regel, die null Treffer meldet, sagt Ihnen, dass das Paket sie nie erreicht hat, und das ist eine Routing- oder Selektor-Frage, keine Firewall-Frage.
Bestätigen Sie dann den Steuerkanal getrennt. IKE hat seine eigenen Ports und seine eigenen Protokolle, und eine abgeschlossene Aushandlung ohne Daten ist genau die Trennung, um die es in diesem Artikel geht.
Schreiben Sie die Regel im richtigen Namensraum
Eine Protokollregel und eine Portregel sind unterschiedliche Anweisungen, also muss das Werkzeug die ausdrücken, die Sie meinen. In nftables ist der Protokollabgleich explizit, und die gekapselte Alternative bekommt ihre eigene UDP-Regel. Halten Sie die beiden Regeln nebeneinander, damit das Paar bei der Durchsicht sichtbar ist.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptErweitern Sie keine der beiden Regeln, um eine Fehldiagnose auszugleichen. Ein Alles-erlauben für das ESP-Protokoll auf jeder Schnittstelle oder eine UDP-Freigabe von überall nach überall behebt ein Symptom und entfernt die Kontrolle, die Sie einrichten wollten. Der schmale unterstützte Fluss ist fast immer ausreichend, sobald die Form bekannt ist.
Schließlich, halten Sie die Schichten auseinander, wenn der Tunnel funktioniert und die Anwendung nicht. Pakete, die am Gateway ankommen, brauchen weiterhin Weiterleitung, eine Rückroute und eine Richtlinie, die sie zulässt, und nichts davon drückt eine ESP-Regel aus. Der fehlende Port erklärt einen bestimmten Fehler, nicht jeden IPsec-Fehler. Behandeln Sie die Regelkorrektur und die Routingprüfung als zwei getrennte Schlussfolgerungen.
Notieren Sie die beobachtete Form, die hinzugefügte Protokollregel und den Zähler, den Sie danach gesehen haben. Drei Zeilen, und die nächste Person kann einen Namensraumfehler in einer Minute von einem Routingfehler unterscheiden statt in einem Nachmittag.