Maršrutais pagrįstas vs. politika pagrįstas VPN tarp svetainių: kuo skiriasi
Politika pagrįstas IPsec parenka srautą selektoriumi; maršrutais pagrįstas siunčia jį per tunelio sąsają. Abiem vis dar reikia ugniasienės taisyklių ir grįžtamojo maršruto.
Abu sprendimai apsaugo tą patį srautą ta pačia IPsec mašina, o skiriasi tuo, kas nusprendžia, kuris paketas patenka į tunelį. Politika pagrįstame ryšyje tai daro suderėti srauto selektoriai; maršrutais pagrįstame – maršrutas, nukreiptas į tunelio sąsają. Sumaišius abu, gaunamas pažįstamas pagalbos siužetas, kuriame tunelis praneša esąs sukurtas, o programėlė nieko nepasiekia. Skirtumas svarbiausias tada, kai pridedate tinklą, paleidžiate maršrutizavimo protokolą arba derinate kelią, kuris tyliai išeina pro netinkamą išėjimą.
Du būdai nuspręsti, kas patenka į tunelį
Politika pagrįstas VPN sukuria saugumo politiką, atitinkančią šaltinio ir paskirties priešdėlius, tada užšifruoja viską, kas tinka. Partneris turi suderėti suderinamus selektorius, todėl veiksminga apimtis galiausiai tampa abiejų pusių pasiūlytų dalykų sankirta. Niekas už tos sankirtos neapsaugotas, ką bebūtų sakoma maršrutizavimo lentelėje.
Maršrutais pagrįstas VPN sukuria sąsają, kuri atstovauja tuneliui, ir leidžia maršrutizavimo lentelei siųsti srautą į ją. IKE demonas vis dar įdiegia būseną ir kiekvienos sąsajos politiką, ir tai yra detalė, kurią praleidžia nusprendusieji, kad maršrutai pakeitė šifravimą. Abu sprendimai šifruoja IPsec; skiriasi tik pasirinkimo mechanizmas.
Skaitykite žemiau pateiktą palyginimą kaip gedimų požymių rinkinį, o ne kaip taškų lentelę, nes nė vienas stulpelis nelaimi pats savaime.
| 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 |
Politika pagrįstas: selektorius yra sutartis
Selektoriai derinami, o ne vien konfigūruojami. Pasiūlykite 10.10.0.0/16 vienoje pusėje ir 10.10.1.0/24 kitoje, ir asociacija apims tai, prie ko sustojo derybos, o visi kiti mazgai liks už jos ribų.
Skaitykite įdiegtą būseną, o ne konfigūracijos failą. Linux partneriui paties branduolio lentelės yra pagrindinė tiesa, ir jos parodo, kas išliko po derybų. Politika, kuri nurodo teisingus priešdėlius be atitinkamos būsenos, reiškia, kad asociacija taip ir nebuvo sukurta. Būsena su politika neteisingam priešdėliui yra priešinga problema, ir ji sukuria tunelį, kuris atrodo sveikas, kol vienas potinklis nieko nepasiekia.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasPalyginkite abu išvedimus su priešdėliais, kuriuos manote saugantys. Šis vienas palyginimas išsprendžia daugumą pranešimų apie veikiantį tunelį su nepasiekiamu serveriu. Jis taip pat parodo, kurį partnerį keisti, nes neatitikimas paprastai matomas tik viena kryptimi.
Maršrutais pagrįstas: sąsaja yra sutartis
XFRM sąsaja suteikia tuneliui vardą ir tapatybę, o srautas ją pasiekia todėl, kad taip sako maršrutizavimo lentelė. Keli nutolę priešdėliai tada tampa maršrutizavimo problema, o ne selektoriaus problema, ir maršrutizavimo protokolas gali juos skelbti. Tai tikrasis pelnas, o ne šifravimas.
Sąsaja nepanaikina politikos poreikio. Demonas įdiegia su sąsajos tapatybe susietas taisykles kiekvienai sąsajai, todėl į netinkamą sąsają atėjęs paketas vis tiek nepraeina. Šaltinio adresas, kurio partneris nepriims, taip pat nepraeina, net ir esant tobulam maršrutui. Maršrutais pagrįstas reiškia, kad maršrutas sprendžia įėjimą, o ne kad politika dingo.
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.10Stebėkite sąsajos skaitiklius, kai maršrutas jau vietoje. Maršrutas egzistuoja, o skaitikliai stovi prie nulio – tai reiškia, kad niekas nėra suderinama į tunelį, ir paprastai tai rodo trūkstamą būseną, o ne trūkstamą maršrutą.
Kur šie du sprendimai iš tikrųjų išsiskiria
Tinklo pridėjimas yra švariausias bandymas, kuris modelis jums tinka. Maršrutais pagrįstas sprendimas prideda maršrutą ir daugiausiai vieną kartą praplečia selektorių, o politika pagrįstas sprendimas redaguoja priešdėlių poras abiejuose partneriuose ir iš naujo derasi. Du stabilūs potinkliai tą redagavimą daro trivialiu, o dvidešimt – projektu.
Nė vienas modelis nepakeičia ugniasienės, ir palyginimai paprastai sustoja prieš šį tašką. Platus selektorius ar platus maršrutas nusprendžia, kas šifruojama, o ne kas leidžiama.
MTU elgsena praktiškai taip pat skiriasi. Inkapsuliavimas sumažina naudingąją apkrovą, o maršrutais pagrįsta sąsaja turi savo MTU, todėl MSS suspaudimas abiejuose vartuose išvengia juodosios skylės simptomo, kai ateina maži atsakymai, o dideli dingsta. Politika pagrįsti tuneliai susiduria su ta pačia siena iš kitos pusės, nes selektorius nieko nesako apie paketo dydį. Nustatykite suspaudimą sąmoningai, o ne kaltinkite partnerį.
Perėjimas neprarandant grįžtamojo kelio
Užrašykite esamas priešdėlių poras prieš ką nors keisdami, tada perkelkite vieną programos kelią ir stebėkite jį nuo pradžios iki pabaigos. Sukurtas tunelis nėra tunelis, kuris persiunčia, ir skirtumas pasirodo atsakymo kryptimi.
Kai partneriai prisijungia, bet LAN mazgai ne, patikrinkite grįžtamąjį maršrutą ir šaltinio adresą, kurį naudos nutolęs mazgas. Mazgas su dviem sąsajomis gali atsakyti iš netinkamos, ir joks selektoriaus pakeitimas to nesutaiso. Užfiksuokite srautą abiejuose galuose prieš redaguodami algoritmus.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsDirbdami palaikykite valdymo kelią, kuris nepriklauso nuo tunelio. Grįžti atgal lengviau, kai paties vartų prieiga nevažiuoja tuo ryšiu, kurį derinate.