Rutebaseret vs. politikbaseret site-to-site-VPN: hvad er forskellen
Politikbaseret IPsec vælger trafik med en selector; rutebaseret sender den gennem en tunnelinterface. Begge kræver stadig firewallregler og en returrute.
Begge design beskytter den samme trafik med den samme IPsec-maskine, og de adskiller sig i, hvad der afgør, hvilken pakke der kommer ind i tunnelen. I en politikbaseret forbindelse gør de forhandlede trafikselectorer det arbejde; i en rutebaseret gør en rute, der peger på et tunnelinterface, det. At forveksle de to giver en velkendt supporttråd, hvor tunnelen melder etableret, mens applikationen ikke når noget. Forskellen betyder mest, når du tilføjer et netværk, kører en routingprotokol eller fejlfinder en sti, der stille forlader gennem den forkerte udgang.
To måder at afgøre, hvad der kommer ind i tunnelen
En politikbaseret VPN bygger en sikkerhedspolitik, der matcher kilde- og destinationspræfikser, og krypterer derefter alt, hvad der passer. Peeren skal forhandle kompatible selectors, så det effektive omfang ender som snittet af det, begge sider foreslog. Intet uden for det snit er beskyttet, uanset hvad routingtabellen siger.
En rutebaseret VPN opretter et interface, der repræsenterer tunnelen, og lader routingtabellen sende trafik ind i det. IKE-dæmonen installerer stadig tilstanden og politikken pr. interface, og det er den detalje, folk springer over, når de beslutter, at ruter har erstattet kryptering. Begge design krypterer med IPsec; kun udvælgelsesmekanismen er forskellig.
Læs sammenligningen nedenfor som et sæt fejlsignaturer snarere end et pointkort, fordi ingen af kolonnerne vinder i det abstrakte.
| 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 |
Politikbaseret: selectoren er kontrakten
Selectors forhandles, de konfigureres ikke bare. Foreslå 10.10.0.0/16 på den ene side og 10.10.1.0/24 på den anden, og associationen dækker det, forhandlingen landede på, mens hver anden host forbliver udenfor.
Læs den installerede tilstand i stedet for konfigurationsfilen. På en Linux-peer er kernens egne tabeller den hårde sandhed, og de viser, hvad der overlevede forhandlingen. En politik, der navngiver de rigtige præfikser uden matchende tilstand, betyder, at associationen aldrig kom op. Tilstand parret med en politik for det forkerte præfiks er det modsatte problem, og det giver den tunnel, der ser sund ud, mens et subnet ikke kan nå noget.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasSammenlign begge output med de præfikser, du mener at beskytte. Den ene sammenligning løser de fleste rapporter om en fungerende tunnel med en utilgængelig server. Den peger også på, hvilken peer der skal ændres, da uoverensstemmelsen normalt kun er synlig i én retning.
Rutebaseret: interfacet er kontrakten
Et XFRM-interface giver tunnelen et navn og en identitet, og trafik når det, fordi routingtabellen siger det. Flere fjerne præfikser bliver så et routingproblem i stedet for et selectorproblem, og en routingprotokol kan annoncere dem. Det er den reelle gevinst, ikke kryptering.
Interfacet fjerner ikke behovet for politik. Dæmonen installerer regler pr. interface bundet til interfaceidentiteten, så en pakke, der ankommer på det forkerte interface, stadig fejler. En kildeadresse, peeren ikke vil acceptere, fejler også, selv med en perfekt rute. Rutebaseret betyder, at ruten afgør indgangen, ikke at politikken er forsvundet.
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.10Hold øje med interfacetællerne, når ruten er på plads. En rute, der findes, mens tællerne bliver på nul, betyder, at intet matches ind i tunnelen, hvilket normalt peger på en manglende tilstand snarere end en manglende rute.
Hvor de to design reelt skilles
At tilføje et netværk er den reneste test af, hvilken model der passer dig. Et rutebaseret design tilføjer en rute og udvider højst selectoren én gang, mens et politikbaseret design redigerer præfikspar på begge peers og forhandler igen. To stabile subnet gør den redigering triviel, og tyve gør den til et projekt.
Ingen af modellerne erstatter en firewall, og sammenligninger stopper normalt før dette punkt. En bred selector eller en bred rute afgør, hvad der krypteres, ikke hvad der er tilladt.
MTU-adfærd er også forskellig i praksis. Indkapsling reducerer den brugbare nyttelast, og et rutebaseret interface bærer sin egen MTU, så klamp af MSS ved begge gateways undgår sort-hul-symptomet, hvor små svar ankommer og store forsvinder. Politikbaserede tunneler møder den samme væg fra den anden side, fordi en selector intet siger om pakkestørrelse. Sæt klampen bevidst i stedet for at bebrejde peeren.
Migrering uden at miste returvejen
Registrér de eksisterende præfikspar, før du ændrer noget, flyt derefter én applikationssti og følg den ende til ende. En tunnel, der etableres, er ikke en tunnel, der videresender, og forskellen viser sig i retningsretningen.
Når peerne forbinder, men LAN-værter ikke kan, skal du inspicere returruten og den kildeadresse, den fjerne vært vil bruge. En vært med to interfaces kan svare fra det forkerte, og ingen selectorændring reparerer det. Optag trafik i begge ender, før du redigerer algoritmer.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsBehold en administrationsvej, der ikke afhænger af tunnelen, mens du arbejder. Tilbagerulning er lettere, når gatewayens egen adgang ikke kører på den forbindelse, du fejlfinder.