Pse një nënrrjet vazhdon t'ia kalojë rrugës së parazgjedhur të VPN-së

Ju e ndërroni VPN-në në tunel të plotë, pjesa më e madhe e trafikut bindet, dhe pastaj një adresë përgjigjet drejtpërdrejt — një printer, një NAS, një host kërcimi në 10.x. Leximi i dukshëm është se tuneli po rrjedh, kështu që ju ulni metrikën e rrugës së parazgjedhur dhe asgjë nuk ndryshon. Ai përpjekje i dështuar është të dhëna: një rrugë e parazgjedhur është një rezervë, jo një verdikt. Kërkimi i rrugës merr prefiksin më të gjatë përputhës përpara se të krahasojë ndonjëherë metrikat, kështu që një /24 vazhdon të fitojë ndaj një /0, pavarësisht se çfarë numri i bashkëngjitni secilës. Pasi ky rend të jetë i qartë, rrjedhja zakonisht është një rrugë që dikush e ka instaluar me qëllim, ose një prefiks që klienti nuk kishte ndërmend ta mbulonte.

Çfarë premton vërtet një rrugë e parazgjedhur

0.0.0.0/0 përputhet me çdo destinacion IPv4 me zero bit specifikë. Ekziston që një host të arrijë çdo gjë që tabela e tij nuk e përshkruan më mirë. Një rrugë drejt 192.168.1.0/24 mbart 24 bit përputhës, kështu që për 192.168.1.40 fiton përpara se dikush të krahasojë metrikat, distancën administrative ose si e quan klienti fushën e prioritetit. I njëjti rregull vlen në FIB-in e Linux, tabelën e rrugëzimit të Windows dhe stack-un BSD pas macOS.

Në një LAN normal, ajo sjellje është një veçori. Nënrrjeti lokal është i lidhur drejtpërdrejt, printeri vazhdon të punojë ndërsa tuneli mbart shfletimin tuaj, dhe asgjë nuk është konfiguruar gabim. Pyetja që ia vlen të bëhet nuk është pse ajo adresë shkon drejtpërdrejt, por cili prefiks në cilën tabelë përputhet me të, dhe kush e vendosi atje.

Gjysmë-parazgjedhjet, ose pse hyrja e parazgjedhur mund të duket e paprekur

Shembulli më i pastër është redirect-gateway def1 në OpenVPN. Në vend që të fshijë dhe zëvendësojë parazgjedhjen tuaj, ai shton 0.0.0.0/1 dhe 128.0.0.0/1. Së bashku çifti mbulon të gjithë IPv4, çdo prefiks është më i gjatë se /0, dhe të dy mundin parazgjedhjen e ruterit duke e lënë në vend. Ekzekutoni një listë rrugësh pas kësaj dhe rruga origjinale e parazgjedhur është ende aty, ende tregon drejt gateway-it tuaj; thjesht nuk zgjidhet kurrë për destinacionet e internetit.

wg-quick i WireGuard arrin të njëjtin rezultat përmes rrugëzimit të bazuar në politikë. Kur AllowedIPs mbulon 0.0.0.0/0, ai krijon tabelën e vet, dërgon atje paketat e shënuara dhe shton një rregull që injoron prefiksin me gjatësi zero të tabelës kryesore. Tabela kryesore mban hyrjen e saj të parazgjedhur, dhe rregullat vendosin që tabela e tunelit konsultohet e para për trafikun që zotëron ndërfaqja.

Të dy dizajnet kanë nevojë për saktësisht një rrugë jashtë tunelit: një rrugë hosti drejt adresës së vetë serverit VPN përmes gateway-it origjinal. Pa të, klienti do të përpiqej të mbante brenda tunelit paketat që ndërtojnë tunelin, dhe lidhja nuk do të përfundonte kurrë. Pra, një rrugë që nuk është tunel në tabelën tuaj është normale edhe në një profil të rreptë tuneli të plotë. Rrugët që meritojnë të vihen në dyshim janë ato që mbulojnë destinacione për të cilat ju interesoheni vërtet.

Metrikat vendosin barazimet, prefikset vendosin fituesit

Metrikat krahasohen vetëm midis kandidatëve që përputhen njësoj mirë me destinacionin. Në Linux ip route get 10.20.5.9 printon fituesin bashkë me tabelën e tij, dhe ip route show table all liston kandidatët, duke përfshirë çdo gjysmë-parazgjedhje dhe çdo tabelë që tregon një rregull. Në Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 kthen rrugën e zgjedhur dhe adresën burimore, ndërsa Get-NetRoute tregon tabelën e papërpunuar — por kostoja efektive është metrika e rrugës plus metrika e ndërfaqes, kështu që një përshtatës i ngadaltë mund të humbasë një barazim që duket se e fiton.

Tre raste mbulojnë pjesën më të madhe të asaj që do të shihni:

