VPN-Route oder Firewall-Regel: Was verwirft das Paket?

Die Route wählt einen Pfad, und der Filter entscheidet über die Erlaubnis. Prüfen Sie beides für dieselbe Quelle, dasselbe Ziel und dieselbe Richtung, bevor Sie eine Firewall-Regel erweitern.

Zwei unabhängige Entscheidungen treffen dasselbe Paket, und jede von ihnen kann die Anfrage still beenden. Die Routensuche wählt eine Schnittstelle und einen nächsten Hop, dann entscheidet der Paketfilter, ob diese Kombination erlaubt ist. Eine Zeitüberschreitung sagt Ihnen, dass eine der beiden abgelehnt hat, nicht welche. Arbeiten Sie die Stufen der Reihe nach ab, und die Reparatur hört meist auf, ein Rätselraten zu sein.

Zwei Entscheidungen, ein Paket, zwei Eigentümer

Die Routensuche konsultiert zuerst die Policy-Regeln, dann die Tabelle, auf die sie zeigen, und wählt das spezifischste Präfix, das zum Ziel passt. Ein Client, der eine Tunnelroute installiert hat, besitzt diese Entscheidung, und nichts an einer Firewall-Regel kann sie ersetzen. Wenn die Suche auf etwas Unerwartetes zeigt, arbeitet jede spätere Stufe am falschen Paket.

Das Filtern ist getrennt. Auf einem Linux-Host teilen die netfilter-Hooks den Verkehr danach auf, für wen das Paket bestimmt ist: Output verlässt die Maschine, Input endet auf ihr, Forward läuft durch sie hindurch. Ein Gateway, das VPN-Clients annimmt und sie in ein LAN routet, braucht den Forward-Pfad, und genau diese Kette lassen die meisten Standardkonfigurationen leer.

Die Quellwahl gehört zur selben Entscheidung, und hier verstecken sich die meisten Abweichungen. Der Kernel wählt eine Quelladresse von der ausgehenden Schnittstelle, sofern die Route keine nennt, daher trifft eine Filterregel für das LAN-Subnetz nie auf ein Paket, das mit der Tunneladresse hinausgeht.

Lesen Sie, was die Suche tatsächlich gewählt hat

Geben Sie die Entscheidung aus, statt sie zu erraten. Der folgende Befehl löst die Route auf, die der Kernel für dieses Ziel verwenden würde, einschließlich der Schnittstelle und der Quelle, die er wählen würde:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-Clients installieren oft Policy-Regeln mit Prioritäten unter der Haupttabelle, daher beweist eine saubere Haupttabelle für sich genommen nichts. Vergleichen Sie die Regelprioritäten mit den Tabellen, die sie auswählen, und prüfen Sie, ob die Tunnelroute einen Reconnect überlebt, statt einmal von Hand hinzugefügt zu werden.

Policy-basiertes IPsec fügt eine dritte Abgleichsstufe hinzu, die das Routing nicht abdeckt, wie strongSwans Weiterleitungsnotizen für Tunnel- und Transport-Setups beschreiben. Die Sicherheitsrichtlinie wählt Verkehr nach Präfix und Protokoll aus, während die Route nur entscheidet, wohin ein ungeschütztes Paket ginge. Ein Subnetz, das geroutet wird, aber keinen passenden Selektor hat, bleibt entweder ungeschützt oder wird verworfen, je nach Konfiguration, und keines der Ergebnisse sieht wie ein Firewall-Problem aus. Geben Sie die Richtlinie aus und vergleichen Sie ihre Selektoren mit den Präfixen, die der Tunnel Ihrer Erwartung nach tragen sollte.

Filtern greift an einem Hook, nicht an einer Route

