Routenbasierte vs. policybasierte Site-to-Site-VPN: Was sich unterscheidet

Beide Entwürfe schützen denselben Verkehr mit derselben IPsec-Maschinerie, und sie unterscheiden sich darin, was entscheidet, welches Paket in den Tunnel gelangt. In einer policybasierten Verbindung übernehmen die ausgehandelten Verkehrsselektoren diese Aufgabe; in einer routenbasierten übernimmt es eine Route, die auf ein Tunnelinterface zeigt. Wer beides verwechselt, erzeugt den vertrauten Support-Thread, in dem der Tunnel als aufgebaut meldet, während die Anwendung nichts erreicht. Am wichtigsten ist die Unterscheidung, wenn Sie ein Netz hinzufügen, ein Routingprotokoll betreiben oder einen Pfad debuggen, der still über den falschen Ausgang verlässt.

Zwei Wege zu entscheiden, was in den Tunnel gelangt

Eine policybasierte VPN baut eine Sicherheitsrichtlinie, die Quell- und Zielpräfixe abgleicht, und verschlüsselt dann, was passt. Der Peer muss kompatible Selektoren aushandeln, sodass der effektive Umfang am Ende der Schnittpunkt dessen ist, was beide Seiten vorgeschlagen haben. Nichts außerhalb dieses Schnittpunkts ist geschützt, egal was die Routing-Tabelle sagt.

Eine routenbasierte VPN erzeugt ein Interface, das für den Tunnel steht, und lässt die Routing-Tabelle Verkehr hineinschicken. Der IKE-Daemon installiert weiterhin den Zustand und die Richtlinie pro Interface – genau das Detail, das übersprungen wird, wenn man entscheidet, Routen hätten die Verschlüsselung ersetzt. Beide Entwürfe verschlüsseln mit IPsec; nur der Auswahlmechanismus unterscheidet sich.

Lesen Sie den Vergleich unten als Sammlung von Fehlersignaturen statt als Punktetabelle, denn keine Spalte gewinnt für sich.

Policybasiert: Der Selektor ist der Vertrag

Selektoren werden ausgehandelt, nicht bloß konfiguriert. Schlagen Sie auf einer Seite 10.10.0.0/16 und auf der anderen 10.10.1.0/24 vor, dann deckt die Assoziation ab, worauf sich die Aushandlung geeinigt hat, während jeder andere Host draußen bleibt.

Lesen Sie den installierten Zustand statt der Konfigurationsdatei. Bei einem Linux-Peer sind die eigenen Tabellen des Kernels die Grundwahrheit, und sie zeigen, was die Aushandlung überlebt hat. Eine Richtlinie, die die richtigen Präfixe nennt, aber keinen passenden Zustand hat, bedeutet, dass die Assoziation nie zustande kam. Zustand zusammen mit einer Richtlinie für das falsche Präfix ist das umgekehrte Problem, und es erzeugt den Tunnel, der gesund aussieht, während ein Subnetz nichts erreicht.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Vergleichen Sie beide Ausgaben mit den Präfixen, die Sie zu schützen glauben. Dieser eine Vergleich löst die meisten Meldungen über einen funktionierenden Tunnel mit einem unerreichbaren Server. Er zeigt auch, welchen Peer Sie ändern müssen, denn die Abweichung ist meist nur in eine Richtung sichtbar.

Routenbasiert: Das Interface ist der Vertrag

Ein XFRM-Interface gibt dem Tunnel einen Namen und eine Identität, und Verkehr erreicht ihn, weil die Routing-Tabelle es so sagt. Mehrere entfernte Präfixe werden dann zu einem Routingproblem statt zu einem Selektorproblem, und ein Routingprotokoll kann sie ankündigen. Das ist der eigentliche Gewinn, nicht die Verschlüsselung.

Das Interface beseitigt nicht die Notwendigkeit einer Richtlinie. Der Daemon installiert Regeln pro Interface, gebunden an die Interface-Identität, sodass ein Paket, das am falschen Interface ankommt, weiterhin scheitert. Eine Quelladresse, die der Peer nicht akzeptiert, scheitert ebenso, selbst mit perfekter Route. Routenbasiert heißt, die Route entscheidet über den Eintritt, nicht dass die Richtlinie verschwunden ist.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Beobachten Sie die Interface-Zähler, sobald die Route steht. Eine Route, die existiert, während die Zähler bei null bleiben, bedeutet, dass nichts in den Tunnel eingepasst wird, was meist auf einen fehlenden Zustand statt auf eine fehlende Route hindeutet.

Wo die beiden Entwürfe tatsächlich auseinandergehen

Ein Netz hinzuzufügen ist der sauberste Test, welches Modell zu Ihnen passt. Ein routenbasiertes Design fügt eine Route hinzu und erweitert den Selektor höchstens einmal, während ein policybasiertes Design Präfixpaare auf beiden Peers bearbeitet und neu aushandelt. Zwei stabile Subnetze machen diese Änderung trivial, zwanzig machen daraus ein Projekt.

Keines der Modelle ersetzt eine Firewall, und Vergleiche enden meist vor diesem Punkt. Ein breiter Selektor oder eine breite Route entscheidet, was verschlüsselt wird, nicht was erlaubt ist.

Auch das MTU-Verhalten unterscheidet sich in der Praxis. Kapselung verringert die nutzbare Nutzlast, und ein routenbasiertes Interface trägt seine eigene MTU, sodass MSS-Clamping an beiden Gateways das Blackhole-Symptom vermeidet, bei dem kleine Antworten ankommen und große verschwinden. Policybasierte Tunnel treffen dieselbe Wand von der anderen Seite, weil ein Selektor nichts über die Paketgröße sagt. Setzen Sie das Clamping bewusst, statt dem Peer die Schuld zu geben.

Migration ohne Verlust des Rückwegs

Erfassen Sie die bestehenden Präfixpaare, bevor Sie etwas ändern, und verschieben Sie dann einen Anwendungspfad und beobachten Sie ihn von Ende zu Ende. Ein Tunnel, der aufgebaut wird, ist kein Tunnel, der weiterleitet, und der Unterschied zeigt sich in der Antwortrichtung.

Wenn die Peers sich verbinden, LAN-Hosts aber nicht, prüfen Sie die Rückroute und die Quelladresse, die der entfernte Host verwenden wird. Ein Host mit zwei Interfaces antwortet möglicherweise über das falsche, und keine Selektoränderung behebt das. Erfassen Sie den Verkehr an beiden Enden, bevor Sie Algorithmen bearbeiten.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Halten Sie während der Arbeit einen Verwaltungsweg frei, der nicht vom Tunnel abhängt. Ein Rollback ist leichter, wenn der eigene Zugang des Gateways nicht auf der Verbindung reitet, die Sie debuggen.