A është tunelimi i plotë më i thjeshtë se një listë e gjatë e tunelimit të ndarë?

Një listë e tunelimit të ndarë nis me tre aplikacione dhe përfundon duke mbuluar pjesën më të madhe të makinës, dhe çdo rresht i ri është përjashtimi i dikujt. Në atë pikë lista është kthyer në heshtje në një parazgjedhje me hapa shtesë. Tunelimi i plotë e përmbys rregullimin: gjithçka hyn në tunel, përveç nëse një përjashtim i dokumentuar thotë ndryshe. Nëse kjo është më e thjeshtë varet nga gateway-i dhe nga shërbimet lokale që do të prisnit.

Filloni duke numëruar rregullat që mirëmbani

Numëroni zërat, pastaj numëroni sa prej tyre kanë një pronar të emërtuar dhe një datë të verifikimit të fundit. Numri i dytë është ai që ka rëndësi, sepse një përjashtim pa pronar nuk mund të vlerësohet kur softueri të cilin e referon riemërtohet ose zëvendësohet. Rregullat e lidhura me një shteg ekzekutuesi dështojnë në heshtje pas një përditësimi, dhe dështimi duket si një VPN i paqëndrueshëm dhe jo si një rregull i vjetruar. Shkruajeni listën përpara se të krijoni një mendim për të.

Çdo zë duhet t'i përgjigjet tre pyetjeve: çfarë prishet pa të, kush e vendosi këtë dhe si do ta vinit re nëse arsyeja skadoi. Zërat që nuk mund t'u përgjigjen të trejave janë kandidatë për fshirje dhe jo për migrim, dhe fshirja e tyre së pari e bën krahasimin e mëvonshëm të ndershëm.

Nëse shumica e zërave drejtojnë një pjesë të madhe të trafikut, ju tashmë po drejtoni një tunel të plotë me një barrë mirëmbajtjeje të bashkangjitur. Vendimi atëherë ka të bëjë me atë ku banon parazgjedhja, jo me atë nëse duhet të keni një të tillë.

Kontrolloni nëse gateway-i mund ta mbajë parazgjedhjen

Tunelimi i plotë e zhvendos çdo paketë në një pajisje të vetme, gjë që ndryshon njëkohësisht ngarkesën e CPU-së, tabelën conntrack, përkthimin e adresave dhe kërkesën për bandwidth në dalje të asaj pajisjeje. Një gateway që u shërbente me lehtësi disa nënrrjetave të brendshme mund të mos jetë dimensionuar për të gjithë shfletimin e një përdoruesi. Shikoni numrin më të madh të seancave të njëkohshme që prisni, jo mesataren, sepse maja thyhet e para.

ip -s link show dev tun0
conntrack -C
ss -s

Matni të njëjtën ngarkesë para dhe pas ndryshimit në vend që të arsyetoni nga specifikimet. Një pasdite e vetme përdorimi të zakonshëm në një makinë do të tregojë nëse gateway-i është afër një kufiri, dhe nuk kushton asgjë në krahasim me zbulimin e kësaj një mëngjes të hënë.

Kontrolloni gjithashtu path MTU nga skaji në skaj, sepse një parazgjedhje e plotë e ekspozon çdo aplikacion ndaj madhësisë maksimale të paketës së tunelit. Aplikacionet që funksiononin jashtë tunelit tani mund të varen nga një sjellje fragmentimi për të cilën nuk ju është dashur të mendoni kurrë.

Konfirmoni që shërbimet lokale dhe DNS-i privat ende funksionojnë

Numëroni çfarë duhet të mbetet lokale sipas protokollit dhe jo sipas emrit të aplikacionit: protokollet e zbulimit për printera dhe ekrane, një urë shtëpie inteligjente, faqja e administrimit e një router-i, një server zhvillimi lokal i arritur përmes një emri që zgjidhet vetëm në LAN. Këto prishen kur rruga e parazgjedhur fillon të tregojë në një tunel, dhe prishen në heshtje sepse asgjë nuk regjistron një gabim në klient.

DNS-i privat është varësia tjetër. Nëse emrat e brendshëm zgjidheshin më parë nga resolver-i i tunelit, asgjë nuk ndryshon; nëse zgjidheshin lokalisht, një parazgjedhje e plotë duhet t'i çojë ata te një resolver që njeh zonat. Testoni një emër të brendshëm dhe një emër publik pas ndryshimit në vend që të supozoni se lista e resolver-ave mbijetoi.

Shkruani përjashtimet lokale në profilin që i zotëron ato. Një përjashtim i mbajtur vetëm në kujtesën e dikujt është gjëja e parë që humbet migrimi i ardhshëm.

Migroni një profil dhe verifikoni kufijtë

Ndryshoni profilin përmes konfigurimit që e zotëron atë, në vend që të vendosni një parazgjedhje të re mbi rrugë manuale të lëna nga eksperimentet e mëparshme. Ato rrugë të mbetura janë shkaku i zakonshëm i një migrimi që duket se funksionon dhe sillet në mënyrë jokonsistente një ditë më vonë. Mbani profilin e vjetër në dispozicion, në mënyrë që kthimi të jetë një zgjedhje dhe jo një rindërtim.

Pastaj verifikoni dy kufij veçmas: që destinacionet publike dhe private funksionojnë të dyja, dhe që trafiku i padëshiruar nuk del jashtë tunelit. Një ngarkim i suksesshëm faqeje provon të parin dhe nuk thotë asgjë për të dytin.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Përsëritni kontrollin pas një rilidhjeje dhe pas një ndërprerjeje, sepse një kill switch që bllokon trafikun gjatë një rënieje është një veti tjetër nga një rrugë që rikthehet saktë më pas. Dizajni më i thjeshtë është ai mbulimin real të cilit mund ta shpjegoni ende pasi një aplikacion ose një rrjet ndryshon.