Antwort der Site-to-Site-VPN kommt nicht durch den Tunnel

Ich habe einen Vormittag mit einem Tunnel verbracht, der sauber hochkam und den Verkehr in genau eine Richtung beförderte: Die Filiale erreichte den Fileserver in der Zentrale, und jede von der Zentrale in die Filiale geöffnete Verbindung starb beim ersten SYN. Die SAs standen, die Tunnelzähler stiegen, und der Handshake war nie das Problem. Die Antwort wurde irgendwohin geroutet, wo der Tunnel sie nicht abdeckt, und diese Wahl trifft die Gegenseite. Eine Site-to-Site-VPN transportiert nur Pakete, die ein Host dem Gateway übergibt, und jeder Host trifft diese Wahl selbst, in jeder Richtung, aus seiner eigenen Routingtabelle.

Beide Richtungen werden getrennt geroutet

IP speichert nichts über die Richtung einer Konversation. Jeder Host, der ein Paket sendet, führt seine eigene Suche nach dem längsten Präfix durch, wählt einen nächsten Hop und vergisst die Entscheidung. Die Anfrage und die Antwort sind zwei unabhängige Pakete, die zufällig zur selben Verbindung gehören, und der Tunnel ist ein Hop, den jedes von beiden nutzen kann oder nicht. Nichts im IKE-Austausch bringt dem entfernten Server bei, wie er Ihr Subnetz erreicht; die Aushandlung einigt sich nur darauf, welche Präfixe verschlüsselt werden dürfen.

Diese Einigung ist das zweite Tor. Bei strongSwan sind die Traffic-Selektoren leftsubnet und rightsubnet, und ein Paket, dessen Quelle oder Ziel außerhalb des ausgehandelten Paares liegt, wird nicht verschlüsselt, was die Routingtabelle auch sagt. Ein Präfix, das in den Tunnel geroutet wird, aber in den Selektoren fehlt, ist ein stiller einseitiger Fehler: Die Route sieht richtig aus, das Paket verlässt den Host trotzdem im Klartext oder wird verworfen, und nur das charon-Log beschwert sich.

Der entfernte Host weiß nichts von Ihrem Tunnel

Innerhalb des entfernten LAN ist die Antwort ein gewöhnliches Paket an Ihren Client. Der Zielhost sieht keinen IPsec-Header und hat keinen Grund, das VPN-Gateway zu bevorzugen; er schlägt Ihr Präfix nach, findet nichts Spezifischeres als seine Standardroute und folgt ihr. Zeigt die Standardroute auf eine Kern-Firewall, hat die Firewall entweder eine Route zurück in den Tunnel oder nicht. Hat sie keine, bekommen Sie einen stillen Drop, ein ICMP unreachable oder eine Antwort, die über die internetseitige Schnittstelle hinausgeht und stirbt.

Eine zweite Schnittstelle genügt, um das zu brechen, selbst wenn eine Route existiert. Ein NAS mit Management-Link in einem anderen VLAN, ein Server mit Backup-Uplink, eine Policy-Regel, die einen Quellbereich in eine zweite Tabelle schickt: All das kann die Antwort abfangen. Unter Linux zeigen ip rule show und ip route show table all Regeln und Tabellen, die die Standardauflistung verbirgt.

Lesen Sie die Entscheidung auf der Maschine, die die Antwort sendet

Fragen Sie den Kernel, bevor Sie etwas ändern, und geben Sie ihm die Quelladresse, denn quellabhängige Regeln ändern die Antwort.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Die Ausgabe nennt die ausgehende Schnittstelle und den nächsten Hop. Ist die Schnittstelle nicht die zum VPN-Gateway weisende, haben Sie den Fehler gefunden, und die restliche Arbeit ist die Wahl, wohin die Route gehört. Ein Ping vom Gateway beweist hier wenig: Er antwortet mit einer Adresse, die der entfernte Host einordnen kann, nicht mit der Adresse Ihres Laptops.

