Rutebasert vs. policybasert nettsted-til-nettsted-VPN: hva som skiller
Policybasert IPsec velger trafikk med en selektor; rutebasert sender den gjennom et tunnelgrensesnitt. Begge trenger fortsatt brannmurregler og en returrute.
Begge designene beskytter den samme trafikken med den samme IPsec-maskinen, og de skiller seg i hva som avgjør hvilken pakke som kommer inn i tunnelen. I en policybasert forbindelse gjør de forhandlede trafikkselektorene den jobben; i en rutebasert gjør en rute som peker på et tunnelgrensesnitt det. Å blande de to gir den kjente støttetråden der tunnelen melder seg etablert mens applikasjonen ikke når noe. Forskjellen betyr mest når du legger til et nettverk, kjører en rutingsprotokoll eller feilsøker en sti som stille forlater gjennom feil utgang.
To måter å avgjøre hva som kommer inn i tunnelen
En policybasert VPN bygger en sikkerhetspolicy som samsvarer med kilde- og målprefikser, og krypterer deretter alt som passer. Motparten må forhandle kompatible selektorer, så det effektive omfanget ender opp som snittet av det begge sider foreslo. Ingenting utenfor det snittet er beskyttet, uansett hva rutetabellen sier.
En rutebasert VPN oppretter et grensesnitt som representerer tunnelen og lar rutetabellen sende trafikk inn i det. IKE-demonen installerer fortsatt tilstanden og policyen per grensesnitt, og det er detaljen folk hopper over når de bestemmer at ruter har erstattet kryptering. Begge designene krypterer med IPsec; bare utvelgelsesmekanismen er forskjellig.
Les sammenligningen nedenfor som et sett feilsignaturer og ikke som et poengark, fordi ingen av kolonnene vinner i seg selv.
| 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 |
Policybasert: selektoren er kontrakten
Selektorer forhandles, ikke bare konfigureres. Foreslå 10.10.0.0/16 på den ene siden og 10.10.1.0/24 på den andre, så dekker assosiasjonen det forhandlingen landet på mens hver annen vert blir utenfor.
Les den installerte tilstanden i stedet for konfigurasjonsfilen. På en Linux-motpart er kjernens egne tabeller grunnsannheten, og de viser hva som overlevde forhandlingen. En policy som navngir de riktige prefiksene uten samsvarende tilstand betyr at assosiasjonen aldri kom opp. Tilstand sammen med en policy for feil prefiks er det motsatte problemet, og det gir tunnelen som ser sunn ut mens ett subnett ikke når noe.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasSammenlign begge utdataene med prefiksene du tror du beskytter. Den ene sammenligningen løser de fleste rapportene om en fungerende tunnel med en utilgjengelig server. Den peker også på hvilken motpart som skal endres, siden avviket vanligvis bare er synlig i én retning.
Rutebasert: grensesnittet er kontrakten
Et XFRM-grensesnitt gir tunnelen et navn og en identitet, og trafikk når det fordi rutetabellen sier det. Flere eksterne prefikser blir da et rutingsproblem i stedet for et selektorproblem, og en rutingsprotokoll kan annonsere dem. Det er den virkelige gevinsten, ikke kryptering.
Grensesnittet fjerner ikke behovet for policy. Demonen installerer regler per grensesnitt bundet til grensesnittets identitet, så en pakke som ankommer feil grensesnitt fortsatt feiler. En kildeadresse motparten ikke vil godta feiler også, selv med en perfekt rute. Rutebasert betyr at ruten avgjør inngangen, ikke at policyen er borte.
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.10Følg med på grensesnitttellerne når ruten er på plass. En rute som finnes mens tellerne blir stående på null betyr at ingenting matches inn i tunnelen, noe som vanligvis peker på en manglende tilstand snarere enn en manglende rute.
Hvor de to designene faktisk skiller lag
Å legge til et nettverk er den reneste testen på hvilken modell som passer deg. Et rutebasert design legger til en rute og utvider høyst selektoren én gang, mens et policybasert design redigerer prefikspar på begge motpartene og forhandler på nytt. To stabile subnett gjør den redigeringen triviell, og tjue gjør den til et prosjekt.
Ingen av modellene erstatter en brannmur, og sammenligninger stopper vanligvis før dette punktet. En bred selektor eller en bred rute avgjør hva som krypteres, ikke hva som er tillatt.
MTU-oppførselen er også forskjellig i praksis. Innkapsling reduserer nyttelasten, og et rutebasert grensesnitt bærer sin egen MTU, så MSS-klamping ved begge gatewayene unngår svart hull-symptomet der små svar ankommer og store forsvinner. Policybaserte tunneler møter den samme veggen fra den andre siden, fordi en selektor ikke sier noe om pakkestørrelse. Sett klampen bevisst i stedet for å klandre motparten.
Migrering uten å miste returveien
Registrer de eksisterende prefiksparene før du endrer noe, flytt deretter én applikasjonssti og følg den ende til ende. En tunnel som etableres er ikke en tunnel som videresender, og forskjellen vises i retningsretningen.
Når motpartene kobler til men LAN-verter ikke, undersøk returruten og kildeadressen den eksterne verten vil bruke. En vert med to grensesnitt kan svare fra feil grensesnitt, og ingen selektorendring reparerer det. Fang trafikk 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-connsHold en administrasjonsvei som ikke avhenger av tunnelen mens du arbeider. Tilbakerulling er lettere når gatewayens egen tilgang ikke rider på forbindelsen du feilsøker.