IPsec-Richtlinie schluckt deinen lokalen Verkehr: So erkennst du es

Der Drucker auf dem Schreibtisch antwortet nicht mehr, sobald der Tunnel steht, und in der Tunnelkonfiguration wird der Drucker nirgends erwähnt. Meist wurde ein geschützter Bereich so weit gefasst, dass er ihn einschließt, sodass der Rechner jetzt Datenverkehr verschlüsseln will, der im lokalen Segment bleiben sollte. Die installierte Richtlinie zu lesen erklärt das Abfangen; sie an der richtigen Stelle zu verengen schützt den entfernten Verkehr weiter. Der Weg von der fehlgeschlagenen Anfrage zur passenden Richtlinie dauert nur wenige Minuten.

Erst den Ablauf verfolgen, dann den Selektor ändern

Beginne bei der fehlgeschlagenen Anfrage und notiere vier Werte: die Quelladresse, die der Rechner nutzt, das genaue Ziel, die Route, die der Kernel wählt, und die Richtlinie, die auf dieses Paar passt.

Diese vier Fakten entscheiden, ob das Abfangen beabsichtigt oder versehentlich ist. Ein Ziel, das innerhalb des entfernten Selektors liegt, wird planmäßig geschützt, selbst wenn der Plan falsch war. Ein Ziel außerhalb, das trotzdem abgefangen wird, bedeutet, dass etwas anderes passt, und eine Änderung des Selektors hilft dann nicht. Beide Fälle sind häufig, und sie werden durch einen einzigen Befehl unterschieden.

Tu das, bevor du irgendetwas bearbeitest, denn der interessante Fall ist das lokale Subnetz, das sich mit einem privaten Bereich überschneidet, den die Verbindung schützt. Vertraute Präfixe wie 192.168.0.0/16 tauchen in vielen Netzen auf, und ein für eines davon geschriebener Selektor kann still dein eigenes Netz abdecken.

Drei Arten von lokal, die sich unterschiedlich verhalten

Ein Ziel, das diesem Host zugewiesen ist, ein Ziel auf demselben Link und ein Ziel hinter einer anderen Schnittstelle sind drei verschiedene Fälle. Der Kernel behandelt jeden davon anders, wenn er entscheidet, ob Verkehr geschützt werden muss.

Vom Gateway selbst erzeugter Verkehr ist auch nicht dasselbe wie von einem Client weitergeleiteter Verkehr. Eine Richtlinie, die für weitergeleiteten Verkehr korrekt aussieht, kann die eigene Verwaltungssitzung des Gateways abfangen, und genau so verliert ein Administrator den Zugang, während er den Tunnel repariert.

Die nützliche Angewohnheit ist, den Fall laut zu benennen: Kommt dieses Paket von mir, zu meinem Link oder durch mich? Jede Antwort zeigt auf eine andere Stelle zum Verengen. Den Fall aufzuschreiben verhindert außerdem, dass die nächste Person dieselbe Arbeit noch einmal macht.

Wenn der geschützte Bereich ein ganzer privater Raum ist, können alle drei Fälle gleichzeitig hineinfallen, und das Symptom wird ein Rechner, der außer dem Tunnelendpunkt nichts mehr erreicht.

Die installierte Richtlinie lesen, nicht die Datei

Konfigurationsdateien beschreiben die Absicht; der Kernel hält die Richtlinien, die tatsächlich passen. Gib beides aus und behandle eine Abweichung als ersten Befund.

Diese Befehle zeigen die gewählte Route für das Ziel und die installierten Richtlinien in jeder Richtung:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Die Route sagt dir, welche Schnittstelle das Paket nutzen würde. Die Richtlinienliste sagt dir, ob auf dieses Paket dann eine Vorlage angewendet wird, und die Verbindungsliste zeigt, welche Selektoren der Daemon installiert zu haben glaubt. Erscheint das Ziel in einem entfernten Selektor, hast du das Abfangen gefunden, ohne zu raten.

Den Selektor verengen oder das Ziel umgehen

Es gibt zwei unterstützte Reparaturen, und sie beantworten unterschiedliche Fragen. Den Selektor zu verengen sagt, dass diese Verbindung nur einen kleineren Bereich schützt, was richtig ist, wenn der weitere Bereich ein Fehler war. Eine Ausnahme hinzuzufügen sagt, dass dieses bestimmte Ziel niemals geschützt werden darf, was richtig ist, wenn der geschützte Bereich wirklich weit ist und ein Ziel eine Ausnahme bildet.

Wähle die erste, wenn du kannst, denn ein kleinerer Selektor ist leichter nachzuvollziehen und erscheint in der Verbindungsdefinition. Wähle die zweite, wenn der weite Bereich absichtlich so ist und die Ausnahme ein einzelner Host oder ein Subnetz ist, das du benennen kannst.

Beides gehört in die Konfiguration, der die Verbindung gehört. Eine von Hand hinzugefügte Laufzeitregel verschwindet beim nächsten Neuverbinden, und der Fehler kehrt in einem Moment zurück, in dem sich niemand mehr an den Workaround erinnert.

Neuinstallationssichere Ausnahmen

Wiederhole nach der Änderung dieselbe harmlose Anfrage und schau auf dieselben Zähler. Das lokale Ziel sollte antworten, und das beabsichtigte entfernte Ziel sollte weiterhin verschlüsselten Verkehr zeigen.

Diese beiden Prüfungen bestätigen, dass die Ausnahme überlebt hat und der Schutz nicht:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Trenne dann den Tunnel bewusst und verbinde ihn neu, und wiederhole beides. Eine Ausnahme, die vor dem Neuverbinden funktioniert und danach scheitert, wurde auf der falschen Ebene angewendet, und das ist der häufigste Weg, auf dem dieses Problem zurückkommt.