Kvifor eitt subnett framleis går utanom standardruta til VPN-en

Du byter VPN-en til full tunnel, mesteparten av trafikken lyder, og så svarar éin adresse direkte — ein skrivar, ein NAS, ein hoppvert på 10.x. Den openberre lesinga er at tunnelen lek, så du senkar metrikken på standardruta og ingenting endrar seg. Det mislukka forsøket er leiartråden: ei standardrute er ein reserve, ikkje ein dom. Ruteoppslaget tek det lengste samsvarande prefikset før det i det heile samanliknar metrikkar, så ein /24 held fram med å vinne over ein /0, uansett kva tal du festar til nokon av dei. Når den rekkjefylgja er klar, er lekkasjen vanlegvis ei rute nokon har installert med vilje, eller eit prefiks klienten aldri meinte å dekkje.

Kva ei standardrute faktisk lovar

0.0.0.0/0 samsvarar med kvar IPv4-destinasjon med null bitar spesifisitet. Ho finst for at ein vert skal nå alt tabellen hans ikkje skildrar betre. Ei rute til 192.168.1.0/24 ber 24 samsvarande bitar, så for 192.168.1.40 vinn ho før nokon samanliknar metrikkar, administrativ avstand eller kva klienten kallar prioritetsfeltet sitt. Same regelen gjeld i Linux FIB, Windows-rutetabellen og BSD-stakken bak macOS.

På eit vanleg LAN er den åtferda ein funksjon. Det lokale subnettet er direkte tilkopla, skrivaren held fram med å verke medan tunnelen ber nettlesinga di, og ingenting er feilkonfigurert. Spørsmålet det er verdt å stille er ikkje kvifor den eine adressa går direkte, men kva prefiks i kva tabell som samsvarar med ho, og kven som sette det der.

Halvstandardruter, eller kvifor standardoppføringa kan sjå urørd ut

Det reinaste dømet er redirect-gateway def1 i OpenVPN. I staden for å slette standardruta di og erstatte ho, legg han til 0.0.0.0/1 og 128.0.0.0/1. Saman dekkjer paret heile IPv4, kvart prefiks er lengre enn /0, og begge slår standardruta til rutaren medan ho blir liggjande. Køyr ei ruteliste etterpå, og den opphavlege standardruta er framleis der, peikar framleis på gatewayen din; ho blir berre aldri vald for internettdestinasjonar.

WireGuards wg-quick når same resultatet gjennom policybasert ruting. Når AllowedIPs dekkjer 0.0.0.0/0, lagar han sin eigen tabell, sender merkte pakkar dit og legg til ein regel som ignorerer prefikset med lengd null i hovudtabellen. Hovudtabellen held på standardoppføringa si, og reglane avgjer at tunneltabellen blir rådspurd først for trafikken grensesnittet eig.

Begge designa treng nøyaktig éi rute utanfor tunnelen: ei vertsrute til den eigne adressa til VPN-tenaren via den opphavlege gatewayen. Utan ho ville klienten prøve å bere pakkane som byggjer tunnelen inne i tunnelen, og tilkoplinga blir aldri fullført. Ei rute som ikkje er ei tunnelrute i tabellen din er difor normal sjølv på ein streng fulltunnelprofil. Rutene det er verdt å stille spørsmål ved, er dei som dekkjer destinasjonar du faktisk bryr deg om.

Metrikkar avgjer uavgjort, prefiks avgjer vinnarar

Metrikkar blir berre samanlikna blant kandidatar som samsvarar like godt med destinasjonen. På Linux ip route get 10.20.5.9 skriv ut vinnaren saman med tabellen sin, og ip route show table all listar kandidatane, inkludert eventuelle halvstandardruter og kvar tabell ein regel peikar på. På Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 returnerer den valde ruta og kjeldeadressa, medan Get-NetRoute viser den rå tabellen — men den effektive kostnaden er rutemetrikk pluss grensesnittmetrikk, så ein treg adapter kan tape eit uavgjort resultat han ser ut til å vinne.

Tre tilfelle dekkjer det meste av det du vil sjå:

