Routegebaseerde versus policygebaseerde site-to-site-VPN: wat verschilt

Beide ontwerpen beschermen hetzelfde verkeer met dezelfde IPsec-machinerie, en ze verschillen in wat bepaalt welk pakket de tunnel in gaat. In een policygebaseerde verbinding doen de onderhandelde verkeersselectors dat werk; in een routegebaseerde doet een route die naar een tunnelinterface wijst dat. De twee verwarren levert de bekende supportthread op waarin de tunnel zich als opgezet meldt terwijl de toepassing niets bereikt. Het onderscheid is het belangrijkst wanneer je een netwerk toevoegt, een routingprotocol draait of een pad debugt dat stilletjes via de verkeerde uitgang vertrekt.

Twee manieren om te bepalen wat de tunnel in gaat

Een policygebaseerde VPN bouwt een beveiligingsbeleid dat overeenkomt met bron- en doelprefixen, en versleutelt vervolgens alles wat past. De peer moet compatibele selectors onderhandelen, dus eindigt de effectieve reikwijdte als de doorsnede van wat beide kanten voorstelden. Niets buiten die doorsnede is beschermd, wat de routingtabel ook zegt.

Een routegebaseerde VPN maakt een interface die de tunnel vertegenwoordigt en laat de routingtabel er verkeer in sturen. De IKE-daemon installeert nog steeds de status en het beleid per interface, en dat is het detail dat mensen overslaan wanneer ze besluiten dat routes de versleuteling hebben vervangen. Beide ontwerpen versleutelen met IPsec; alleen het selectiemechanisme verschilt.

Lees de vergelijking hieronder als een reeks storingssignaturen en niet als een scorekaart, want geen van de kolommen wint op zichzelf.

Policygebaseerd: de selector is het contract

Selectors worden onderhandeld, niet alleen geconfigureerd. Stel 10.10.0.0/16 aan de ene kant voor en 10.10.1.0/24 aan de andere, en de associatie dekt wat de onderhandeling bepaalde terwijl elke andere host erbuiten blijft.

Lees de geïnstalleerde status in plaats van het configuratiebestand. Bij een Linux-peer zijn de eigen tabellen van de kernel de grondwaarheid, en ze laten zien wat de onderhandeling overleefde. Een beleid dat de juiste prefixen noemt zonder bijpassende status betekent dat de associatie nooit tot stand kwam. Status samen met een beleid voor het verkeerde prefix is het omgekeerde probleem, en het levert de tunnel op die er gezond uitziet terwijl één subnet niets bereikt.

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

Vergelijk beide uitvoer met de prefixen waarvan je denkt dat je ze beschermt. Die ene vergelijking lost de meeste meldingen op over een werkende tunnel met een onbereikbare server. Ze wijst ook aan welke peer gewijzigd moet worden, omdat de mismatch meestal maar in één richting zichtbaar is.

Routegebaseerd: de interface is het contract

Een XFRM-interface geeft de tunnel een naam en een identiteit, en verkeer bereikt hem omdat de routingtabel dat zegt. Meerdere externe prefixen worden dan een routingprobleem in plaats van een selectorprobleem, en een routingprotocol kan ze aankondigen. Dat is de echte winst, niet de versleuteling.

De interface neemt de noodzaak van beleid niet weg. De daemon installeert regels per interface die aan de interface-identiteit zijn gebonden, dus een pakket dat op de verkeerde interface aankomt faalt nog steeds. Een bronadres dat de peer niet accepteert faalt ook, zelfs met een perfecte route. Routegebaseerd betekent dat de route de ingang bepaalt, niet dat het beleid is verdwenen.

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

Houd de interfacetellers in de gaten zodra de route staat. Een route die bestaat terwijl de tellers op nul blijven betekent dat er niets in de tunnel wordt gematcht, wat meestal op een ontbrekende status wijst en niet op een ontbrekende route.

Waar de twee ontwerpen echt uiteengaan

Een netwerk toevoegen is de schoonste test van welk model bij je past. Een routegebaseerd ontwerp voegt een route toe en verbreedt de selector hooguit één keer, terwijl een policygebaseerd ontwerp prefixparen op beide peers bewerkt en opnieuw onderhandelt. Twee stabiele subnetten maken die bewerking triviaal, en twintig maken er een project van.

Geen van de modellen vervangt een firewall, en vergelijkingen stoppen meestal vóór dit punt. Een brede selector of een brede route bepaalt wat versleuteld wordt, niet wat is toegestaan.

Het MTU-gedrag verschilt in de praktijk ook. Encapsulatie vermindert de bruikbare payload, en een routegebaseerde interface draagt zijn eigen MTU, dus MSS-clamping op beide gateways voorkomt het zwarte-gat-symptoom waarbij kleine antwoorden aankomen en grote verdwijnen. Policygebaseerde tunnels lopen tegen dezelfde muur aan vanaf de andere kant, omdat een selector niets over de pakketgrootte zegt. Stel de clamp bewust in in plaats van de peer de schuld te geven.

Migreren zonder de terugweg te verliezen

Leg de bestaande prefixparen vast voordat je iets wijzigt, verplaats dan één toepassingspad en volg het van begin tot eind. Een tunnel die tot stand komt is geen tunnel die doorstuurt, en het verschil verschijnt in de antwoordrichting.

Wanneer de peers verbinden maar LAN-hosts niet, inspecteer dan de retourroute en het bronadres dat de externe host zal gebruiken. Een host met twee interfaces antwoordt mogelijk vanaf de verkeerde, en geen enkele selectorwijziging herstelt dat. Leg verkeer aan beide uiteinden vast voordat je algoritmen bewerkt.

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

Houd een beheerpad vrij dat niet van de tunnel afhangt terwijl je werkt. Terugrollen is eenvoudiger wanneer de eigen toegang van de gateway niet op de verbinding rijdt die je debugt.