Hvorfor ett subnett fortsatt går utenom VPN-ens standardrute

Du bytter VPN-en til full tunnel, mesteparten av trafikken adlyder, og så svarer én adresse direkte — en skriver, en NAS, en hoppvert på 10.x. Den åpenbare lesningen er at tunnelen lekker, så du senker metrikken på standardruten og ingenting endres. Det mislykkede forsøket er ledetråden: en standardrute er en reserve, ikke en dom. Ruteoppslaget tar det lengste samsvarende prefikset før det i det hele tatt sammenligner metrikker, så en /24 fortsetter å vinne over en /0, uansett hvilket tall du fester til noen av dem. Når den rekkefølgen er klar, er lekkasjen vanligvis en rute noen har installert med vilje, eller et prefiks klienten aldri mente å dekke.

Hva en standardrute faktisk lover

0.0.0.0/0 samsvarer med hver IPv4-destinasjon med null biter spesifisitet. Den finnes for at en vert skal nå alt tabellen dens ikke beskriver bedre. En rute til 192.168.1.0/24 bærer 24 samsvarende biter, så for 192.168.1.40 vinner den før noen sammenligner metrikker, administrativ avstand eller hva klienten kaller prioritetsfeltet sitt. Samme regel gjelder i Linux FIB, Windows-rutetabellen og BSD-stakken bak macOS.

På et normalt LAN er den oppførselen en funksjon. Det lokale subnettet er direkte tilkoblet, skriveren fortsetter å virke mens tunnelen bærer nettlesingen din, og ingenting er feilkonfigurert. Spørsmålet det er verdt å stille er ikke hvorfor den ene adressen går direkte, men hvilket prefiks i hvilken tabell som samsvarer med den, og hvem som satte det der.

Halvstandardruter, eller hvorfor standardoppføringen kan se urørt ut

Det reneste eksempelet er redirect-gateway def1 i OpenVPN. I stedet for å slette standardruten din og erstatte den, legger den til 0.0.0.0/1 og 128.0.0.0/1. Sammen dekker paret hele IPv4, hvert prefiks er lengre enn /0, og begge slår ruteren sin standard samtidig som den blir liggende. Kjør en ruteliste etterpå, og den opprinnelige standardruten er fortsatt der, peker fortsatt på gatewayen din; den blir bare aldri valgt for internettdestinasjoner.

WireGuards wg-quick oppnår samme resultat gjennom policybasert ruting. Når AllowedIPs dekker 0.0.0.0/0, lager den sin egen tabell, sender merkede pakker dit og legger til en regel som ignorerer hovedtabellens prefiks med lengde null. Hovedtabellen beholder standardoppføringen, og reglene bestemmer at tunneltabellen konsulteres først for trafikken grensesnittet eier.

Begge designene trenger nøyaktig én rute utenfor tunnelen: en vertsrute til VPN-serverens egen adresse via den opprinnelige gatewayen. Uten den ville klienten prøve å bære pakkene som bygger tunnelen inne i tunnelen, og tilkoblingen blir aldri fullført. En rute som ikke er en tunnelrute i tabellen din er derfor normal selv på en streng fulltunnelprofil. Rutene det er verdt å stille spørsmål ved, er de som dekker destinasjoner du faktisk bryr deg om.

Metrikker avgjør uavgjort, prefikser avgjør vinnere

Metrikker sammenlignes bare blant kandidater som samsvarer like godt med destinasjonen. På Linux ip route get 10.20.5.9 skriver ut vinneren sammen med tabellen sin, og ip route show table all lister kandidatene, inkludert eventuelle halvstandardruter og enhver tabell en regel peker på. På Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 returnerer den valgte ruten og kildeadressen, mens Get-NetRoute viser den rå tabellen — men den effektive kostnaden er rutemetrikk pluss grensesnittmetrikk, så en treg adapter kan tape et uavgjort resultat den ser ut til å vinne.

Tre tilfeller dekker det meste av det du vil se:

