Të dy modelet mbrojnë të njëjtin trafik me të njëjtën mekanizëm IPsec, dhe ndryshojnë në atë që vendos se cili paketë hyn në tunel. Në një lidhje të bazuar në politika këtë punë e bëjnë përzgjedhësit e trafikut të negociuar; në një të bazuar në rrugë e bën një rrugë që tregon drejt një ndërfaqeje tuneli. Ngatërrimi i të dyjave prodhon atë temë të njohur mbështetjeje ku tuneli raportohet i vendosur ndërsa aplikacioni nuk arrin asgjë. Diferenca ka më shumë rëndësi kur shton një rrjet, ekzekuton një protokoll rrugëtimi ose korrigjon një shteg që del në heshtje nga dalja e gabuar.

Dy mënyra për të vendosur çfarë hyn në tunel

Një VPN i bazuar në politika ndërton një politikë sigurie që përputhet me prefikset e burimit dhe destinacionit, pastaj kripton gjithçka që përshtatet. Palët duhet të negociojnë përzgjedhës të pajtueshëm, prandaj shtrirja efektive përfundon si prerja e asaj që propozuan të dyja palët. Asgjë jashtë asaj prerjeje nuk mbrohet, çfarëdo që thotë tabela e rrugëtimit.

Një VPN i bazuar në rrugë krijon një ndërfaqe që përfaqëson tunelin dhe lejon tabelën e rrugëtimit të dërgojë trafik në të. Daemoni IKE ende instalon gjendjen dhe politikën për çdo ndërfaqe, dhe ky është detaji që njerëzit e anashkalojnë kur vendosin se rrugët kanë zëvendësuar kriptimin. Të dy modelet kriptojnë me IPsec; ndryshon vetëm mekanizmi i përzgjedhjes.

Lexojeni krahasimin më poshtë si një grup shenjash dështimi dhe jo si një tabelë pikësh, sepse asnjë kolonë nuk fiton më vete.

AspectPolicy-basedRoute-based
What selects trafficNegotiated selectorsA route into the tunnel interface
Adding a networkEdit selectors on both peersAdd a route, widen the selector once
Dynamic routingAwkward to run over the tunnelRuns over the interface directly
Typical failureTunnel up, host outside the selectorTunnel up, no route or wrong source

I bazuar në politika: përzgjedhësi është kontrata

Përzgjedhësit negociohen, nuk konfigurohen thjesht. Propozo 10.10.0.0/16 nga njëra anë dhe 10.10.1.0/24 nga ana tjetër, dhe shoqërimi do të mbulojë atë ku u ndal negocimi, ndërsa çdo strehë tjetër mbetet jashtë.

Lexo gjendjen e instaluar në vend të skedarit të konfigurimit. Në një palë Linux tabelat e vetë kernelit janë e vërteta bazë, dhe tregojnë çfarë mbijetoi nga negocimi. Një politikë që emërton prefikset e duhura pa gjendje përputhëse do të thotë që shoqërimi nuk u ngrit kurrë. Gjendja e çiftuar me një politikë për prefiksin e gabuar është problemi i kundërt, dhe prodhon tunelin që duket i shëndetshëm ndërsa një nënrrjet nuk arrin asgjë.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Krahaso të dyja daljet me prefikset që mendon se po mbron. Ai krahasim i vetëm zgjidh shumicën e raportimeve për një tunel që funksionon me një server të paarritshëm. Tregon gjithashtu cilën palë duhet ndryshuar, sepse mospërputhja zakonisht shihet vetëm në një drejtim.

I bazuar në rrugë: ndërfaqja është kontrata

Një ndërfaqe XFRM i jep tunelit një emër dhe një identitet, dhe trafiku arrin tek ajo sepse kështu thotë tabela e rrugëtimit. Disa prefikse të largëta pastaj bëhen problem rrugëtimi dhe jo problem përzgjedhësi, dhe një protokoll rrugëtimi mund t'i shpallë ato. Ky është përfitimi i vërtetë, jo kriptimi.

Ndërfaqja nuk e heq nevojën për politikë. Daemoni instalon rregulla për çdo ndërfaqe të lidhura me identitetin e ndërfaqes, kështu që një paketë që arrin në ndërfaqen e gabuar ende dështon. Një adresë burimi që pala nuk do të pranojë dështon gjithashtu, edhe me një rrugë të përsosur. I bazuar në rrugë do të thotë që rruga vendos hyrjen, jo që politika është zhdukur.

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.10

Vëzhgo numëruesit e ndërfaqes pasi rruga të jetë në vend. Një rrugë që ekziston ndërsa numëruesit mbeten në zero do të thotë që asgjë nuk po përputhet në tunel, çka zakonisht tregon një gjendje që mungon dhe jo një rrugë që mungon.

Ku ndryshojnë vërtet dy modelet

Shtimi i një rrjeti është testi më i pastër i modelit që ju përshtatet. Një model i bazuar në rrugë shton një rrugë dhe zgjeron përzgjedhësin më së shumti një herë, ndërsa një model i bazuar në politika redakton palë prefiksesh në të dyja palët dhe rinegocion. Dy nënrrjeta të qëndrueshme e bëjnë atë redaktim të parëndësishëm, dhe njëzet e kthejnë në projekt.

Asnjë model nuk zëvendëson një firewall, dhe krahasimet zakonisht ndalen para kësaj pike. Një përzgjedhës i gjerë ose një rrugë e gjerë vendos çfarë kriptohet, jo çfarë lejohet.

Sjellja e MTU-së ndryshon gjithashtu në praktikë. Enkapsulimi zvogëlon ngarkesën e përdorshme, dhe një ndërfaqe e bazuar në rrugë mbart MTU-në e vet, kështu që shtrëngimi i MSS në të dy portat shmang simptomën e vrimës së zezë ku përgjigjet e vogla vijnë dhe ato të mëdha zhduken. Tunelet e bazuar në politika ndeshen me të njëjtin mur nga ana tjetër, sepse përzgjedhësi nuk thotë asgjë për madhësinë e paketës. Vendos shtrëngimin me qëllim në vend që të fajësosh palën.

Migrim pa humbur rrugën e kthimit

Regjistro palët ekzistuese të prefikseve përpara se të ndryshosh diçka, pastaj zhvendos një shteg aplikacioni dhe ndiqe nga fillimi në fund. Një tunel që vendoset nuk është një tunel që përcjell, dhe diferenca shfaqet në drejtimin e përgjigjes.

Kur palët lidhen por strehët e LAN-it jo, inspekto rrugën e kthimit dhe adresën e burimit që do të përdorë streha e largët. Një strehë me dy ndërfaqe mund të përgjigjet nga e gabuara, dhe asnjë ndryshim përzgjedhësi nuk e rregullon atë. Kap trafikun në të dy skajet përpara se të redaktosh algoritmet.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Mbaj një shteg administrimi që nuk varet nga tuneli ndërsa punon. Kthimi pas është më i lehtë kur aksesi i vetë portës nuk kalon mbi lidhjen që po korrigjon.

Artikuj të ngjashëm