• Same destinasjon, /24 mot /0: /24 vinn på prefikslengd, uansett kva metrikkane seier.
• Same destinasjon, to /24 med ulike metrikkar: den lågaste effektive metrikken vinn.
• Same destinasjon, to tabellar, éin vald av ein policyregel: regelen vel tabellen først, og prefikssamanlikninga skjer inne i han.

Det tredje tilfellet er der dei fleste av desse rapportane endar. Ein ip rule i Linux eller eit Windows VPN-trafikkfilter kan sende trafikk til ein tabell som aldri har halde standardruta til tunnelen, og hovudtabellen ser perfekt ut heile tida.

Kven som vanlegvis eig omvegen

Start med profilen, ikkje tabellen. Split-tunnel-konfigurasjonar og VPN-innstillingar per app lèt namngjevne prefiks liggje utanfor tunnelen med vilje; ein arbeidsprofil som vernar eitt privat subnett og lèt vanleg nettlesing gå direkte, oppfører seg som designa, og å overstyre han bryt policyen han vart bygd for å handheve. Microsofts rettleiing for VPN-ruting dreg same lina mellom tvinga tunneltrafikk og eksplisitte unntak, noko som gjer han til ein nyttig kryssjekk før du endrar noko.

Sjå deretter etter restar. Ei rute som peikar på eit grensesnitt som ikkje finst lenger, eller på ei adresse frå det førre nettet, dukkar opp etter at dokkingstasjonar, USB-adapterar og containerbruer kjem og går. Å slette ho éin gong er ikkje slutten: NetworkManager-tilkoplingsprofilar, netplan-filer og vedvarande Windows-ruter installerar ho på nytt ved neste tilkopling eller oppstart, så finn fila eller profilen som eig ho før du endrar noko.

Sjekk deretter IPv6 for seg sjølv. ip -6 route og Get-NetRoute -AddressFamily IPv6 held separat tilstand, separate standardar og separat klientåtferd. Ein revisjon berre av IPv4 seier ingenting om ein dual-stack-vert som stille føretrekkjer ein innfødd IPv6-veg, og det åleine kan få ein klient til å sjå split-tunnel ut.

Stadfest med den eigentlege flyten til applikasjonen

Noter destinasjonen applikasjonen faktisk brukar, og spør deretter systemet om vegen han ville ta frå kjeldeadressa applikasjonen bind seg til. ip route get 10.20.5.9 from 192.168.1.40 svarar på det på Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 pluss den lokale adressa gjer det på Windows. Samanlikn resultatet med det profilen hevdar. Den offentlege IP-sida til ein nettlesar testar éin destinasjon på éin protokoll og seier ingenting om den private adressa som starta klaga.

Fiks den smalaste gjenstanden som forklarar skilnaden. Viss unntaket er godkjent, skriv ned prefikset og lat det vere; viss ikkje, fjern ruta eller legg til ei eksplisitt smalare rute gjennom tunnelen i staden for å senke metrikken til standardruta. Å senke ein metrikk kan ikkje overgå eit lengre prefiks, og å endre standarden medan to /1-ruter eig internettvegen endrar heller ingenting.

Kopla deretter tunnelen til på nytt og gjenta den same spørjinga. Klientar installerar ruter på nytt ved kvar tilkopling, så ei endring som berre varer til neste handsaming, er ikkje testa. Viss vegen framleis avvik, er dei gjenverande mistenkte ein policyregel, ein andre tabell eller eit filter på klientsida — ikkje standardruta.

• Namngje destinasjonen og kjeldeadressa appen faktisk brukar.
• Skriv ut vinnarruta med ip route get eller Find-NetRoute.
• Sjekk om eit /1-par eller ein policytabell eig internettvegen.
• List opp kvart prefiks som er lengre enn /0 og samsvarar med destinasjonen.
• Gjenta IPv6-sjekken separat.
• Spor den overlevande ruta tilbake til fila, profilen eller filteret som installerar ho.
• Kopla til på nytt og køyr spørjinga på nytt før du kallar det fiksa.

Viss alle sju er samde med profilen, gjer tunnelen nøyaktig det han vart konfigurert til, og fiksen høyrer heime i profilen og ikkje i ein metrikk.