Hvordan delt tunnel avgjør hvilken trafikk som bruker VPN-en

En delt tunnel er en rutepolicy uttrykt som et sett regler, og klienten er bare det som installerer dem. Delingen skjer på to steder: matchende regler som velger en vei for hver pakke, og bindinger som holder en applikasjon på ett grensesnitt uansett hva tabellen sier. Hvilken mekanisme klienten din hviler på, forklarer de fleste overraskelsene folk rapporterer.

En policy du kan uttrykke på én linje, er testbar. En policy beskrevet som raskere surfing er det ikke, og den vil ikke fortelle deg hvilken regel du skal endre når en forespørsel går feil vei.

Klienten installerer regler, kjernen gjør valget

Når tunnelen kommer opp, legger klienten til ruter og ofte policyregler i samme tabell som de andre grensesnittene dine bruker. Hver pakke når deretter et oppslag som sammenligner destinasjonen med hvert kandidatprefiks og beholder det mest spesifikke treffet, mens prioritet avgjør uavgjorte forhold mellom regler som peker på forskjellige tabeller. Ingenting i det oppslaget vet at pakken kom fra en nettleserfane og ikke fra en sikkerhetskopijobb. Regelen som vinner, er den som setter veien, og du kan lese den før og etter endringen.

Derfor kan en delt tunnel virke vilkårlig. To destinasjoner i én applikasjon kan ta forskjellige veier bare fordi det ene prefikset er smalere enn det andre.

Det samme valget finnes på hver plattform, selv om navnene endres. Windows skyver beslutningen inn i filterplattformen sin, Android eksponerer en tillatelsesliste per app gjennom VPN-tjenesten sin, og macOS knytter tunnelen til en enhet som fortsatt adlyder rutetabellen. Microsofts rutenotater er verdt å lese for Windows-tilfellet, og en guide skrevet for én plattform overføres sjelden uendret til en annen.

Binding per app og destinasjonsprefikser er forskjellige verktøy

En destinasjonspolicy spør hvor pakken skal, og rådfører seg med rutetabellen eller en policyregel. En policy per app spør hvilket program som åpnet sokkelen, og plattformen holder det programmet på tunnelets grensesnitt selv når en mer spesifikk rute peker et annet sted. Den andre er sterkere fordi den overlever tabellendringer, men den dekker bare prosesser plattformen kan tilskrive. En hjelpeprosess, en innebygd nettleser eller en tjeneste som åpner sin egen forbindelse arver kanskje ikke bindingen du antok.

Ingen av de to tilnærmingene overlever en navnebasert policy uten hjelp. Adresser til store nettsteder roterer mellom innholdsnetverk, så å feste et vertsnavn til noen få prefikser gir en regel som stille slutter å stemme. En policy som må følge navn, trenger en resolverbevisst komponent i stedet for en statisk rute.

DNS og sikkerhetsbryteren følger sine egne regler

Navneoppslag er en beslutning atskilt fra pakkeruting, og en delt tunnel vil vanligvis ha to resolvere: bedriftens for interne navn, den lokale for alt annet. Klienten kan installere DNS-innstillinger per grensesnitt, gi spørringer til en mellomresolver eller la systemstandarden være urørt. En nettleser med sin egen krypterte resolver omgår alle tre ordningene. Test et oppslag i stedet for å anta at resolveren fulgte ruten.

En sikkerhetsbryter legger et filter på toppen, og det filteret skiller ikke alltid en tilsiktet utelatelse fra en utilsiktet lekkasje. Noen klienter blokkerer alt utenfor tunnelen, mens andre tillater utelatelsene policyen erklærer, så les hvilken atferd din implementerer før du stoler på noen av dem.

Kontroller delingen fra begge sider

Test den inkluderte veien og den ekskluderte veien hver for seg, og vurder resultatet etter grensesnittnavn og ikke etter en offentlig adresse. Disse kommandoene forutsetter en Linux-vert med tunneleenheten allerede oppe. Erstatt 203.0.113.10 med en destinasjon som policyen din ruter innover, og 198.51.100.25 med en den sender utover.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Les de to første svarene sammen, fordi grensesnittet som nevnes i hvert av dem viser om delingen satte den destinasjonen på tunnelen. Resolverspørringen viser hvilken server som svarte på det interne navnet, og den siste kommandoen beviser at tunneleenheten i det hele tatt kan bære en forespørsel. En feil på den andre linjen mens den første lykkes, betyr at policyen gjør nøyaktig det den ble bedt om.

Gjenta settet etter en ny tilkobling og etter en nettverksendring. Leiefornyelse og grensesnittbytte er der en deling slutter å stemme med hensikten den ble bygget for, og et lagret resultat fra hver kjøring gjør avviket tydelig.