VPN-rutemetrikken endret seg etter tilkobling: hva det betyr
En lavere metrikk avgjør bare uavgjort mellom like spesifikke ruter. Les policyregelen, prefikset og vertsruten til endepunktet før du redigerer et VPN-rutenummer.
Du kobler til VPN-en, kjører route print, og standardruten bærer nå en mye lavere metrikk enn før. Den naturlige konklusjonen er at VPN-en tok standardruten fordi nummeret er mindre. Noen ganger er det nøyaktig det som skjedde. Ofte er metrikken ikke den avgjørende faktoren i det hele tatt, og å endre den endrer ingenting fordi valget ble tatt tidligere, av prefikslengden eller av en policyregel.
Symptomet er ekte: trafikk som før gikk ut gjennom Wi-Fi-adapteret, går nå ut gjennom tunnelen, eller omvendt. Metrikken er én inngang til et oppslag som kjøres i en fast rekkefølge, og den rekkefølgen er det du må lese før du rører et tall.
Hva tallet faktisk konkurrerer med
Den første sammenligningen er spesifisitet, ikke preferanse. En rute for 10.20.0.0/16 slår 10.0.0.0/8, og begge slår 0.0.0.0/0, uansett hva metrikkene sier. En VPN som installerer en standardrute med den laveste metrikken på maskinen, taper fortsatt mot enhver mer spesifikk rute som passer destinasjonen, inkludert vertsruten klienten installerer for sin egen server.
Derfor kan en lavere metrikk på en standardrute ikke tvinge et direkte tilkoblet subnett inn i tunnelen. Hvis du vil ha det subnettet inne i VPN-en, legg til en rute for prefikset eller velg tunneltabellen med en 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 velger tabellen før metrikken
På Linux rådfører kjernen seg først med policydatabasen. ip rule lister opp reglene og tabellene de velger, og ip route get 203.0.113.10 rapporterer tabellen, ruten og kildeadressen kjernen faktisk ville brukt for den destinasjonen. En metrikk inne i tabell 100 konkurrerer aldri med en rute i hovedtabellen, fordi regelen valgte tabellen før noen metrikk ble sammenlignet.
Derfor kan en rute se riktig ut i ip route show table all og fortsatt ikke bære trafikk. Les regelen som passet, deretter tabellen den valgte, og sammenlign så rutene inni den. Hvis feil tabell er valgt, hjelper ingen metrikkendring i den andre tabellen.
Windows kombinerer to metrikker
Windows har ingen policydatabase som standard, men det kombinerer en rutemetrikk med en grensesnittmetrikk, og den automatiske grensesnittmetrikken kan endre seg med lenkehastighet og adaptertilstand. Derfor kan samme rute oppføre seg annerledes etter at en dockestasjon eller en virtuell adapter dukker opp. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporterer den valgte kildeadressen, neste hopp og grensesnittet, som er nærmere den virkelige beslutningen enn den rå tabellen.
Les rute- og grensesnittverdiene sammen. Å øke en grensesnittmetrikk kan flytte trafikk uten at noen ruteoppføring endres, og en VPN-klient som eier rutene sine, installerer dem på nytt ved gjentilkobling og forkaster endringen din.
Hold tunnelendepunktet utenfor tunnelen
Hver tunnel trenger en vei til sin egen server som ikke går gjennom tunnelen. Klienter installerer en vertsrute for endepunktet via den fysiske gatewayen, og den ruten må forbli mer spesifikk enn standardruten klienten legger til. Slett den, eller la tunnelen vinne oppslaget for den adressen, og de innkapslede pakkene prøver å gå inn i tunnelen de skal bygge. Tilkoblingen feiler eller går i løkke.
Sjekk den vertsruten før og etter enhver metrikkendring: den skal peke på det fysiske neste hoppet og overleve en gjentilkobling. Hvis klienten eier den, endre profilen eller den administrerte konfigurasjonen i stedet for en kjøretidsverdi som blir overskrevet.
Sjekk begge adressefamiliene og app-konteksten
IPv4 og IPv6 er separate beslutninger med separate tabeller. En VPN kan bære IPv4 mens IPv6 fortsetter å bruke den lokale ruteren, og en metrikkendring i den ene familien sier ingenting om den andre. Sjekk begge, og sjekk deretter applikasjonskonteksten. En prosess bundet til et grensesnitt, et containernavnerom eller en VPN per app kan se en annen tabell enn skallet ditt.
Verifiser med verktøyet som rapporterer beslutningen for den virkelige destinasjonen, ikke med hele tabelllisten. Hvis den valgte ruten er den designet forutsetter, stopp. En metrikk som ikke er det minste tallet på skjermen, er ikke en feil, og å tvinge den til å være minst kan bryte endepunktets vei som tunnelen er avhengig av.