Metrika e rrugës VPN ndryshoi pas lidhjes: çfarë do të thotë
Një metrikë më e ulët vetëm zgjidh barazimin mes rrugëve njësoj specifike. Lexoni rregullin e politikës, prefiksin dhe rrugën host të pikës fundore përpara se të ndryshoni çdo numër të rrugës VPN.
Ju lidheni VPN-në, ekzekutoni route print dhe rruga e parazgjedhur tani mbart një metrikë shumë më të ulët se më parë. Përfundimi i natyrshëm është se VPN-ja mori rrugën e parazgjedhur sepse numri i saj është më i vogël. Ndonjëherë ndodhi pikërisht kjo. Shpesh metrika nuk është fare faktor vendimtar, dhe ndryshimi i saj nuk ndryshon asgjë, sepse zgjedhja u bë më herët, nga gjatësia e prefiksit ose nga një rregull politike.
Simptoma është reale: trafiku që më parë dilte përmes përshtatësit Wi-Fi tani del përmes tunelit, ose anasjelltas. Metrika është një hyrje e një kërkimi që zhvillohet në një rend fiks, dhe pikërisht ai rend duhet lexuar përpara se të prekni një numër.
Me çfarë konkurron në të vërtetë numri
Krahasimi i parë është specifikësia, jo preferenca. Një rrugë për 10.20.0.0/16 mund 10.0.0.0/8, dhe të dyja mundin 0.0.0.0/0, çfarëdo që thonë metrikat e tyre. Një VPN që instalon një rrugë të parazgjedhur me metrikën më të ulët në makinë përsëri humbet ndaj çdo rruge më specifike që përputhet me destinacionin, duke përfshirë rrugën host që klienti instalon për serverin e vet.
Kjo është arsyeja pse ulja e metrikës në një rrugë të parazgjedhur nuk mund të detyrojë një nënrrjet të lidhur drejtpërdrejt të hyjë në tunel. Nëse e doni atë nënrrjet brenda VPN-së, shtoni një rrugë për prefiksin ose zgjidhni tabelën e tunelit me një rregull politike. Metrika është levë e gabuar për atë punë.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux vendos tabelën përpara metrikës
Në Linux kerneli konsulton fillimisht bazën e politikave. ip rule liston rregullat dhe tabelat që ato zgjedhin, dhe ip route get 203.0.113.10 raporton tabelën, rrugën dhe adresën burimore që kerneli do të përdorte vërtet për atë destinacion. Një metrikë brenda tabelës 100 nuk konkurron kurrë me një rrugë në tabelën kryesore, sepse rregulli zgjodhi tabelën përpara se të krahasohej çdo metrikë.
Kjo është arsyeja pse një rrugë mund të duket e saktë në ip route show table all dhe përsëri të mos mbajë trafik. Lexoni rregullin që përputhet, pastaj tabelën që zgjodhi, pastaj krahasoni rrugët brenda saj. Nëse zgjidhet tabela e gabuar, asnjë ndryshim metrike në tabelën tjetër nuk do të ndihmojë.
Windows kombinon dy metrika
Windows nuk ka bazë politikash si parazgjedhje, por kombinon një metrikë rruge me një metrikë ndërfaqeje, dhe metrika automatike e ndërfaqes mund të ndryshojë me shpejtësinë e lidhjes dhe gjendjen e përshtatësit. Kjo është arsyeja pse e njëjta rrugë mund të sillet ndryshe pasi shfaqet një stacion dokimi ose një përshtatës virtual. Find-NetRoute -RemoteIPAddress 203.0.113.10 raporton adresën burimore, hopin tjetër dhe ndërfaqen e zgjedhur, çka është më afër vendimit real se tabela e papërpunuar.
Lexoni së bashku vlerat e rrugës dhe të ndërfaqes. Rritja e metrikës së një ndërfaqeje mund të zhvendosë trafikun pa u ndryshuar asnjë zë rruge, dhe një klient VPN që zotëron rrugët e veta do t'i riinstalojë ato në rilidhje dhe do të hedhë poshtë ndryshimin tuaj.
Mbani pikën fundore të tunelit jashtë tunelit
Çdo tunel ka nevojë për një rrugë drejt serverit të vet që nuk kalon nëpër tunel. Klientët instalojnë një rrugë host për pikën fundore përmes portës fizike, dhe ajo rrugë duhet të mbetet më specifike se rruga e parazgjedhur që shton klienti. Fshijeni, ose lëreni tunelin të fitojë kërkimin për atë adresë, dhe paketat e enkapsuluara do të përpiqen të hyjnë në tunelin që supozohet të ndërtojnë. Lidhja dështon ose hyn në lak.
Kontrolloni atë rrugë host përpara dhe pas çdo ndryshimi metrike: duhet të tregojë hopin tjetër fizik dhe të mbijetojë një rilidhje. Nëse klienti e zotëron, ndryshoni profilin ose konfigurimin e menaxhuar në vend të një vlere kohë ekzekutimi që do të mbishkruhet.
Kontrolloni të dyja familjet e adresave dhe kontekstin e aplikacionit
IPv4 dhe IPv6 janë vendime të veçanta me tabela të veçanta. VPN-ja mund të mbajë IPv4 ndërsa IPv6 vazhdon të përdorë ruterin lokal, dhe një ndryshim metrike në një familje nuk thotë asgjë për tjetrën. Kontrolloni të dyja, pastaj kontrolloni kontekstin e aplikacionit. Një proces i lidhur me një ndërfaqe, një hapësirë emrash kontejneri ose një VPN për çdo aplikacion mund të shohë një tabelë tjetër nga shell-i juaj.
Verifikoni me mjetin që raporton vendimin për destinacionin real, jo me listën e plotë të tabelës. Nëse rruga e zgjedhur është ajo që synon dizajni, ndaloni. Një metrikë që nuk është numri më i vogël në ekran nuk është defekt, dhe detyrimi i saj të jetë më i vogli mund të thyejë rrugën e pikës fundore nga e cila varet tuneli.