VPN-rutemetricen ændrede sig efter forbindelse: hvad det betyder
En lavere metric afgør kun uafgjort mellem lige specifikke ruter. Læs politikreglen, præfikset og slutpunktets værtsrute, før du redigerer et VPN-rutenummer.
Du forbinder VPN'en, kører route print, og standardruten bærer nu en meget lavere metric end før. Den naturlige konklusion er, at VPN'en tog standardruten, fordi dens tal er mindre. Nogle gange er det præcis, hvad der skete. Ofte er metricen slet ikke den afgørende faktor, og at redigere den ændrer intet, fordi valget blev truffet tidligere, af præfikslængden eller af en politikregel.
Symtomet er ægte: trafik, der før forlod gennem Wi-Fi-adapteren, forlader nu gennem tunnelen, eller omvendt. Metricen er ét input til et opslag, der kører i en fast rækkefølge, og den rækkefølge er det, du skal læse, før du rører et tal.
Hvad tallet faktisk konkurrerer med
Den første sammenligning er specificitet, ikke præference. En rute til 10.20.0.0/16 slår 10.0.0.0/8, og begge slår 0.0.0.0/0, uanset hvad deres metricer siger. En VPN, der installerer en standardrute med den laveste metric på maskinen, taber stadig til enhver mere specifik rute, der matcher destinationen, inklusive den værtsrute, klienten installerer til sin egen server.
Derfor kan en lavere metric på en standardrute ikke tvinge et direkte tilsluttet undernet ind i tunnelen. Hvis du vil have det undernet ind i VPN'en, skal du tilføje en rute for præfikset eller vælge tunellens tabel med en politikregel. Metricen er det forkerte håndtag til det arbejde.
| 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 vælger tabellen før metricen
På Linux rådfører kernen sig først med politikdatabasen. ip rule viser reglerne og de tabeller, de vælger, og ip route get 203.0.113.10 rapporterer den tabel, rute og kildeadresse, som kernen faktisk ville bruge til den destination. En metric inde i tabel 100 konkurrerer aldrig med en rute i hovedtabellen, fordi reglen valgte tabellen, før nogen metric blev sammenlignet.
Derfor kan en rute se rigtig ud i ip route show table all og stadig ikke bære trafik. Læs den regel, der matchede, læs derefter den tabel, den valgte, og sammenlign derefter ruterne indeni. Hvis den forkerte tabel er valgt, hjælper ingen metrikredigering i den anden tabel.
Windows kombinerer to metricer
Windows har ingen politikdatabase som standard, men det kombinerer en rutemetric med en interfacemetric, og den automatiske interfacemetric kan ændre sig med linkhastighed og adaptertilstand. Derfor kan den samme rute opføre sig anderledes, efter at en dockstation eller en virtuel adapter dukker op. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporterer den valgte kildeadresse, næste hop og interface, hvilket er tættere på den reelle beslutning end den rå tabel.
Læs rute- og interfaceværdierne sammen. At hæve en interfacemetric kan flytte trafik, uden at nogen ruteindgang ændres, og en VPN-klient, der ejer sine ruter, geninstallerer dem ved genopkobling og kasserer din redigering.
Hold tunnelens slutpunkt uden for tunnelen
Enhver tunnel har brug for en vej til sin egen server, som ikke går gennem tunnelen. Klienter installerer en værtsrute til slutpunktet gennem den fysiske gateway, og den rute skal forblive mere specifik end den standardrute, klienten tilføjer. Slet den, eller lad tunnelen vinde opslaget for den adresse, og de indkapslede pakker forsøger at gå ind i den tunnel, de skulle bygge. Forbindelsen fejler eller går i loop.
Kontrollér den værtsrute før og efter enhver metrikændring: den skal pege på det fysiske næste hop og overleve en genopkobling. Hvis klienten ejer den, skal du ændre profilen eller den administrerede konfiguration i stedet for en runtimeværdi, der bliver overskrevet.
Kontrollér begge adressefamilier og app-konteksten
IPv4 og IPv6 er separate beslutninger med separate tabeller. En VPN kan bære IPv4, mens IPv6 fortsætter med at bruge den lokale router, og en metrikændring i den ene familie siger intet om den anden. Kontrollér begge, og kontrollér derefter applikationskonteksten. En proces bundet til et interface, et containernamespace eller en VPN pr. app kan se en anden tabel end dit shell.
Verificér med det værktøj, der rapporterer beslutningen for den rigtige destination, ikke med den fulde tabeludskrift. Hvis den valgte rute er den, designet tilsigter, så stop. En metric, der ikke er det mindste tal på skærmen, er ikke en fejl, og at tvinge den til at være mindst kan bryde slutpunktets vej, som tunnelen afhænger af.