Waarom een subnet jou VPN-verstekroete steeds omseil

Jy skakel die VPN oor na voltonnel, die meeste verkeer gehoorsaam, en dan antwoord een adres direk — 'n drukker, 'n NAS, 'n spronggasheer op 10.x. Die ooglopende lesing is dat die tonnel lek, so jy verlaag die metriek op die verstekroete en niks verander nie. Daardie mislukte poging is die leidraad: 'n verstekroete is 'n terugval, nie 'n uitspraak nie. Die roetesoek neem die langste ooreenstemmende voorvoegsel voordat dit ooit metrieke vergelyk, so 'n /24 bly wen teen 'n /0 maak nie saak watter nommer jy aan enigeen heg nie. Sodra daardie ordening duidelik is, is die lek gewoonlik 'n roete wat iemand doelbewus geïnstalleer het, of 'n voorvoegsel wat die kliënt nooit bedoel het om te dek nie.

Wat 'n verstekroete werklik belowe

0.0.0.0/0 pas by elke IPv4-bestemming met nul bisse spesifisiteit. Dit bestaan sodat 'n gasheer enigiets kan bereik wat sy tabel nie beter beskryf nie. 'n Roete na 192.168.1.0/24 dra 24 ooreenstemmende bisse, so vir 192.168.1.40 wen dit voordat iemand metrieke, administratiewe afstand of wat die kliënt ook al sy prioriteitsveld noem, vergelyk. Dieselfde reël geld in die Linux-FIB, die Windows-roetetabel en die BSD-stapel agter macOS.

Op 'n normale LAN is daardie gedrag 'n kenmerk. Die plaaslike subnet is direk gekoppel, die drukker bly werk terwyl die tonnel jou blaai dra, en niks is verkeerd opgestel nie. Die vraag werd om te vra is nie hoekom daardie een adres direk gaan nie, maar watter voorvoegsel in watter tabel daarmee pas, en wie dit daar gesit het.

Half-verstekroetes, of hoekom die verstekinskrywing ongerep kan lyk

OpenVPN se redirect-gateway def1 is die skoonste voorbeeld. In plaas daarvan om jou verstek te skrap en te vervang, voeg dit 0.0.0.0/1 en 128.0.0.0/1 by. Saam dek die paar die hele IPv4, elke voorvoegsel is langer as /0, en albei klop die router se verstek terwyl dit in plek bly. Hardloop daarna 'n roetelys en die oorspronklike verstek is steeds daar, steeds na jou gateway gerig; dit word bloot nooit vir internetbestemmings gekies nie.

WireGuard se wg-quick bereik dieselfde uitkoms deur beleidsroetering. Met AllowedIPs wat 0.0.0.0/0 dek, skep dit sy eie tabel, stuur gemerkte pakkette daarheen en voeg 'n reël by wat die hoof-tabel se nul-lengte-voorvoegsel ignoreer. Die hoof-tabel hou sy verstekinskrywing, en die reëls bepaal dat die tonneltabel eerste geraadpleeg word vir die verkeer wat die koppelvlak besit.

Albei ontwerpe het presies een roete buite die tonnel nodig: 'n gasheerroete na die VPN-bediener se eie adres deur die oorspronklike gateway. Sonder dit sou die kliënt probeer om die pakkette wat die tonnel bou binne die tonnel te dra, en die verbinding voltooi nooit nie. 'n Nie-tonnelroete in jou tabel is dus normaal selfs op 'n streng voltonnelprofiel. Die roetes wat bevraagteken moet word, is dié wat bestemmings dek waaraan jy werklik omgee.

Metrieke beslis gelykop, voorvoegsels beslis wenners

Metrieke word slegs vergelyk tussen kandidate wat die bestemming ewe goed pas. Op Linux, ip route get 10.20.5.9 druk die wenner saam met sy tabel uit, en ip route show table all lys die kandidate, insluitend enige half-verstekke en enige tabel waarna 'n reël wys. Op Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 gee die gekose roete en bronadres terug, terwyl Get-NetRoute die ruwe tabel wys — maar die doeltreffende koste is roetemetriek plus koppelvlakmetriek, so 'n stadige adapter kan 'n gelykop verloor wat hy skynbaar wen.

Drie gevalle dek die meeste van wat jy sal sien:

• Dieselfde bestemming, /24 teen /0: die /24 wen op voorvoegsellengte, wat die metrieke ook al sê.
• Dieselfde bestemming, twee /24's met verskillende metrieke: die laer doeltreffende metriek wen.
• Dieselfde bestemming, twee tabelle, een gekies deur 'n beleidsreël: die reël kies eers die tabel, en voorvoegselvergeliking gebeur binne dit.

Die derde geval is waar die meeste van hierdie verslae beland. 'n Linux ip rule of 'n Windows VPN-verkeersfilter kan verkeer na 'n tabel stuur wat nooit die tonnelverstek gehad het nie, en die hoof-tabel lyk die hele tyd perfek.

Wie besit gewoonlik die omseiling

Begin by die profiel, nie die tabel nie. Split-tonnel-konfigurasies en per-app-VPN-instellings laat doelbewus benoemde voorvoegsels buite die tonnel; 'n werkprofiel wat een private subnet beskerm en algemene blaai direk laat gaan, gedra hom soos ontwerp, en om dit te oorheers breek die beleid wat dit moes afdwing. Microsoft se VPN-roeterigting trek dieselfde lyn tussen geforseerde tonnelverkeer en eksplisiete uitsonderings, wat dit 'n nuttige kruiskontrole maak voordat jy enigiets wysig.

Soek daarna vir oorblyfsels. 'n Roete wat na 'n koppelvlak wys wat nie meer bestaan nie, of na 'n adres uit die vorige netwerk, duik op nadat dokstasies, USB-adapters en houerbruggies kom en gaan. Om dit een keer te skrap is nie die einde daarvan nie: NetworkManager-verbindingsprofiele, netplan-lêers en Windows se blywende roetes herinstalleer dit by die volgende verbinding of selfslaan, so vind die lêer of profiel wat dit besit voordat jy enigiets wysig.

Kontroleer dan IPv6 op sy eie. ip -6 route en Get-NetRoute -AddressFamily IPv6 hou aparte toestand, aparte verstekke en aparte kliëntgedrag. 'n Slegs-IPv4-oudit sê niks oor 'n dubbelstapel-gasheer wat stilweg 'n inheemse IPv6-pad verkies nie, en dit alleen kan 'n kliënt laat lyk asof hy split-tonnel is.

Bevestig met die toepassing se eie vloei

Teken die bestemming aan wat die toepassing werklik gebruik, vra dan die stelsel vir die pad wat dit sou neem vanaf die bronadres wat daardie toepassing bind. ip route get 10.20.5.9 from 192.168.1.40 antwoord dit op Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus die plaaslike adres doen dit op Windows. Vergelyk die resultaat met wat die profiel beweer. 'n Blaaier se publieke-IP-bladsy toets een bestemming op een protokol en sê niks oor die private adres wat die klag begin het nie.

Repareer die engste objek wat die verskil verklaar. As die uitsondering goedgekeur is, skryf die voorvoegsel neer en los dit; indien nie, verwyder die roete of voeg 'n eksplisiete smaller roete deur die tonnel by in plaas daarvan om die verstek se metriek te verlaag. Om 'n metriek te verlaag kan nie 'n langer voorvoegsel oorterf nie, en om die verstek te wysig terwyl twee /1-roetes die internetpad besit, verander ook niks.

Herverbind dan die tonnel en herhaal dieselfde navraag. Kliënte herinstalleer roetes by elke verbinding, so 'n verandering wat net tot die volgende handdruk oorleef, is nie getoets nie. As die pad steeds afwyk, is die oorblywende verdagtes 'n beleidsreël, 'n tweede tabel of 'n kliëntkantige filter — nie die verstekroete nie.

• Noem die bestemming en die bronadres wat die app werklik gebruik.
• Druk die wenroete uit met ip route get of Find-NetRoute.
• Kontroleer of 'n /1-paar of 'n beleidstabel die internetpad besit.
• Lys elke voorvoegsel langer as /0 wat by die bestemming pas.
• Herhaal die IPv6-kontrole afsonderlik.
• Spoor die oorblywende roete terug na die lêer, profiel of filter wat dit installeer.
• Herverbind en herhaal die navraag voordat jy dit opgelos noem.

As al sewe met die profiel ooreenstem, doen die tonnel presies wat dit opgestel is om te doen, en hoort die oplossing in die profiel eerder as in 'n metriek.