Si t'i dallosh rrugët e shtyra nga VPN nga ato statike në Linux

Një prefiks shfaqet në laptop kur tuneli ngrihet, ndaj duket sikur e ka instaluar VPN-i. Mund ta ketë bërë, por i njëjti rezultat mund të vijë nga një skript klienti që ekzekutohet gjatë lidhjes, nga një profil lidhjeje që liston nënrrjetin, ose nga një rrugë statike që ishte aty që në fillim dhe filloi të funksionojë vetëm kur ndërfaqja ekzistonte. Zgjedhja e pronarit të gabuar do të thotë që rruga kthehet pas çdo pastrimi dhe personi tjetër përsërit të njëjtin rregullim. Sekuenca më poshtë i ndan këto të tre përpara se të ndryshohet diçka.

Hapi 1: emërtoni mekanizmin që instalon prefikset

Protokolle të ndryshme ofrojnë arritshmëri në mënyra të ndryshme, dhe quajtja e të gjithë kësaj njoftim fsheh dallimin. Një server OpenVPN shtyn një direktivë rruge përmes kanalit të kontrollit dhe klienti e instalon, përveç nëse një filtër pull e bllokon. Një konfigurim WireGuard liston lokalisht prefikset e lejuara, të cilat klienti i përdor si për rrugëtimin e çelësave kriptografikë ashtu edhe për rrugët që shton. Një tunel IPsec bie dakord për përzgjedhës trafiku me palën tjetër, dhe kerneli instalon rrugë nga ata përzgjedhës.

Identifikoni cilin prej tyre përdor tuneli juaj përpara se të lexoni çdo tabelë. Një rrugë e shtyrë gjatë lidhjes nuk është njoftim i një protokolli rrugëtimi dhe nuk premton se prefiksi është i arritshëm pas skajit të largët. Shënoni mekanizmin pranë prefiksit, sepse ai vendos ku i takon rregullimi.

Hapi 2: krahasoni tabelën gjatë një lidhjeje

Ruani tabelën kryesore me tunelin poshtë, ngrijeni, ruajeni përsëri dhe krahasoni dy kapjet. Çdo gjë që u shfaq i takon ciklit të jetës së lidhjes, dhe çdo gjë që mbeti i takon konfigurimit lokal.

Kapeni me ip route show table main > /tmp/route-down.txt, lidhuni dhe kapeni përsëri. Bëni të njëjtën gjë për ip -6 route nëse faqja përdor IPv6, sepse një prefiks që mungon atje prodhon dështime që duken të palidhura me rrugëtimin.

Hapi 3: lexoni metrikën, jo vetëm praninë

Dy zëra për të njëjtin prefiks mund të bashkëjetojnë, dhe kerneli zgjedh metrikën më të ulët. Një rrugë statike me metrikë 50 do të vazhdojë të fitojë ndaj një rruge të shtyrë në 100 edhe pse të dyja janë të dukshme, prandaj 'rruga është atje' dhe 'trafiku e përdor' janë deklarata të ndryshme.

Pyetni kernelin drejtpërdrejt me ip route get 10.20.5.7 dhe lexoni ndërfaqen që raporton. Nëse trafiku del përmes përshtatësit fizik ndërsa një rrugë e tunelit qëndron në tabelë, metrika ose gjatësia e prefiksit e shpjegon atë, jo klienti VPN. Përsëritni kërkimin për një host që e dini se është pas tunelit dhe për një që e dini se nuk është, dhe dallimi tregon nëse ndarja sillet siç është menduar.

Hapi 4: gjeni zërat që jetojnë më shumë se tuneli

Rrugët statike i mbijetojnë shkëputjes sipas dizajnit, dhe prej andej vijnë zërat e vjetruar. Një rrugë e përhershme drejt një ndërfaqeje që nuk ekziston më mund të gëlltisë në heshtje një nënrrjet, dhe një drejt një emri ndërfaqeje të ripërdorur mund të dërgojë trafik privat nga dera e gabuar pas një rindezjeje.

Kontrolloni anën e përhershme në vendin që përdor shpërndarja juaj, qoftë njësi systemd-networkd, profil NetworkManager apo skript në drejtorinë up të klientit. Rregullimi i tabelës së gjallë me ip route del mbahet vetëm deri në lidhjen tjetër. Trajtojeni atë fshirje si provë e hipotezës dhe jo si rregullimi.

Kur skaji i largët ofron mbulim të gabuar, ngrijeni çështjen te operatori në vend që të filtroni gjithçka. Hedhja e të gjitha cilësimeve të shtyra hedh edhe DNS-in dhe politikën e tunelit të ndarë nga të cilat varet profili.

Hapi 5: konfirmoni rrugën e kthimit përpara se të fajësoni klientin

Për një lidhje faqe-me-faqe ose një nënrrjet pas tunelit, ana e largët ka nevojë për një rrugë kthimi drejt adresës së klientit tuaj dhe për përcjellje të aktivizuar në portë. Një rrugë njëdrejtimëshe duket saktësisht si një defekt rrugëtimi i klientit, përveç se shtrëngimi i duarve dhe paketa dalëse të dyja kanë sukses.

Filtrimi i rrugës së kthimit shton një kurth të dytë në portat Linux. Një përgjigje që mbërrin në një ndërfaqe të ndryshme nga ajo që parashikon rruga hidhet në modalitetin e rreptë, dhe rrugët asimetrike përmes dy ofruesve e shkaktojnë atë me besueshmëri. Numëruesit e hedhjes në portë, jo në klient, ju thonë nëse filtrimmi është shkaku.

Hapi 6: provoni burimin, jo pingun

Pasi rruga e zgjedhur të jetë e saktë, hapni burimin e vërtetë dhe konfirmoni trafikun e kthimit. Një përgjigje ping provon rrugën në një drejtim dhe asgjë për shërbimin, dhe një shërbim që përgjigjet në një lidhje të ruajtur në cache provon edhe më pak.

Pastaj përsëritni të gjithë kontrollin pas një rilidhjeje. Vlera e sekuencës është se parashikon çfarë do të bëjë lidhja tjetër, prandaj edhe krahasimi edhe metrika i takojnë biletës.