• Samme destinasjon, /24 mot /0: /24 vinner på prefikslengde, uansett hva metrikkene sier.
• Samme destinasjon, to /24 med ulike metrikker: den laveste effektive metrikken vinner.
• Samme destinasjon, to tabeller, én valgt av en policyregel: regelen velger tabellen først, og prefikssammenligningen skjer inne i den.

Det tredje tilfellet er der de fleste av disse rapportene ender. En ip rule i Linux eller et Windows VPN-trafikkfilter kan sende trafikk til en tabell som aldri har holdt tunnelens standardrute, og hovedtabellen ser perfekt ut hele tiden.

Hvem som vanligvis eier omveien

Start med profilen, ikke tabellen. Split-tunnel-konfigurasjoner og VPN-innstillinger per app lar navngitte prefikser ligge utenfor tunnelen med vilje; en arbeidsprofil som beskytter ett privat subnett og lar vanlig nettlesing gå direkte, oppfører seg som designet, og å overstyre den bryter policyen den ble bygget for å håndheve. Microsofts veiledning for VPN-ruting trekker samme linje mellom tvunget tunneltrafikk og eksplisitte unntak, noe som gjør den til en nyttig kryssjekk før du redigerer noe.

Se deretter etter rester. En rute som peker på et grensesnitt som ikke finnes lenger, eller på en adresse fra forrige nettverk, dukker opp etter at dokkingstasjoner, USB-adaptere og containerbroer kommer og går. Å slette den én gang er ikke slutten: NetworkManager-tilkoblingsprofiler, netplan-filer og Windows' vedvarende ruter installerer den på nytt ved neste tilkobling eller oppstart, så finn filen eller profilen som eier den før du redigerer noe.

Sjekk deretter IPv6 for seg selv. ip -6 route og Get-NetRoute -AddressFamily IPv6 holder separat tilstand, separate standarder og separat klientatferd. En revisjon kun av IPv4 sier ingenting om en dual-stack-vert som stille foretrekker en innfødt IPv6-vei, og det alene kan få en klient til å se split-tunnel ut.

Bekreft med applikasjonens egen flyt

Noter destinasjonen applikasjonen faktisk bruker, og spør deretter systemet om veien den ville ta fra kildeadressen applikasjonen binder seg 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 pluss den lokale adressen gjør det på Windows. Sammenlign resultatet med det profilen hevder. En nettlesers offentlige IP-side tester én destinasjon på én protokoll og sier ingenting om den private adressen som startet klagen.

Fiks det smaleste objektet som forklarer forskjellen. Hvis unntaket er godkjent, skriv ned prefikset og la det være; hvis ikke, fjern ruten eller legg til en eksplisitt smalere rute gjennom tunnelen i stedet for å senke metrikken til standardruten. Å senke en metrikk kan ikke overgå et lengre prefiks, og å redigere standarden mens to /1-ruter eier internettveien endrer heller ingenting.

Koble deretter tunnelen til på nytt og gjenta den samme spørringen. Klienter installerer ruter på nytt ved hver tilkobling, så en endring som bare varer til neste håndtrykk, er ikke testet. Hvis veien fortsatt avviker, er de gjenværende mistenkte en policyregel, en andre tabell eller et filter på klientsiden — ikke standardruten.

• Navngi destinasjonen og kildeadressen appen faktisk bruker.
• Skriv ut vinnerruten med ip route get eller Find-NetRoute.
• Sjekk om et /1-par eller en policytabell eier internettveien.
• List opp hvert prefiks som er lengre enn /0 og samsvarer med destinasjonen.
• Gjenta IPv6-sjekken separat.
• Spor den overlevende ruten tilbake til filen, profilen eller filteret som installerer den.
• Koble til på nytt og kjør spørringen på nytt før du kaller det fikset.

Hvis alle sju er enige med profilen, gjør tunnelen nøyaktig det den ble konfigurert til, og fiksen hører hjemme i profilen og ikke i en metrikk.