Waarom één subnet nog steeds de standaardroute van je VPN omzeilt

Je schakelt de VPN om naar volledige tunnel, het meeste verkeer gehoorzaamt, en dan antwoordt één adres direct — een printer, een NAS, een jumphost op 10.x. De voor de hand liggende lezing is dat de tunnel lekt, dus je verlaagt de metriek op de standaardroute en er verandert niets. Die mislukte poging is de aanwijzing: een standaardroute is een terugvaloptie, geen vonnis. De routeopzoeking neemt het langste overeenkomende prefix voordat er ooit metrieken worden vergeleken, dus een /24 blijft winnen van een /0, ongeacht welk getal je aan een van beide hangt. Zodra die volgorde duidelijk is, is het lek meestal een route die iemand expres heeft geïnstalleerd, of een prefix die de client nooit bedoelde te dekken.

Wat een standaardroute werkelijk belooft

0.0.0.0/0 komt overeen met elke IPv4-bestemming met nul bits specificiteit. Hij bestaat zodat een host alles kan bereiken wat zijn tabel niet beter beschrijft. Een route naar 192.168.1.0/24 draagt 24 overeenkomende bits, dus voor 192.168.1.40 wint hij voordat iemand metrieken, administratieve afstand of hoe de client zijn prioriteitsveld ook noemt vergelijkt. Dezelfde regel geldt in de Linux-FIB, de Windows-routingtabel en de BSD-stack achter macOS.

Op een normaal LAN is dat gedrag een functie. Het lokale subnet is direct aangesloten, de printer blijft werken terwijl de tunnel je browsen draagt, en niets is verkeerd geconfigureerd. De vraag die het stellen waard is, is niet waarom dat ene adres direct gaat, maar welk prefix in welke tabel ermee overeenkomt, en wie het daar heeft neergezet.

Halve standaardroutes, of waarom de standaardingang onaangeroerd kan lijken

Het schoonste voorbeeld is redirect-gateway def1 bij OpenVPN. In plaats van je standaardroute te verwijderen en te vervangen, voegt het 0.0.0.0/1 en 128.0.0.0/1 toe. Samen dekt het paar heel IPv4, elk prefix is langer dan /0, en beide verslaan de standaard van de router terwijl die blijft staan. Draai daarna een routelijst en de oorspronkelijke standaardroute staat er nog, wijst nog naar je gateway; hij wordt alleen nooit gekozen voor internetbestemmingen.

WireGuards wg-quick bereikt hetzelfde via beleidsgebaseerde routing. Als AllowedIPs 0.0.0.0/0 dekt, maakt het zijn eigen tabel, stuurt gemarkeerde pakketten daarheen en voegt een regel toe die het prefix van lengte nul van de hoofdtabel negeert. De hoofdtabel houdt zijn standaardingang, en de regels bepalen dat de tunneltabel eerst wordt geraadpleegd voor het verkeer dat de interface bezit.

Beide ontwerpen hebben precies één route buiten de tunnel nodig: een hostroute naar het eigen adres van de VPN-server via de oorspronkelijke gateway. Zonder die route zou de client proberen de pakketten die de tunnel bouwen binnen de tunnel te dragen, en de verbinding komt nooit tot stand. Een route die geen tunnel is, is in je tabel dus normaal, zelfs op een streng volledig-tunnelprofiel. De routes die het bevragen waard zijn, zijn de routes die bestemmingen dekken waar je echt om geeft.

Metrieken beslissen gelijkspel, prefixen beslissen winnaars

Metrieken worden alleen vergeleken tussen kandidaten die even goed bij de bestemming passen. Op Linux ip route get 10.20.5.9 print de winnaar samen met zijn tabel, en ip route show table all somt de kandidaten op, inclusief eventuele halve standaardroutes en elke tabel waar een regel naar wijst. Op Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 geeft de gekozen route en het bronadres terug, terwijl Get-NetRoute de ruwe tabel toont — maar de effectieve kosten zijn routemetriek plus interfacemetriek, dus een trage adapter kan een gelijkspel verliezen dat hij lijkt te winnen.

Drie gevallen dekken het meeste van wat je zult zien:

• Dezelfde bestemming, /24 tegen /0: de /24 wint op prefixlengte, wat de metrieken ook zeggen.
• Dezelfde bestemming, twee /24's met verschillende metrieken: de laagste effectieve metriek wint.
• Dezelfde bestemming, twee tabellen, één gekozen door een beleidsregel: de regel kiest eerst de tabel, en de prefixvergelijking gebeurt daarbinnen.

Het derde geval is waar de meeste van deze meldingen eindigen. Een ip rule in Linux of een Windows VPN-verkeersfilter kan verkeer naar een tabel sturen die nooit de standaard van de tunnel heeft gehad, en de hoofdtabel ziet er de hele tijd perfect uit.

Wie de omleiding meestal bezit

Begin bij het profiel, niet bij de tabel. Split-tunnelconfiguraties en VPN-instellingen per app laten genoemde prefixen bewust buiten de tunnel; een werkprofiel dat één privésubnet beschermt en algemeen browsen direct laat gaan, gedraagt zich zoals ontworpen, en het overschrijven ervan breekt het beleid dat het moest afdwingen. Microsofts richtlijn voor VPN-routing trekt dezelfde lijn tussen geforceerd tunnelverkeer en expliciete uitzonderingen, wat het een nuttige kruiscontrole maakt voordat je iets aanpast.

Zoek daarna naar resten. Een route die naar een interface wijst die niet meer bestaat, of naar een adres uit het vorige netwerk, duikt op nadat dockingstations, USB-adapters en containerbruggen komen en gaan. Hem één keer verwijderen is niet het einde: NetworkManager-verbindingsprofielen, netplan-bestanden en persistente Windows-routes installeren hem opnieuw bij de volgende verbinding of opstart, dus vind het bestand of profiel dat hem bezit voordat je iets aanpast.

Controleer daarna IPv6 apart. ip -6 route en Get-NetRoute -AddressFamily IPv6 houden aparte status, aparte standaarden en apart clientgedrag. Een controle van alleen IPv4 zegt niets over een dual-stackhost die stilletjes een native IPv6-pad verkiest, en dat alleen kan een client op split-tunnel laten lijken.

Bevestig met de eigen stroom van de applicatie

Noteer de bestemming die de applicatie echt gebruikt, en vraag het systeem dan naar het pad dat het zou nemen vanaf het bronadres waaraan die applicatie zich bindt. ip route get 10.20.5.9 from 192.168.1.40 beantwoordt dat op Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus het lokale adres doet dat op Windows. Vergelijk het resultaat met wat het profiel beweert. De openbare-IP-pagina van een browser test één bestemming op één protocol en zegt niets over het privéadres dat de klacht begon.

Repareer het smalste object dat het verschil verklaart. Als de uitzondering is goedgekeurd, schrijf het prefix op en laat het staan; zo niet, verwijder de route of voeg een expliciete smallere route door de tunnel toe in plaats van de metriek van de standaard te verlagen. Een metriek verlagen kan een langer prefix niet voorbijstreven, en de standaard aanpassen terwijl twee /1-routes het internetpad bezitten verandert ook niets.

Verbind daarna de tunnel opnieuw en herhaal dezelfde query. Clients installeren bij elke verbinding routes opnieuw, dus een wijziging die alleen tot de volgende handshake standhoudt, is niet getest. Als het pad nog steeds afwijkt, zijn de overgebleven verdachten een beleidsregel, een tweede tabel of een filter aan de clientkant — niet de standaardroute.

• Noem de bestemming en het bronadres dat de app echt gebruikt.
• Print de winnende route met ip route get of Find-NetRoute.
• Controleer of een /1-paar of een beleidstabel het internetpad bezit.
• Som elk prefix op dat langer is dan /0 en bij de bestemming past.
• Herhaal de IPv6-controle apart.
• Volg de overlevende route terug naar het bestand, profiel of filter dat hem installeert.
• Verbind opnieuw en voer de query opnieuw uit voordat je het opgelost noemt.

Als alle zeven met het profiel overeenkomen, doet de tunnel precies wat ervoor geconfigureerd is, en hoort de fix in het profiel thuis, niet in een metriek.