VPN-itinera metriko ŝanĝiĝis post konekto: kion tio signifas
Pli malalta metriko nur decidas egalpezon inter egale specifaj itineroj. Legu la politikan regulon, la prefikson kaj la gastigan itineron de la finpunkto antaŭ ol vi redaktos iun ajn VPN-itinernumeron.
Vi konektas la VPN-on, rulas route print, kaj la implicita itinero nun portas multe pli malaltan metrikon ol antaŭe. La natura konkludo estas, ke la VPN prenis la implicitan itineron ĉar ĝia numero estas pli malgranda. Foje ĝuste tio okazis. Ofte la metriko tute ne estas la decida faktoro, kaj redakti ĝin ŝanĝas nenion, ĉar la elekto estis farita pli frue, per la prefiksa longo aŭ per politika regulo.
La simptomo estas reala: trafiko, kiu antaŭe eliris tra la Wi-Fi-adaptilo, nun eliras tra la tunelo, aŭ male. La metriko estas unu enigo al serĉo, kiu ruliĝas en fiksa ordo, kaj ĝuste tiun ordon vi devas legi antaŭ ol tuŝi numeron.
Kun kio la numero efektive konkuras
La unua komparo estas specifeco, ne prefero. Itinero por 10.20.0.0/16 venkas 10.0.0.0/8, kaj ambaŭ venkas 0.0.0.0/0, kion ajn diras iliaj metrikoj. VPN, kiu instalas implicitan itineron kun la plej malalta metriko en la maŝino, ankoraŭ malvenkas al ĉiu pli specifa itinero, kiu kongruas kun la celo, inkluzive de la gastiga itinero, kiun la kliento instalas por sia propra servilo.
Tial malaltigi la metrikon de implicita itinero ne povas devigi rekte konektitan subreton en la tunelon. Se vi volas tiun subreton ene de la VPN, aldonu itineron por la prefikso aŭ elektu la tunelan tabelon per politika regulo. La metriko estas la malĝusta levilo por tiu tasko.
| 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 decidas la tabelon antaŭ la metriko
En Linux la kerno unue konsultas la politikan datumbazon. ip rule listigas la regulojn kaj la tabelojn, kiujn ili elektas, kaj ip route get 203.0.113.10 raportas la tabelon, itineron kaj fontan adreson, kiujn la kerno efektive uzus por tiu celo. Metriko ene de tabelo 100 neniam konkuras kun itinero en la ĉefa tabelo, ĉar la regulo elektis la tabelon antaŭ ol iu ajn metriko estis komparita.
Tial itinero povas aspekti ĝusta en ip route show table all kaj tamen ne porti trafikon. Legu la regulon, kiu kongruis, poste la tabelon, kiun ĝi elektis, poste komparu la itinerojn ene de ĝi. Se la malĝusta tabelo estas elektita, neniu metrika redakto en la alia tabelo helpos.
Windows kunigas du metrikojn
Windows ne havas politikan datumbazon defaŭlte, sed ĝi kunigas itineran metrikon kun interfaca metriko, kaj la aŭtomata interfaca metriko povas ŝanĝiĝi kun ligila rapido kaj adaptila stato. Tial la sama itinero povas konduti alie post kiam docking-stacio aŭ virtuala adaptilo aperas. Find-NetRoute -RemoteIPAddress 203.0.113.10 raportas la elektitan fontan adreson, la sekvan salteton kaj la interfacon, kio estas pli proksima al la reala decido ol la kruda tabelo.
Legu la itinerajn kaj interfacajn valorojn kune. Altigi interfacan metrikon povas movi trafikon sen ke iu ajn itinera ero ŝanĝiĝu, kaj VPN-kliento, kiu posedas siajn itinerojn, reinstalos ilin ĉe rekonekto kaj forĵetos vian redakton.
Tenu la tunelan finpunkton ekster la tunelo
Ĉiu tunelo bezonas vojon al sia propra servilo, kiu ne iras tra la tunelo. Klientoj instalas gastigan itineron por la finpunkto tra la fizika enirejo, kaj tiu itinero devas resti pli specifa ol la implicita, kiun la kliento aldonas. Forigu ĝin, aŭ lasu la tunelon venki la serĉon por tiu adreso, kaj la enkapsuligitaj pakaĵoj provos eniri la tunelon, kiun ili devus konstrui. La konekto malsukcesas aŭ eniras buklon.
Kontrolu tiun gastigan itineron antaŭ kaj post iu ajn metrika ŝanĝo: ĝi devus montri al la fizika sekva salteto kaj postvivi rekonekton. Se la kliento posedas ĝin, ŝanĝu la profilon aŭ la administritan agordon anstataŭ rultempan valoron, kiu estos anstataŭigita.
Kontrolu ambaŭ adresajn familiojn kaj la ap-kuntekston
IPv4 kaj IPv6 estas apartaj decidoj kun apartaj tabeloj. VPN povas porti IPv4 dum IPv6 daŭre uzas la lokan enkursigilon, kaj metrika ŝanĝo en unu familio diras nenion pri la alia. Kontrolu ambaŭ, poste kontrolu la aplikaĵan kuntekston. Procezo ligita al interfaco, ujuja nomspaco aŭ VPN po apo povas vidi alian tabelon ol via ŝelo.
Kontrolu per la ilo, kiu raportas la decidon por la reala celo, ne per la plena tabela listo. Se la elektita itinero estas tiu, kiun la dezajno intencas, haltu. Metriko, kiu ne estas la plej malgranda numero sur la ekrano, ne estas difekto, kaj devigi ĝin esti la plej malgranda povas rompi la finpunkan vojon, de kiu la tunelo dependas.