VPN-rutemetrikken endra seg etter tilkopling: kva det tyder
Ein lågare metrikk avgjer berre uavgjort mellom like spesifikke ruter. Les policyregelen, prefikset og vertsruta til endepunktet før du endrar eit VPN-rutenummer.
Du koplar til VPN-en, køyrer route print, og standardruta ber no ein mykje lågare metrikk enn før. Den naturlege konklusjonen er at VPN-en tok standardruta fordi nummeret er mindre. Nokre gonger er det nøyaktig det som skjedde. Ofte er metrikken slett ikkje den avgjerande faktoren, og å endre han endrar ingenting fordi valet vart teke tidlegare, av prefikslengda eller av ein policyregel.
Symptomet er ekte: trafikk som før gjekk ut gjennom Wi-Fi-adapteret, går no ut gjennom tunnelen, eller omvendt. Metrikken er éin inngang til eit oppslag som går i fast rekkjefølgje, og den rekkjefølgja er det du må lese før du rører eit tal.
Kva talet faktisk konkurrerer med
Den første samanlikninga er spesifisitet, ikkje preferanse. Ei rute for 10.20.0.0/16 slår 10.0.0.0/8, og begge slår 0.0.0.0/0, kva metrikkane enn seier. Ein VPN som installerer ei standardrute med den lågaste metrikken på maskina, taper framleis mot kvar meir spesifikk rute som passar destinasjonen, inkludert vertsruta klienten installerer for sin eigen server.
Derfor kan ein lågare metrikk på ei standardrute ikkje tvinge eit direkte tilkopla subnett inn i tunnelen. Vil du ha det subnettet inne i VPN-en, legg til ei rute for prefikset eller vel tunneltabellen med ein policyregel. Metrikken er feil spak for den jobben.
| 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 vel tabellen før metrikken
På Linux rådspør kjernen først policydatabasen. ip rule listar opp reglane og tabellane dei vel, og ip route get 203.0.113.10 rapporterer tabellen, ruta og kjeldeadressa kjernen faktisk ville brukt for den destinasjonen. Ein metrikk inne i tabell 100 konkurrerer aldri med ei rute i hovudtabellen, fordi regelen valde tabellen før nokon metrikk vart samanlikna.
Derfor kan ei rute sjå rett ut i ip route show table all og likevel ikkje bere trafikk. Les regelen som passa, deretter tabellen han valde, og samanlikn så rutene inni han. Er feil tabell vald, hjelper inga metrikkendring i den andre tabellen.
Windows kombinerer to metrikkar
Windows har ingen policydatabase som standard, men det kombinerer ein rutemetrikk med ein grensesnittmetrikk, og den automatiske grensesnittmetrikken kan endre seg med lenkefart og adaptertilstand. Derfor kan same ruta oppføre seg annleis etter at ein dockestasjon eller ein virtuell adapter dukkar opp. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporterer den valde kjeldeadressa, neste hopp og grensesnittet, som er nærare den verkelege avgjerda enn den rå tabellen.
Les rute- og grensesnittverdiane saman. Å auke ein grensesnittmetrikk kan flytte trafikk utan at noka ruteoppføring endrar seg, og ein VPN-klient som eig rutene sine, installerer dei på nytt ved attiltkopling og kastar endringa di.
Hald tunnelendepunktet utanfor tunnelen
Kvar tunnel treng ein veg til sin eigen server som ikkje går gjennom tunnelen. Klientar installerer ei vertsrute for endepunktet via den fysiske gatewayen, og den ruta må halde fram med å vere meir spesifikk enn standardruta klienten legg til. Slett henne, eller lat tunnelen vinne oppslaget for den adressa, og dei innkapsla pakkane prøver å gå inn i tunnelen dei skal byggje. Tilkoplinga feilar eller går i løkke.
Sjekk den vertsruta før og etter kvar metrikkendring: ho skal peike på det fysiske neste hoppet og overleve ei attiltkopling. Om klienten eig henne, endre profilen eller den administrerte konfigurasjonen i staden for ein køyretidsverdi som blir overstyrt.
Sjekk begge adressefamiliane og app-konteksten
IPv4 og IPv6 er separate avgjerder med separate tabellar. Ein VPN kan bere IPv4 medan IPv6 held fram med å bruke den lokale rutaren, og ei metrikkendring i den eine familien seier ingenting om den andre. Sjekk begge, og sjekk deretter applikasjonskonteksten. Ein prosess bunden til eit grensesnitt, eit containernamnerom eller ein VPN per app kan sjå ein annan tabell enn skalet ditt.
Verifiser med verktøyet som rapporterer avgjerda for den verkelege destinasjonen, ikkje med heile tabelllista. Om den valde ruta er den designet føreset, stopp. Ein metrikk som ikkje er det minste talet på skjermen, er ikkje ein feil, og å tvinge han til å vere minst kan bryte vegen til endepunktet som tunnelen er avhengig av.