Varför ett subnät fortfarande går förbi VPN:ens standardrutt

Du byter VPN till full tunnel, det mesta av trafiken lyder, och då svarar en adress direkt — en skrivare, en NAS, en hoppvärd på 10.x. Den uppenbara läsningen är att tunneln läcker, så du sänker metriken på standardrutten och ingenting ändras. Det misslyckade försöket är ledtråden: en standardrutt är en reserv, inte en dom. Ruttuppslaget tar det längsta matchande prefixet innan det ens jämför metriker, så en /24 fortsätter att vinna över en /0, oavsett vilket tal du fäster vid någon av dem. När den ordningen är klar är läckan oftast en rutt som någon installerat med avsikt, eller ett prefix som klienten aldrig menade att täcka.

Vad en standardrutt faktiskt lovar

0.0.0.0/0 matchar varje IPv4-destination med noll bitars specificitet. Den finns så att en värd kan nå allt som dess tabell inte beskriver bättre. En rutt till 192.168.1.0/24 bär 24 matchande bitar, så för 192.168.1.40 vinner den innan någon jämför metriker, administrativt avstånd eller vad klienten nu kallar sitt prioritetsfält. Samma regel gäller i Linux FIB, Windows routingtabell och BSD-stacken bakom macOS.

På ett normalt LAN är det beteendet en funktion. Det lokala subnätet är direkt anslutet, skrivaren fortsätter att fungera medan tunneln bär din surfning, och ingenting är felkonfigurerat. Frågan som är värd att ställa är inte varför den där adressen går direkt, utan vilket prefix i vilken tabell som matchar den, och vem som satte det där.

Halvstandardrutter, eller varför standardposten kan se orörd ut

Det renaste exemplet är redirect-gateway def1 i OpenVPN. I stället för att radera din standardrutt och ersätta den lägger den till 0.0.0.0/1 och 128.0.0.0/1. Tillsammans täcker paret hela IPv4, varje prefix är längre än /0, och båda slår routerns standard medan den ligger kvar. Kör en ruttlista efteråt och den ursprungliga standardrutten finns fortfarande kvar, pekar fortfarande på din gateway; den väljs bara aldrig för internetdestinationer.

WireGuards wg-quick når samma resultat genom policybaserad routing. När AllowedIPs täcker 0.0.0.0/0 skapar den sin egen tabell, skickar markerade paket dit och lägger till en regel som ignorerar huvudtabellens prefix med längden noll. Huvudtabellen behåller sin standardpost, och reglerna avgör att tunneltabellen konsulteras först för trafiken som gränssnittet äger.

Båda designerna behöver exakt en rutt utanför tunneln: en värdrutt till VPN-serverns egen adress via den ursprungliga gatewayen. Utan den skulle klienten försöka bära paketen som bygger tunneln inuti tunneln, och anslutningen skulle aldrig slutföras. En rutt som inte är en tunnelrutt i din tabell är därför normal även på en strikt fulltunnelprofil. De rutter som är värda att ifrågasätta är de som täcker destinationer du faktiskt bryr dig om.

Metriker avgör oavgjort, prefix avgör vinnare

Metriker jämförs bara bland kandidater som matchar destinationen lika bra. På Linux ip route get 10.20.5.9 skriver ut vinnaren tillsammans med sin tabell, och ip route show table all listar kandidaterna, inklusive eventuella halvstandardrutter och varje tabell som en regel pekar på. På Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 returnerar den valda rutten och källadressen, medan Get-NetRoute visar den råa tabellen — men den effektiva kostnaden är ruttmetrik plus gränssnittsmetrik, så en långsam adapter kan förlora ett oavgjort som den verkar vinna.

Tre fall täcker det mesta av det du kommer att se:

• Samma destination, /24 mot /0: /24 vinner på prefixlängd, vad metrikerna än säger.
• Samma destination, två /24 med olika metriker: den lägsta effektiva metriken vinner.
• Samma destination, två tabeller, en vald av en policyregel: regeln väljer tabellen först, och prefixjämförelsen sker inuti den.

Det tredje fallet är där de flesta av dessa rapporter slutar. En ip rule i Linux eller ett Windows VPN-trafikfilter kan skicka trafik till en tabell som aldrig har hållit tunnelns standardrutt, och huvudtabellen ser perfekt ut hela tiden.

Vem som vanligtvis äger förbikopplingen

Börja med profilen, inte tabellen. Split-tunnelkonfigurationer och VPN-inställningar per app lämnar medvetet namngivna prefix utanför tunneln; en arbetsprofil som skyddar ett privat subnät och låter allmän surfning gå direkt beter sig som designat, och att åsidosätta den bryter policyn den byggdes för att upprätthålla. Microsofts vägledning för VPN-routing drar samma gräns mellan påtvingad tunneltrafik och uttryckliga undantag, vilket gör den till en användbar korskontroll innan du ändrar något.

Leta sedan efter rester. En rutt som pekar på ett gränssnitt som inte längre finns, eller på en adress från det föregående nätverket, dyker upp efter att dockningsstationer, USB-adapter och containerbryggor kommer och går. Att radera den en gång är inte slutet: NetworkManager-anslutningsprofiler, netplan-filer och Windows beständiga rutter installerar den igen vid nästa anslutning eller uppstart, så hitta filen eller profilen som äger den innan du ändrar något.

Kontrollera sedan IPv6 för sig. ip -6 route och Get-NetRoute -AddressFamily IPv6 håller separat tillstånd, separata standardrutter och separat klientbeteende. En granskning av bara IPv4 säger ingenting om en dual-stack-värd som tyst föredrar en inhemsk IPv6-väg, och det ensamt kan få en klient att se split-tunnel ut.

Bekräfta med applikationens eget flöde

Anteckna destinationen som applikationen faktiskt använder och fråga sedan systemet om den väg den skulle ta från källadressen som applikationen binder sig till. ip route get 10.20.5.9 from 192.168.1.40 svarar på det på Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus den lokala adressen gör det på Windows. Jämför resultatet med vad profilen hävdar. En webbläsares publika IP-sida testar en destination på ett protokoll och säger ingenting om den privata adressen som startade klagomålet.

Åtgärda det smalaste objektet som förklarar skillnaden. Om undantaget är godkänt, skriv ner prefixet och låt det vara; om inte, ta bort rutten eller lägg till en uttrycklig smalare rutt genom tunneln i stället för att sänka standardens metrik. Att sänka en metrik kan inte gå om ett längre prefix, och att redigera standarden medan två /1-rutter äger internetvägen ändrar inte heller någonting.

Anslut sedan tunneln igen och upprepa samma fråga. Klienter installerar om rutter vid varje anslutning, så en ändring som bara håller till nästa handskakning är inte testad. Om vägen fortfarande avviker är de kvarvarande misstänkta en policyregel, en andra tabell eller ett filter på klientsidan — inte standardrutten.

• Namnge destinationen och källadressen som appen faktiskt använder.
• Skriv ut vinnarrutten med ip route get eller Find-NetRoute.
• Kontrollera om ett /1-par eller en policytabell äger internetvägen.
• Lista varje prefix som är längre än /0 och matchar destinationen.
• Upprepa IPv6-kontrollen separat.
• Spåra den överlevande rutten tillbaka till filen, profilen eller filtret som installerar den.
• Anslut igen och kör frågan igen innan du kallar det åtgärdat.

Om alla sju stämmer med profilen gör tunneln exakt det den konfigurerades för, och åtgärden hör hemma i profilen och inte i en metrik.