Hvorfor et enkelt subnet stadig omgår din VPN-standardrute

Du skifter VPN'en til fuld tunnel, det meste trafik adlyder, og så svarer én adresse direkte — en printer, en NAS, en jump host på 10.x. Den oplagte læsning er, at tunnelen lækker, så du sænker metrikken på standardruten, og intet ændrer sig. Det mislykkede forsøg er ledetråden: en standardrute er en reserve, ikke en dom. Ruteopslaget tager det længste matchende præfiks, før det overhovedet sammenligner metrikker, så en /24 bliver ved med at vinde over en /0, uanset hvilket tal du sætter på nogen af dem. Når den rækkefølge er klar, er lækagen normalt en rute, nogen har installeret med vilje, eller et præfiks, klienten aldrig havde tænkt sig at dække.

Hvad en standardrute egentlig lover

0.0.0.0/0 matcher enhver IPv4-destination med nul bits specificitet. Den findes, så en vært kan nå alt, hvad dens tabel ikke beskriver bedre. En rute til 192.168.1.0/24 bærer 24 matchende bits, så for 192.168.1.40 vinder den, før nogen sammenligner metrikker, administrativ afstand eller hvad klienten nu kalder sit prioritetsfelt. Samme regel gælder i Linux FIB, Windows' rutetabel og BSD-stakken bag macOS.

På et normalt LAN er den adfærd en funktion. Det lokale subnet er direkte tilsluttet, printeren bliver ved med at virke, mens tunnelen bærer din browsing, og intet er forkert konfigureret. Spørgsmålet, der er værd at stille, er ikke, hvorfor den ene adresse går direkte, men hvilket præfiks i hvilken tabel der matcher den, og hvem der satte det der.

Halve standardruter, eller hvorfor standardposten kan se urørt ud

Det reneste eksempel er redirect-gateway def1 i OpenVPN. I stedet for at slette din standardrute og erstatte den tilføjer den 0.0.0.0/1 og 128.0.0.0/1. Sammen dækker parret hele IPv4, hvert præfiks er længere end /0, og begge slår routerens standardrute, mens den bliver liggende. Kør en ruteliste bagefter, og den oprindelige standardrute er stadig der, peger stadig på din gateway; den bliver blot aldrig valgt til internetdestinationer.

WireGuards wg-quick opnår det samme gennem politikbaseret routing. Når AllowedIPs dækker 0.0.0.0/0, opretter den sin egen tabel, sender markerede pakker derhen og tilføjer en regel, der ignorerer hovedtabellens præfiks med længde nul. Hovedtabellen beholder sin standardpost, og reglerne afgør, at tunneltabellen konsulteres først for den trafik, som interfacet ejer.

Begge design kræver præcis én rute uden for tunnelen: en værtsrute til VPN-serverens egen adresse gennem den oprindelige gateway. Uden den ville klienten forsøge at bære de pakker, der bygger tunnelen, inde i tunnelen, og forbindelsen bliver aldrig fuldført. En rute, der ikke er en tunnelrute, er derfor normal i din tabel, selv på en streng fuld-tunnel-profil. De ruter, der er værd at sætte spørgsmålstegn ved, er dem, der dækker destinationer, du faktisk bekymrer dig om.

Metrikker afgør uafgjorte kampe, præfikser afgør vindere

Metrikker sammenlignes kun blandt kandidater, der matcher destinationen lige godt. På Linux ip route get 10.20.5.9 udskriver vinderen sammen med sin tabel, og ip route show table all viser kandidaterne, inklusive eventuelle halve standardruter og enhver tabel, en regel peger på. På Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 returnerer den valgte rute og kildeadressen, mens Get-NetRoute viser den rå tabel — men den effektive pris er rutemetrik plus interfacmetrik, så en langsom adapter kan tabe en uafgjort kamp, som den ser ud til at vinde.

Tre tilfælde dækker det meste af det, du vil se:

• Samme destination, /24 mod /0: /24 vinder på præfikslængde, uanset hvad metrikkerne siger.
• Samme destination, to /24 med forskellige metrikker: den lavere effektive metrik vinder.
• Samme destination, to tabeller, én valgt af en politikregel: reglen vælger tabellen først, og præfikset sammenlignes inde i den.

Det tredje tilfælde er, hvor de fleste af disse rapporter ender. En ip rule i Linux eller et Windows VPN-trafikfilter kan sende trafik til en tabel, der aldrig har holdt tunnels standardrute, og hovedtabellen ser perfekt ud hele tiden.

Hvem ejer normalt omgåelsen

Start med profilen, ikke tabellen. Split-tunnel-konfigurationer og VPN-indstillinger pr. app efterlader med vilje navngivne præfikser uden for tunnelen; en arbejdsprofil, der beskytter ét privat subnet og lader almindelig browsing gå direkte, opfører sig som designet, og at tilsidesætte den bryder den politik, den blev bygget til at håndhæve. Microsofts vejledning i VPN-routing drager samme grænse mellem tvungen tunnel-trafik og udtrykkelige undtagelser, hvilket gør den til et nyttigt krydstjek, før du redigerer noget.

Se derefter efter rester. En rute, der peger på et interface, som ikke findes længere, eller på en adresse fra det forrige netværk, dukker op, efter at dockstationer, USB-adaptere og containerbroer kommer og går. At slette den én gang er ikke slutningen: NetworkManager-forbindelsesprofiler, netplan-filer og Windows' vedvarende ruter geninstallerer den ved næste forbindelse eller opstart, så find den fil eller profil, der ejer den, før du redigerer noget.

Tjek derefter IPv6 for sig selv. ip -6 route og Get-NetRoute -AddressFamily IPv6 holder separat tilstand, separate standardruter og separat klientadfærd. En revision, der kun ser på IPv4, siger intet om en dual-stack-vært, der stille foretrækker en indfødt IPv6-sti, og alene det kan få en klient til at se split-tunnel ud.

Bekræft med applikationens eget flow

Notér den destination, applikationen faktisk bruger, og spørg derefter systemet om den sti, den ville tage fra den kildeadresse, som applikationen binder sig til. ip route get 10.20.5.9 from 192.168.1.40 svarer på det på Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus den lokale adresse gør det på Windows. Sammenlign resultatet med det, profilen hævder. En browsers offentlige IP-side tester én destination på én protokol og siger intet om den private adresse, der startede klagen.

Ret det smalleste objekt, der forklarer forskellen. Hvis undtagelsen er godkendt, så skriv præfikset ned og lad det være; hvis ikke, fjern ruten eller tilføj en udtrykkelig smallere rute gennem tunnelen i stedet for at sænke standardrutens metrik. At sænke en metrik kan ikke overgå et længere præfiks, og at redigere standardruten, mens to /1-ruter ejer internetstien, ændrer heller intet.

Genopret derefter tunnelen, og gentag den samme forespørgsel. Klienter geninstallerer ruter ved hver forbindelse, så en ændring, der kun holder til næste håndtryk, er ikke testet. Hvis stien stadig afviger, er de resterende mistænkte en politikregel, en anden tabel eller et filter på klientsiden — ikke standardruten.

• Navngiv destinationen og den kildeadresse, appen faktisk bruger.
• Udskriv den vindende rute med ip route get eller Find-NetRoute.
• Tjek, om et /1-par eller en politikstabel ejer internetstien.
• List hvert præfiks, der er længere end /0, og som matcher destinationen.
• Gentag IPv6-tjekket separat.
• Spor den overlevende rute tilbage til den fil, profil eller det filter, der installerer den.
• Genopret forbindelsen, og kør forespørgslen igen, før du kalder det løst.

Hvis alle syv er enige med profilen, gør tunnelen præcis det, den blev konfigureret til, og rettelsen hører i profilen snarere end i en metrik.