VPN-rutens metrik ändrades efter anslutning: vad det betyder
En lägre metrik avgör bara oavgjort mellan lika specifika rutter. Läs policyregeln, prefixet och slutpunktens värdrutt innan du ändrar något VPN-rutnummer.
Du ansluter VPN:en, kör route print och standardrutten bär nu en mycket lägre metrik än tidigare. Den naturliga slutsatsen är att VPN:en tog standardrutten eftersom dess nummer är mindre. Ibland är det precis vad som hände. Ofta är metriken inte alls den avgörande faktorn, och att ändra den ändrar ingenting eftersom valet gjordes tidigare, av prefixlängden eller av en policyregel.
Symtomet är verkligt: trafik som tidigare gick ut via Wi-Fi-adaptern går nu ut via tunneln, eller tvärtom. Metriken är en ingång till ett uppslag som körs i fast ordning, och den ordningen är det du måste läsa innan du rör ett tal.
Vad talet faktiskt konkurrerar med
Den första jämförelsen är specificitet, inte preferens. En rutt för 10.20.0.0/16 slår 10.0.0.0/8, och båda slår 0.0.0.0/0, vad deras metriker än säger. En VPN som installerar en standardrutt med den lägsta metriken på maskinen förlorar ändå mot varje mer specifik rutt som matchar destinationen, inklusive den värdrutt som klienten installerar för sin egen server.
Därför kan en lägre metrik på en standardrutt inte tvinga ett direkt anslutet subnät in i tunneln. Vill du ha det subnätet inne i VPN:en lägger du till en rutt för prefixet eller väljer tunneltabellen med en policyregel. Metriken är fel spak för det jobbet.
| 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äljer tabellen före metriken
På Linux rådgör kärnan först med policydatabasen. ip rule listar reglerna och tabellerna de väljer, och ip route get 203.0.113.10 rapporterar tabellen, rutten och källadressen som kärnan faktiskt skulle använda för den destinationen. En metrik inne i tabell 100 konkurrerar aldrig med en rutt i huvudtabellen, eftersom regeln valde tabellen innan någon metrik jämfördes.
Därför kan en rutt se rätt ut i ip route show table all och ändå inte bära trafik. Läs regeln som matchade, sedan tabellen den valde, och jämför sedan rutterna inuti den. Om fel tabell valdes hjälper ingen metrikändring i den andra tabellen.
Windows kombinerar två metriker
Windows har ingen policydatabas som standard, men det kombinerar en ruttmetrik med en gränssnittsmetrik, och den automatiska gränssnittsmetriken kan ändras med länkhastighet och adapterstatus. Därför kan samma rutt bete sig annorlunda efter att en dockningsstation eller en virtuell adapter dyker upp. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporterar den valda källadressen, nästa hopp och gränssnittet, vilket är närmare det verkliga beslutet än den råa tabellen.
Läs rutt- och gränssnittsvärdena tillsammans. Att höja en gränssnittsmetrik kan flytta trafik utan att någon ruttpost ändras, och en VPN-klient som äger sina rutter installerar om dem vid återanslutning och kastar din ändring.
Håll tunnelns slutpunkt utanför tunneln
Varje tunnel behöver en väg till sin egen server som inte går genom tunneln. Klienter installerar en värdrutt för slutpunkten via den fysiska gatewayn, och den rutten måste förbli mer specifik än standardrutten klienten lägger till. Ta bort den, eller låt tunneln vinna uppslaget för den adressen, och de inkapslade paketen försöker gå in i tunneln de ska bygga. Anslutningen misslyckas eller går i loop.
Kontrollera den värdrutten före och efter varje metrikändring: den ska peka på nästa fysiska hopp och överleva en återanslutning. Om klienten äger den, ändra profilen eller den hanterade konfigurationen i stället för ett körtidsvärde som skrivs över.
Kontrollera båda adressfamiljerna och appkontexten
IPv4 och IPv6 är separata beslut med separata tabeller. En VPN kan bära IPv4 medan IPv6 fortsätter använda den lokala routern, och en metrikändring i den ena familjen säger ingenting om den andra. Kontrollera båda och kontrollera sedan applikationskontexten. En process bunden till ett gränssnitt, ett containernamnrymd eller en VPN per app kan se en annan tabell än ditt skal.
Verifiera med verktyget som rapporterar beslutet för den verkliga destinationen, inte med hela tabellistan. Om den valda rutten är den designen avser, stanna. En metrik som inte är det minsta talet på skärmen är inte ett fel, och att tvinga den att vara minst kan bryta slutpunktens väg som tunneln är beroende av.