Rûtebasearre vs. beliedsbasearre side-nei-side VPN: wat ferskilt
Beliedsbasearre IPsec kiest ferkear mei in selektor; rûtebasearre stjoert it troch in tunnelinterface. Beide hawwe noch firewalledielen en in weromrûte nedich.
Beide ûntwerpen beskermje itselde ferkear mei deselde IPsec-masjinerie, en se ferskille yn wat beslút hokker pakket de tunnel yn giet. Yn in beliedsbasearre ferbining dogge de ûnderhannele ferkearsselektors dat wurk; yn in rûtebasearre ien docht in rûte dy't nei in tunnelinterface wiist dat. It trochinoar heljen fan de twa leveret in bekende stipe-thread op wêryn't de tunnel him as oprjochte rapportearret wylst de applikaasje neat berikt. It ûnderskied is it wichtichst as jo in netwurk tafoegje, in rûteprotokol draaie of in paad debugge dat stil fia de ferkearde útgong fuortgiet.
Twa manieren om te besluten wat de tunnel yn giet
In beliedsbasearre VPN bout in befeiligingsbelied dat boarne- en bestimmingprefiksen matchet, en fersiferet dan wat past. De peer moat kompatibele selektors ûnderhannelje, dus einiget it effektive berik as de krusing fan wat beide kanten foarstelden. Neat bûten dy krusing wurdt beskerme, wat de rûtetabel ek seit.
In rûtebasearre VPN makket in ynterface dat de tunnel fertsjintwurdiget en lit de rûtetabel ferkear deryn stjoere. De IKE-daemon ynstallearret noch de steat en it belied per ynterface, en dat is it detail dat minsken oerslaan as se beslute dat rûtes de fersifering ferfongen hawwe. Beide ûntwerpen fersiferje mei IPsec; allinnich it seleksjemeganisme ferskilt.
Lês de ferliking hjirûnder as in set flatertekens ynstee fan in puntetabel, want gjin inkelde kolom wint op himsels.
| 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 |
Beliedsbasearre: de selektor is it kontrakt
Selektors wurde ûnderhannele, net allinnich ynsteld. Stel 10.10.0.0/16 oan ien kant foar en 10.10.1.0/24 oan de oare, en de assosjaasje dekt wat de ûnderhanneling beslist hat wylst elke oare host derbûten bliuwt.
Lês de ynstallearre steat ynstee fan it konfiguraasjebestân. Op in Linux-peer binne de eigen tabellen fan 'e kernel de grûnwierheid, en se litte sjen wat de ûnderhanneling oerlibbe. In belied dat de juste prefiksen neamt sûnder byhearrende steat betsjut dat de assosjaasje nea omheech kaam. Steat peard mei in belied foar it ferkearde prefiks is it tsjinstelde probleem, en it leveret de tunnel dy't sûn liket wylst ien subnet neat berikke kin.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasFergelykje beide útgongen mei de prefiksen dy't jo tinke te beskermjen. Dy iene ferliking lost de measte rapporten op fan in wurkjende tunnel mei in ûnberikbere server. It wiist ek op hokker peer te feroarjen, want de misferhâlding is meastentiids mar yn ien rjochting sichtber.
Rûtebasearre: it ynterface is it kontrakt
In XFRM-ynterface jout de tunnel in namme en in identiteit, en ferkear berikt it om't de rûtetabel dat seit. Ferskate fiere prefiksen wurde dan in rûteprobleem ynstee fan in selektorprobleem, en in rûteprotokol kin se oankundigje. Dat is de echte winst, net fersifering.
It ynterface hellet de needsaak fan belied net fuort. De daemon ynstallearret regels per ynterface bûn oan 'e ynterface-identiteit, dus in pakket dat op it ferkearde ynterface oankomt mislearret noch altyd. In boarneadres dat de peer net akseptearret mislearret ek, sels mei in perfekte rûte. Rûtebasearre betsjut dat de rûte de yngong beslút, net dat it belied ferdwûn is.
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âld de ynterface-tellers yn 'e gaten as de rûte ienris stiet. In rûte dy't bestiet wylst de tellers op nul bliuwe betsjut dat neat yn 'e tunnel matcht, wat meastentiids op in ûntbrekkende steat wiist ynstee fan in ûntbrekkende rûte.
Wêr't de twa ûntwerpen wier skiede
In netwurk tafoegje is de skjinste test fan hokker model by jo past. In rûtebasearre ûntwerp foeget in rûte ta en ferbreedet de selektor op syn heechst ien kear, wylst in beliedsbasearre ûntwerp prefiksparen oan beide kanten bewurket en opnij ûnderhannelet. Twa stabile subnets meitsje dy bewurking triviaal, en tweintich meitsje der in projekt fan.
Gjin fan beide modellen ferfangt in firewall, en ferlikingen stopje meastentiids foar dit punt. In breed selektor of in brede rûte beslút wat fersifere wurdt, net wat tastien is.
It MTU-gedrach ferskilt ek yn 'e praktyk. Ynkapseling ferminderet de brûkbere lading, en in rûtebasearre ynterface draacht syn eigen MTU, dus MSS klemme by beide poarten foarkomt it swartgat-symtoom wêrby't lytse antwurden oankomme en grutte ferdwine. Beliedsbasearre tunnels treffe deselde muorre fan 'e oare kant, want in selektor seit neat oer pakketgrutte. Set de klem mei opsetsin ynstee fan de peer de skuld te jaan.
Migrearje sûnder de weromwei te ferliezen
Skriuw de besteande prefiksparen op foardat jo wat feroarje, ferpleats dan ien applikaasjepaad en folgje it fan begjin oant ein. In tunnel dy't oprjochte wurdt is gjin tunnel dy't trochstjoert, en it ferskil ferskynt yn 'e antwurd-rjochting.
As de peers ferbine mar LAN-hosts net, ûndersykje dan de weromrûte en it boarneadres dat de fiere host brûke sil. In host mei twa ynterfaces kin fan it ferkearde ien antwurdzje, en gjin selektorwiziging reparearret dat. Fange ferkear op beide einen foardat jo algoritmen bewurkje.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsHâld in behearspaad dat net fan de tunnel ôfhinget wylst jo wurkje. Weromrôlje is makliker as de eigen tagong fan 'e poarte net op 'e ferbining rydt dy't jo debugge.