Rutebasert vs. policybasert nettstad-til-nettstad-VPN: kva som skil
Policybasert IPsec vel trafikk med ein selektor; rutebasert sender han gjennom eit tunnelgrensesnitt. Begge treng framleis brannmurreglar og ei returrute.
Begge designa vernar den same trafikken med den same IPsec-maskinen, og dei skil seg i kva som avgjer kva pakke som kjem inn i tunnelen. I ei policybasert sambinding gjer dei forhandla trafikkselektorane den jobben; i ei rutebasert gjer ei rute som peikar på eit tunnelgrensesnitt det. Å blande dei to gjev den kjende støttetråden der tunnelen melder seg etablert medan applikasjonen ikkje når noko. Skiljet tyder mest når du legg til eit nettverk, køyrer ein rutingsprotokoll eller feilsøkjer ein stig som stille forlèt gjennom feil utgang.
To måtar å avgjere kva som kjem inn i tunnelen
Ein policybasert VPN byggjer ein tryggingspolicy som samsvarar med kjelde- og målprefiks, og krypterer deretter alt som passar. Motparten må forhandle kompatible selektorar, så det effektive omfanget endar som snittet av det begge sider føreslo. Ingenting utanfor det snittet er verna, uansett kva rutetabellen seier.
Ein rutebasert VPN opprettar eit grensesnitt som representerer tunnelen og lèt rutetabellen sende trafikk inn i det. IKE-demonen installerer framleis tilstanden og policyen per grensesnitt, og det er detaljen folk hoppar over når dei avgjer at ruter har erstatta kryptering. Begge designa krypterer med IPsec; berre utvalsmekanismen er ulik.
Les samanlikninga nedanfor som eit sett feilsignaturar og ikkje som eit poengkort, fordi ingen av kolonnane vinn i seg 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 |
Policybasert: selektoren er kontrakten
Selektorar vert forhandla, ikkje berre konfigurerte. Føreslå 10.10.0.0/16 på den eine sida og 10.10.1.0/24 på den andre, så dekkjer assosiasjonen det forhandlinga landa på medan kvar annan vert held seg utanfor.
Les den installerte tilstanden i staden for konfigurasjonsfila. På ein Linux-motpart er kjernens eigne tabellar grunnsanninga, og dei viser kva som overlevde forhandlinga. Ein policy som namngjev dei rette prefiksa utan samsvarande tilstand tyder at assosiasjonen aldri kom opp. Tilstand saman med ein policy for feil prefiks er det motsette problemet, og det gjev tunnelen som ser sunn ut medan eitt subnett ikkje når noko.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasSamanlikn begge utdata med prefiksa du trur du vernar. Den eine samanlikninga løyser dei fleste rapportane om ein fungerande tunnel med ein utilgjengeleg tenar. Ho peikar òg på kva motpart som skal endrast, sidan avviket vanlegvis berre er synleg i éi retning.
Rutebasert: grensesnittet er kontrakten
Eit XFRM-grensesnitt gjev tunnelen eit namn og ein identitet, og trafikk når det fordi rutetabellen seier det. Fleire fjerne prefiks vert då eit rutingsproblem i staden for eit selektorproblem, og ein rutingsprotokoll kan annonsere dei. Det er den verkelege vinsten, ikkje kryptering.
Grensesnittet fjernar ikkje behovet for policy. Demonen installerer reglar per grensesnitt bundne til grensesnittidentiteten, så ein pakke som kjem inn på feil grensesnitt feilar framleis. Ei kjeldeadresse motparten ikkje vil godta feilar òg, sjølv med ei perfekt rute. Rutebasert tyder at ruta avgjer inngangen, ikkje 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.10Fylg med på grensesnittteljarane når ruta er på plass. Ei rute som finst medan teljarane blir ståande på null tyder at ingenting vert matcha inn i tunnelen, noko som vanlegvis peikar på ein manglande tilstand snarare enn ei manglande rute.
Kvar dei to designa faktisk skil lag
Å leggje til eit nettverk er den reinaste testen på kva modell som passar deg. Eit rutebasert design legg til ei rute og utvidar høgst selektoren éin gong, medan eit policybasert design redigerer prefikspar på begge motpartane og forhandlar på nytt. To stabile subnett gjer den redigeringa triviell, og tjue gjer ho til eit prosjekt.
Ingen av modellane erstattar ein brannmur, og samanlikningar stoppar vanlegvis før dette punktet. Ein brei selektor eller ei brei rute avgjer kva som vert kryptert, ikkje kva som er tillate.
MTU-åtferda er òg ulik i praksis. Innpakking reduserer nyttelasta, og eit rutebasert grensesnitt ber sin eigen MTU, så MSS-klamping ved begge gatewayane unngår svart hol-symtomet der små svar kjem inn og store forsvinn. Policybaserte tunnelar møter den same veggen frå den andre sida, fordi ein selektor ikkje seier noko om pakkestorleik. Set klampa medvite i staden for å klandre motparten.
Migrering utan å miste returvegen
Registrer dei eksisterande prefikspara før du endrar noko, flytt deretter ein applikasjonssti og fylg han ende til ende. Ein tunnel som etablerer seg er ikkje ein tunnel som videresender, og skiljet viser seg i retningsretninga.
Når motpartane koplar til men LAN-vertar ikkje, gransk returruta og kjeldeadressa den fjerne verten vil bruke. Ein vert med to grensesnitt kan svare frå feil grensesnitt, og inga selektorendring reparerer det. Fang trafikk i begge endar før du redigerer algoritmar.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsHald ein administrasjonsveg som ikkje er avhengig av tunnelen medan du arbeider. Tilbakerulling er lettare når eigen tilgang til gatewayen ikkje rir på sambindinga du feilsøkjer.