• I njëjti destinacion, /24 kundër /0: /24 fiton në gjatësinë e prefiksit, çfarëdo që thonë metrikat.
• I njëjti destinacion, dy /24 me metrika të ndryshme: fiton metrika efektive më e ulët.
• I njëjti destinacion, dy tabela, njëra e zgjedhur nga një rregull politike: rregulli zgjedh së pari tabelën, dhe krahasimi i prefikseve ndodh brenda saj.

Rasti i tretë është vendi ku përfundojnë shumica e këtyre raporteve. Një ip rule në Linux ose një filtër trafiku VPN i Windows mund ta dërgojë trafikun në një tabelë që nuk e mbajti kurrë parazgjedhjen e tunelit, dhe tabela kryesore duket e përsosur gjatë gjithë kohës.

Kush zakonisht e zotëron anashkalimin

Filloni me profilin, jo me tabelën. Konfigurimet split-tunnel dhe cilësimet VPN për aplikacion e lënë qëllimisht prefikset e emërtuara jashtë tunelit; një profil pune që mbron një nënrrjet privat dhe lë shfletimin e përgjithshëm të shkojë drejtpërdrejt sillet ashtu siç është projektuar, dhe tejkalimi i tij thyen politikën që duhej të zbatonte. Udhëzuesi i rrugëzimit VPN i Microsoft tërheq të njëjtën kufi midis trafikut të detyruar në tunel dhe përjashtimeve të qarta, gjë që e bën atë një kontroll të ndërsjellë të dobishëm përpara se të ndryshoni ndonjë gjë.

Më pas kërkoni mbetje. Një rrugë që tregon një ndërfaqe që nuk ekziston më, ose një adresë nga rrjeti i mëparshëm, shfaqet pasi stacionet e dokimit, përshtatësit USB dhe urat e kontejnerëve vijnë dhe ikin. Fshirja një herë nuk është fundi: profilet e lidhjes NetworkManager, skedarët netplan dhe rrugët e vazhdueshme të Windows e instalojnë sërish në lidhjen ose nisjen tjetër, ndaj gjeni skedarin ose profilin që e zotëron përpara se të ndryshoni ndonjë gjë.

Më pas kontrolloni IPv6 veçmas. ip -6 route dhe Get-NetRoute -AddressFamily IPv6 mbajnë gjendje të veçantë, parazgjedhje të veçanta dhe sjellje klienti të veçantë. Një auditim vetëm i IPv4 nuk thotë asgjë për një host me dy stack që preferon në heshtje një shteg nativ IPv6, dhe vetëm kjo mund ta bëjë një klient të duket si split-tunnel.

Konfirmoni me rrjedhën e vetë aplikacionit

Regjistroni destinacionin që aplikacioni përdor vërtet, pastaj pyesni sistemin për shtegun që do të merrte nga adresa burimore me të cilën lidhet ai aplikacion. ip route get 10.20.5.9 from 192.168.1.40 përgjigjet për këtë në Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus adresa lokale e bën këtë në Windows. Krahasoni rezultatin me atë që pretendon profili. Faqja e IP publike e një shfletuesi teston një destinacion në një protokoll dhe nuk thotë asgjë për adresën private që filloi ankesën.

Rregulloni objektin më të ngushtë që shpjegon ndryshimin. Nëse përjashtimi është miratuar, shkruani prefiksin dhe lëreni; nëse jo, hiqni rrugën ose shtoni një rrugë të qartë më të ngushtë përmes tunelit në vend që të ulni metrikën e parazgjedhur. Ulja e metrikës nuk mund të kalojë një prefiks më të gjatë, dhe redaktimi i parazgjedhjes ndërsa dy rrugë /1 zotërojnë shtegun e internetit gjithashtu nuk ndryshon asgjë.

Më pas rilidhni tunelin dhe përsëritni të njëjtën pyetje. Klientët i instalojnë sërish rrugët në çdo lidhje, kështu që një ndryshim që zgjat vetëm deri në shtrëngimin e duarve tjetër nuk është testuar. Nëse shtegu vazhdon të ndryshojë, të dyshuarit e mbetur janë një rregull politike, një tabelë e dytë ose një filtër në anën e klientit — jo rruga e parazgjedhur.

• Emërtoni destinacionin dhe adresën burimore që aplikacioni përdor vërtet.
• Printoni rrugën fituese me ip route get ose Find-NetRoute.
• Kontrolloni nëse një çift /1 apo një tabelë politike zotëron shtegun e internetit.
• Listoni çdo prefiks më të gjatë se /0 që përputhet me destinacionin.
• Përsëritni kontrollin e IPv6 veçmas.
• Gjurmoni rrugën e mbetur deri te skedari, profili ose filtri që e instalon.
• Rilidhuni dhe ekzekutoni përsëri pyetjen përpara se ta quani të rregulluar.

Nëse të shtatë pajtohen me profilin, tuneli bën pikërisht atë për të cilin është konfiguruar, dhe rregullimi i përket profilit, jo metrikës.