Maršrutē balstīts vs. politikā balstīts VPN starp vietnēm: ar ko atšķiras
Politikā balstīts IPsec izvēlas datu plūsmu ar selektoru; maršrutē balstīts to sūta caur tuneļa saskarni. Abiem joprojām vajadzīgi ugunsmūra noteikumi un atgriešanās maršruts.
Abi risinājumi aizsargā vienu un to pašu plūsmu ar vienu un to pašu IPsec mehānismu, un tie atšķiras ar to, kas izlemj, kurš pakete nonāk tunelī. Politikā balstītā savienojumā to dara saskaņotie plūsmas selektori; maršrutē balstītā to dara maršruts, kas norāda uz tuneļa saskarni. Abu sajaukšana rada pazīstamu atbalsta sarunu, kurā tunelis ziņo, ka ir izveidots, bet lietotne nekur nenonāk. Atšķirība ir vissvarīgākā, kad pievienojat tīklu, palaižat maršrutēšanas protokolu vai atkļūdojat ceļu, kas klusi aiziet pa nepareizo izeju.
Divi veidi, kā izlemt, kas nonāk tunelī
Politikā balstīts VPN izveido drošības politiku, kas atbilst avota un galamērķa prefiksiem, un pēc tam šifrē visu, kas atbilst. Partnerim ir jāsaskaņo saderīgi selektori, tāpēc faktiskais apjoms galu galā kļūst par abu pušu piedāvātā krustojumu. Nekas ārpus šī krustojuma nav aizsargāts, ko vien saka maršrutēšanas tabula.
Maršrutē balstīts VPN izveido saskarni, kas pārstāv tuneli, un ļauj maršrutēšanas tabulai sūtīt tajā plūsmu. IKE dēmons joprojām instalē stāvokli un katras saskarnes politiku, un tas ir tas sīkums, ko izlaiž, kad nolemj, ka maršruti ir aizstājuši šifrēšanu. Abi risinājumi šifrē ar IPsec; atšķiras tikai izvēles mehānisms.
Lasiet zemāk esošo salīdzinājumu kā bojājumu pazīmju kopumu, nevis kā punktu tabulu, jo neviena kolonna neuzvar pati par sevi.
| 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 |
Politikā balstīts: selektors ir līgums
Selektori tiek saskaņoti, nevis vienkārši konfigurēti. Piedāvājiet 10.10.0.0/16 vienā pusē un 10.10.1.0/24 otrā, un asociācija aptvers to, pie kā apstājās sarunas, bet visi pārējie saimnieki paliks ārpusē.
Lasiet instalēto stāvokli, nevis konfigurācijas failu. Linux partnerim paša kodola tabulas ir pamata patiesība, un tās parāda, kas izdzīvoja sarunās. Politika, kas nosauc pareizos prefiksus bez atbilstoša stāvokļa, nozīmē, ka asociācija nekad netika izveidota. Stāvoklis kopā ar politiku nepareizajam prefiksam ir pretēja problēma, un tas rada tuneli, kas izskatās vesels, kamēr viena apakštīkla nekur nenonāk.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasSalīdziniet abas izejas ar prefiksiem, kurus, jūsuprāt, aizsargājat. Šis viens salīdzinājums atrisina lielāko daļu ziņojumu par strādājošu tuneli ar nesasniedzamu serveri. Tas arī parāda, kuru partneri mainīt, jo neatbilstība parasti ir redzama tikai vienā virzienā.
Maršrutē balstīts: saskarne ir līgums
XFRM saskarne piešķir tunelim vārdu un identitāti, un plūsma to sasniedz tāpēc, ka tā saka maršrutēšanas tabula. Vairāki attāli prefiksi tad kļūst par maršrutēšanas problēmu, nevis selektora problēmu, un maršrutēšanas protokols var tos paziņot. Tas ir īstais ieguvums, nevis šifrēšana.
Saskarne neatceļ politikas nepieciešamību. Dēmons instalē noteikumus katrai saskarnei, kas piesaistīti saskarnes identitātei, tāpēc pakete, kas ierodas nepareizajā saskarnē, joprojām neiztur. Arī avota adrese, ko partneris nepieņems, neiztur, pat ar perfektu maršrutu. Maršrutē balstīts nozīmē, ka maršruts izlemj ieeju, nevis to, ka politika ir pazudusi.
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.10Vērojiet saskarnes skaitītājus, kad maršruts ir vietā. Maršruts pastāv, bet skaitītāji paliek uz nulles – tas nozīmē, ka tunelī nekas netiek saskaņots, un tas parasti norāda uz trūkstošu stāvokli, nevis trūkstošu maršrutu.
Kur abi risinājumi patiešām atšķiras
Tīkla pievienošana ir vistīrākais pārbaudījums, kurš modelis jums piemērots. Maršrutē balstīts risinājums pievieno maršrutu un labākajā gadījumā vienu reizi paplašina selektoru, bet politikā balstīts risinājums rediģē prefiksu pārus abos partneros un sarunājas no jauna. Divi stabili apakštīkli padara šo rediģēšanu triviālu, un divdesmit padara to par projektu.
Neviens modelis neaizstāj ugunsmūri, un salīdzinājumi parasti apstājas pirms šī punkta. Plašs selektors vai plašs maršruts izlemj, kas tiek šifrēts, nevis kas ir atļauts.
Arī MTU uzvedība praksē atšķiras. Iekapsulēšana samazina izmantojamo kravu, un maršrutē balstīta saskarne nes savu MTU, tāpēc MSS savilkšana abos vārtejos izvairās no melnās bedres simptoma, kurā ierodas mazas atbildes un lielās pazūd. Politikā balstīti tuneļi saskaras ar to pašu sienu no otras puses, jo selektors neko nepasaka par paketes izmēru. Iestatiet savilkšanu apzināti, nevis vainojiet partneri.
Pāreja, nezaudējot atgriešanās ceļu
Pierakstiet esošos prefiksu pārus pirms kaut kā maiņas, pēc tam pārvietojiet vienu lietotnes ceļu un vērojiet to no sākuma līdz beigām. Izveidots tunelis nav tunelis, kas pārsūta, un atšķirība parādās atbildes virzienā.
Kad partneri savienojas, bet LAN saimnieki nevar, pārbaudiet atgriešanās maršrutu un avota adresi, ko izmantos attālais saimnieks. Saimnieks ar divām saskarnēm var atbildēt no nepareizās, un nekāda selektora maiņa to nelabo. Tveriet plūsmu abos galos pirms algoritmu rediģēšanas.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsStrādājot saglabājiet pārvaldības ceļu, kas nav atkarīgs no tuneļa. Atgriezties atpakaļ ir vieglāk, ja pašas vārtejas piekļuve nebrauc pa savienojumu, kuru atkļūdojat.