Eine Regel, die den VPN-Listener erlaubt, ist eine Regel über Verkehr, der an das Gateway selbst adressiert ist. Sie sagt nichts über Clients aus, die Hosts hinter diesem Gateway erreichen, weil weitergeleiteter Verkehr eine andere Kette durchläuft. Das Regelwerk als eine flache Liste zu lesen, ist der übliche Grund, warum eine korrekt aussehende Regel nie greift.

Zähler klären die Frage schnell. Eine Regel mit null Paketzähler wurde nie erreicht, was auf die falsche Kette, die falsche Schnittstelle oder einen früheren Drop hindeutet. Eine Regel mit steigendem Zähler unter einer Drop-Policy ist die Grenze, die Sie gesucht haben, und das Paket wird verworfen statt falsch geroutet.

Schicken Sie eine Sonde über den Pfad, den der Client nutzt

Tests, die auf dem Gateway selbst laufen, gehen über Output und Input mit der eigenen Quelladresse des Gateways. Das ist ein anderer Pfad als die weitergeleitete Anfrage eines Clients, daher beweist ein erfolgreicher lokaler curl weniger, als es scheint. Prüfen Sie von der Maschine, die scheitert, oder legen Sie Schnittstelle und Quelle explizit fest.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Eine Aufzeichnung an beiden Enden trennt die restlichen Fälle. Ein SYN, das den Client verlässt und nie ankommt, bedeutet Routing, Verschlüsselung oder eine vorgelagerte Zugriffsliste. Ein SYN, das ankommt und keine Antwort erhält, bedeutet den Dienst oder seinen Host-Filter, und der Tunnel war nie das Problem.

Rückverkehr verdient einen eigenen Blick. Asymmetrisches Routing plus Reverse-Path-Filtering verwirft Antworten, die auf der falschen Schnittstelle ankommen, was sich als einseitige Verbindung statt als blockierter Port zeigt. Prüfen Sie den sysctl-Wert, bevor Sie die Firewall für ein Symptom verantwortlich machen, das sie nicht verursacht hat.

Logging wirkt als zweite Meinung, nicht als erster Schritt. Eine temporäre Log-Anweisung auf der Forward-Kette benennt die Schnittstelle und die Adressen, die sie getroffen haben, und sie ist danach leicht zu entfernen. Lassen Sie sie dauerhaft stehen, und Sie haben ein Log-Volumenproblem statt einer Antwort gebaut.

Setzen Sie jede Änderung dorthin, wo sie einen Reconnect überlebt

Eine mit ip route add hinzugefügte Route lebt, bis die Schnittstelle heruntergeht. Speichern Sie sie stattdessen im Verbindungsprofil: NetworkManager akzeptiert zusätzliche Routen auf der Verbindung, und netplan behält sie über Neustarts hinweg. Dieselbe Regel gilt für eine Firewall-Ausnahme auf Clientseite, die nach dem nächsten Neuladen verschwunden ist.

Regeln auf Serverseite gehören in die Konfigurationsdatei, die der Dienst beim Start lädt, nicht in eine interaktive Sitzung, die endet, wenn Sie sie schließen. Schreiben Sie die Regel, laden Sie neu und bestätigen Sie, dass sich der Zähler bewegt hat, denn ein Neuladen, das die Syntax abgelehnt hat, lässt das alte Regelwerk stillschweigend stehen.

Wiederholen Sie dann die ursprüngliche Anwendungsanfrage von Ende zu Ende und notieren Sie, welche Schicht sich geändert hat. Eine Routenkorrektur, die auch eine Filteränderung brauchte, wird trotzdem scheitern, und der zweite Fehlschlag liest sich viel leichter, wenn man weiß, dass der erste weg ist. Notieren Sie Datum und Clientversion neben dem Ergebnis, da sich Voreinstellungen für Routing und Filtern zwischen Versionen bewegen. Behalten Sie diese Notiz im Ticket, damit die nächste Person dort beginnt, wo Sie aufgehört haben, statt den zweistufigen Weg zu wiederholen.

Ähnliche Artikel