Ruttbaserad vs. policybaserad plats-till-plats-VPN: vad som skiljer
Policybaserad IPsec väljer trafik med en selektor; ruttbaserad skickar den genom ett tunnelgränssnitt. Båda behöver fortfarande brandväggsregler och en returrutt.
Båda designerna skyddar samma trafik med samma IPsec-maskineri, och de skiljer sig i vad som avgör vilket paket som kommer in i tunneln. I en policybaserad anslutning gör de förhandlade trafikselektorerna det jobbet; i en ruttbaserad gör en rutt som pekar på ett tunnelgränssnitt det. Att blanda ihop de två ger den bekanta supporttråden där tunneln rapporterar att den är etablerad medan applikationen inte når något. Skillnaden spelar störst roll när du lägger till ett nätverk, kör ett routingprotokoll eller felsöker en väg som tyst lämnar genom fel utgång.
Två sätt att avgöra vad som kommer in i tunneln
En policybaserad VPN bygger en säkerhetspolicy som matchar käll- och målprefix, och krypterar sedan allt som passar. Motparten måste förhandla fram kompatibla selektorer, så den effektiva omfattningen blir till slut snittet av vad båda sidor föreslog. Inget utanför det snittet är skyddat, vad routingtabellen än säger.
En ruttbaserad VPN skapar ett gränssnitt som representerar tunneln och låter routingtabellen skicka trafik in i det. IKE-demonen installerar fortfarande tillståndet och policyn per gränssnitt, och det är detaljen folk hoppar över när de bestämmer att rutter har ersatt kryptering. Båda designerna krypterar med IPsec; bara urvalsmekanismen skiljer sig.
Läs jämförelsen nedan som en uppsättning felsignaturer och inte som ett poängkort, eftersom ingen av kolumnerna vinner i sig själv.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
Policybaserad: selektorn är kontraktet
Selektorer förhandlas, inte bara konfigureras. Föreslå 10.10.0.0/16 på ena sidan och 10.10.1.0/24 på den andra, då täcker associationen det förhandlingen landade i medan varje annan värd stannar utanför.
Läs det installerade tillståndet i stället för konfigurationsfilen. Hos en Linux-motpart är kernens egna tabeller grundsanningen, och de visar vad som överlevde förhandlingen. En policy som namnger rätt prefix utan matchande tillstånd betyder att associationen aldrig kom upp. Tillstånd tillsammans med en policy för fel prefix är det omvända problemet, och det ger tunneln som ser frisk ut medan ett subnät inte når något.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasJämför båda utdata med de prefix du tror att du skyddar. Den enda jämförelsen löser de flesta rapporter om en fungerande tunnel med en oåtkomlig server. Den pekar också ut vilken motpart som ska ändras, eftersom avvikelsen oftast bara syns i en riktning.
Ruttbaserad: gränssnittet är kontraktet
Ett XFRM-gränssnitt ger tunneln ett namn och en identitet, och trafik når det eftersom routingtabellen säger det. Flera avlägsna prefix blir då ett routingproblem i stället för ett selektorproblem, och ett routingprotokoll kan annonsera dem. Det är den verkliga vinsten, inte krypteringen.
Gränssnittet tar inte bort behovet av policy. Demonen installerar regler per gränssnitt bundna till gränssnittets identitet, så ett paket som anländer på fel gränssnitt misslyckas ändå. En källadress som motparten inte accepterar misslyckas också, även med en perfekt rutt. Ruttbaserad betyder att rutten avgör inträdet, inte att policyn har försvunnit.
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.10Håll koll på gränssnittets räknare när rutten är på plats. En rutt som finns medan räknarna står kvar på noll betyder att inget matchas in i tunneln, vilket oftast pekar på ett saknat tillstånd snarare än en saknad rutt.
Där de två designerna faktiskt skiljer sig
Att lägga till ett nätverk är det renaste testet av vilken modell som passar dig. En ruttbaserad design lägger till en rutt och breddar selektorn högst en gång, medan en policybaserad design redigerar prefixpar på båda motparterna och förhandlar om. Två stabila subnät gör den redigeringen trivial, och tjugo gör den till ett projekt.
Ingen av modellerna ersätter en brandvägg, och jämförelser stannar oftast före den här punkten. En bred selektor eller en bred rutt avgör vad som krypteras, inte vad som är tillåtet.
MTU-beteendet skiljer sig också i praktiken. Inkapsling minskar den användbara nyttolasten, och ett ruttbaserat gränssnitt bär sin egen MTU, så MSS-klämning vid båda gatewayerna undviker svart hål-symptomet där små svar anländer och stora försvinner. Policybaserade tunnlar möter samma vägg från andra sidan, eftersom en selektor inte säger något om paketstorleken. Sätt klämningen medvetet i stället för att skylla på motparten.
Migrering utan att förlora returvägen
Registrera de befintliga prefixparen innan du ändrar något, flytta sedan en applikationsväg och följ den från början till slut. En tunnel som etableras är inte en tunnel som vidarebefordrar, och skillnaden syns i svarsriktningen.
När motparterna ansluter men LAN-värdar inte kan, granska returrutten och källadressen som fjärrvärden kommer att använda. En värd med två gränssnitt kan svara från fel, och ingen selektorändring reparerar det. Fånga trafik i båda ändar innan du redigerar algoritmer.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsBehåll en administrativ väg som inte beror på tunneln medan du arbetar. Det är lättare att rulla tillbaka när gatewayens egen åtkomst inte rider på anslutningen du felsöker.