Warum eine IPsec-Sicherheitsrichtlinie kein Eintrag in der Routentabelle ist

Pingen Sie 10.20.0.5 durch den Tunnel, und es kommt nichts zurück, während die Routentabelle behauptet, dieses Subnetz sei erreichbar. Routing und IPsec beantworten unterschiedliche Fragen, und nur eine davon betrifft die Erreichbarkeit. Der Vorwärts-Lookup wählt einen Pfad, dann entscheidet die Datenbank der Sicherheitsrichtlinie, ob dieser Pfad geschützt, unberührt gelassen oder abgelehnt werden muss. Wenn die beiden sich widersprechen, stirbt das Paket still, lesen Sie sie also in dieser Reihenfolge.

Beginnen Sie mit dem Lookup, nicht mit der Tabelle

Fragen Sie den Kernel, was er wirklich tun würde: ip route get 10.20.0.5 zeigt die gewählte Route, die ausgehende Schnittstelle und die Quelladresse, die er verwenden würde. Ein Präfix, eine Richtlinienregel, eine Markierung oder eine bevorzugte Quelle können diese Antwort ändern, deshalb schlägt der Live-Lookup das Lesen der Tabelle mit dem Auge.

Testen Sie ein Ziel innerhalb des geschützten Bereichs, nicht die Gateway-Adresse. Das Erreichen des Gateways auf der Gegenseite beweist nur, dass irgendeine Route existiert; es sagt nichts über das Subnetz aus, das Sie tatsächlich brauchen. Bestätigen Sie dann, dass die vom Lookup gewählte Schnittstelle die ist, die der Tunnel Ihrer Erwartung nach nutzt.

Gleichen Sie die Selektoren auf beiden Seiten ab

Die Richtliniendatenbank hat eigene Einträge, und jeder nennt eine Richtung, eine Quelle, ein Ziel und ein Protokoll und gibt dann an, was mit passenden Paketen geschehen soll. Verwenden Sie ip xfrm policy, um sie aufzulisten; die Flags zeigen, ob die Aktion schützen, umgehen oder blockieren lautet. Eine Richtlinie, deren Selektoren breiter oder enger als Ihr Testflow sind, passt nicht darauf, und das Paket verlässt den Host ungeschützt. Das ist der Fehler, den Sie suchen, keine fehlende Route.

Vergleichen Sie die tatsächlichen Werte: Quelle, Ziel, Protokoll und Ports. Wenn der Lookup ein Adresspaar aufgelöst hat, während der Richtlinieneintrag ein anderes abdeckt, beschreiben die beiden Ansichten unterschiedlichen Verkehr. Führen Sie beide mit demselben Tupel erneut aus, bevor Sie eine Schlussfolgerung ziehen, sonst bearbeiten Sie eine Richtlinie, die nie im Pfad lag.

Ein Richtlinientreffer ist kein installierter Zustand

Eine passende Richtlinie sagt nur, dass das Paket geschützt werden muss; der Kernel braucht trotzdem eine Sicherheitsassoziation, um den Schutz auszuführen. Listen Sie sie mit ip xfrm state auf, oder mit swanctl --list-sas, wenn strongSwan die Verhandlung führt, und lesen Sie die Selektoren und Zähler jedes Eintrags.

Wenn eine Richtlinie passt und keine Assoziation dieselben Selektoren abdeckt, wird das Paket verworfen, statt im Klartext gesendet zu werden. Das ist der Verwerfungsfall, nach dem Sie suchen, wenn der Tunnel steht, aber ein einzelnes Subnetz ausfällt. Die Zähler sagen den Rest: Eine Assoziation, die nie hochzählt, wurde nie ausgewählt, während eine, die hochzählt und trotzdem in einer Verwerfung endet, auf die Gegenseite zeigt. Selektoren zu korrigieren und Schlüssel zu erneuern sind verschiedene Reparaturen, entscheiden Sie also, welche Sie brauchen, bevor Sie die Konfiguration anfassen.

Was ein routenbasierter Tunnel trotzdem verlangt

Eine XFRM-Schnittstelle lässt den Tunnel wie ein Gerät aussehen, in das Sie routen können, was wirklich nützlich ist. Sie beseitigt aber nicht die Richtlinie und den Zustand, die entscheiden, was geschieht, sobald das Paket dort ankommt. Die Route steuert einen nächsten Hop bei und nichts weiter.

Wenn das Gerät existiert und die Route hineinzeigt, aber keine Assoziation zu den inneren Selektoren passt, wird das Paket verworfen, und noch so viel Routenbearbeitung erzeugt weder Schlüssel noch Selektoren. Prüfen Sie die Schnittstelle mit derselben Quelle und demselben Ziel, die Sie geroutet haben, und vergleichen Sie das dann mit der Zustandsliste.

Klären Sie die Zuständigkeit, bevor Sie etwas bearbeiten

Eine Host-Firewall fügt eine dritte Entscheidung hinzu, von der keine der beiden Datenbanken weiß. Eine korrekte Route plus eine passende Richtlinie plus eine installierte Assoziation können trotzdem in einem verworfenen Paket enden, und die Anwendung meldet nur den Timeout. Bestätigen Sie, dass die Firewall den geschützten Verkehr zulässt, bevor Sie IPsec beschuldigen. Mitschnitte auf dem Tunnelgerät und auf der physischen Schnittstelle zeigen, auf welcher Seite der Verschlüsselung das Paket verschwunden ist.

Die Zuständigkeit für die Konfiguration entscheidet, ob Ihre Korrektur einen Neustart überlebt. Eine Komponente kann Zustand installieren, während eine andere Routen verwaltet, und eine Handbearbeitung der zweiten wird überschrieben, wenn der Tunnel das nächste Mal hochkommt. Ändern Sie die zuständige Konfiguration und lesen Sie dann beide Ansichten erneut; RFC 4301 hält die beiden Datenbanken getrennt, wenn Sie die Trennung jemand anderem erklären müssen.