Unter Windows sind die Entsprechungen Find-NetRoute -RemoteIPAddress 10.10.5.10 für die Entscheidung und Get-NetRoute für die Tabelle. Eine mit New-NetRoute hinzugefügte Route, die eine höhere Metrik als die Standardroute trägt, verliert still, lesen Sie also die Metrikspalte, nicht den Eintrag. Bestätigen Sie dann mit Paketen: tcpdump -ni any "host 10.10.5.10 and tcp port 445" auf der entfernten LAN-Schnittstelle zeigt die Anfrage, und derselbe Filter auf der Tunnelseite zeigt, ob eine Antwort zurückkam. Sichtbare Anfrage ohne Antwort heißt, die Antwort wurde woandershin geroutet oder verworfen; eine Antwort auf der falschen Schnittstelle liefert Ihnen den Täter, bevor Sie eine Route anfassen.

Wenn das Server-Gateway nicht der VPN-Endpunkt ist

Viele Standorte setzen eine Firewall zwischen die Server und den Konzentrator. Diese Firewall leitet die Antwort weiter, also braucht sie eine Route für Ihr Client-Präfix zum VPN-Gateway und Weiterleitungspolitik in beide Richtungen. Zustandsbehaftete Geräte machen es schlimmer: Die Anfrage passierte die Firewall von einem LAN-Host, den sie erlaubte, die Antwort kommt nun aus einer anderen Richtung, und der Verbindungsverfolgungseintrag passt nicht mehr, sodass das Paket als ungültig statt als verboten verworfen wird. Deshalb sieht das Policy-Log leer aus, während der Verkehr verschwindet.

Das Gateway hat einen eigenen zweiten Filter. Die Reverse-Path-Filterung unter Linux verwirft Pakete, deren Quelle über die Schnittstelle, auf der sie ankamen, nicht erreichbar ist, und genau das ist die Form eines legitimen asymmetrischen Rückwegs. strongSwans Anleitung zur Weiterleitung verlangt aus genau diesem Grund net.ipv4.ip_forward und ein gelockertes net.ipv4.conf.all.rp_filter. Ein strenger Wert von 1 auf einem der beiden Gateways bricht still eine korrekte Route, und nstat -az zeigt die Drops, wenn man weiß, wo man nachsieht.

Routen oder übersetzen, dann in beide Richtungen prüfen

Die beiden Reparaturen sind nicht gleichwertig. Eine Route hinzuzufügen lässt die Client-Adresse unangetastet, sodass quellbasierte Regeln, Audit-Logs und Anwendungen, die den Aufrufer festhalten, weiter funktionieren; der Preis ist, dass jeder Hop, der die Entscheidung trifft, die Route braucht, also mehr Stellen, an denen es falsch sein kann. Maskierung auf dem entfernten Gateway schrumpft den Rückweg auf einen Hop, weil die Antwort nun an das Gateway selbst adressiert ist, und verbirgt, welcher Client was getan hat.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Wählen Sie es bewusst: Sobald Clients als Gateway-Adresse erscheinen, können quellbasierte ACLs sie nicht mehr unterscheiden, und conntrack muss die Zuordnung halten, damit die Antwort zurück in den Tunnel geschrieben wird. Schließen die Selektoren das Client-Präfix weiterhin aus, ändert NAT nichts, weil die Anfrage nie in den Tunnel gelangt ist.

Bevor Sie es als behoben bezeichnen, bestätigen Sie vier Dinge der Reihe nach: die Route auf dem Host, der die Antwort sendet, die Route auf jedem Hop, der sie weiterleitet, die Selektoren, die beide Präfixe abdecken, und einen Mitschnitt, der zeigt, dass die Antwort mit der erwarteten Quelle in den Tunnel eintritt. Wiederholen Sie dann den Test von der anderen Seite. Eine Richtung, die durchgeht, ist ein halboffenes Design, und die zweite Richtung scheitert meist aus einem anderen Grund als dem, den Sie gerade repariert haben.