Korleis delt tunnel avgjer kva trafikk som brukar VPN-en
Ein delt tunnel er eit sett med rute- og bindingsavgjerder, ikkje ein modus du slår på. Sjå korleis reglar per app, prefiks, DNS og tryggingsbrytarar spelar saman.
Ein delt tunnel er ein rutepolicy uttrykt som eit sett reglar, og klienten er berre det som installerer dei. Delinga skjer på to stader: matchande reglar som vel ein veg for kvar pakke, og bindingar som held ein applikasjon på eitt grensesnitt uansett kva tabellen seier. Kva mekanisme klienten din kviler på, forklarer dei fleste overraskingane folk rapporterer.
Ein policy du kan uttrykkje på éi linje, er testbar. Ein policy skildra som raskare surfing er det ikkje, og han vil ikkje fortelje deg kva regel du skal endre når ei førespurnad går feil veg.
Klienten installerer reglar, kjernen gjer valet
Når tunnelen kjem opp, legg klienten til ruter og ofte policyreglar i same tabell som dei andre grensesnitta dine brukar. Kvar pakke når deretter eit oppslag som samanliknar destinasjonen med kvart kandidatprefiks og held det mest spesifikke treffet, medan prioritet avgjer uavgjorde tilhøve mellom reglar som peikar på ulike tabellar. Ingenting i det oppslaget veit at pakken kom frå ei nettlesarfane og ikkje frå ein tryggingskopijobb. Regelen som vinn, er den som set vegen, og du kan lese han før og etter endringa.
Derfor kan ein delt tunnel verke vilkårleg. To destinasjonar i éin applikasjon kan ta ulike vegar berre fordi det eine prefikset er smalare enn det andre.
Det same valet finst på kvar plattform, sjølv om namna endrar seg. Windows skyv avgjerda inn i filterplattformen sin, Android eksponerer ei tillatingsliste per app gjennom VPN-tenesta si, og macOS knyter tunnelen til eininga som framleis lyder rutetabellen. Microsoft sine rutenotat er verdt å lese for Windows-tilfellet, og ein guide skriven for éin plattform vert sjeldan overført uendra til ein annan.
Binding per app og destinasjonsprefiks er ulike verktøy
Ein destinasjonspolicy spør kvar pakken skal, og rådfører seg med rutetabellen eller ein policyregel. Ein policy per app spør kva program som opna sokkelen, og plattformen held det programmet på grensesnittet til tunnelen sjølv når ei meir spesifikk rute peikar ein annan stad. Den andre er sterkare fordi han overlever tabellendringar, men han dekkjer berre prosessar plattformen kan tilskrive. Ein hjelpeprosess, ein innebygd nettlesar eller ei teneste som opnar si eiga tilknyting arvar kanskje ikkje bindinga du antok.
Ingen av dei to tilnærmingane overlever ein navnebasert policy utan hjelp. Adresser til store nettstader roterer mellom innhaldsnettverk, så å feste eit vertsnamn til nokre få prefiks gir ein regel som stille sluttar å stemme. Ein policy som må følgje namn, treng ein resolvermedviten komponent i staden for ei statisk rute.
DNS og tryggingsbrytaren følgjer sine eigne reglar
Namneoppslag er ei avgjerd skild frå pakkeruting, og ein delt tunnel vil vanlegvis ha to resolverar: bedrifta sin for interne namn, den lokale for alt anna. Klienten kan installere DNS-innstillingar per grensesnitt, gje spørjingar til ein mellomresolver eller la systemstandarden vere urørt. Ein nettlesar med sin eigen krypterte resolver omgår alle tre ordningane. Test eit oppslag i staden for å anta at resolveren følgde ruta.
Ein tryggingsbrytar legg eit filter på toppen, og det filteret skil ikkje alltid ei tilsikta utelating frå ein utilsikta lekkasje. Nokre klientar blokkerer alt utanfor tunnelen, medan andre tillèt utelatingane policyen erklærer, så les kva åtferd din implementerer før du stolar på nokon av dei.
Kontroller delinga frå begge sider
Test den inkluderte vegen og den ekskluderte vegen kvar for seg, og vurder resultatet etter grensesnittnamn og ikkje etter ei offentleg adresse. Desse kommandoane føreset ein Linux-vert med tunneleininga allereie oppe. Erstatt 203.0.113.10 med ein destinasjon som policyen din ruter innover, og 198.51.100.25 med ein han 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 dei to første svara saman, fordi grensesnittet som er nemnt i kvart av dei viser om delinga sette den destinasjonen på tunnelen. Resolverspørjinga viser kva tenar som svara på det interne namnet, og den siste kommandoen beviser at tunneleininga i det heile kan bere ei førespurnad. Ein feil på den andre linja medan den første lukkast, betyr at policyen gjer nøyaktig det han vart beden om.
Gjenta settet etter ei ny tilkopling og etter ei nettverksendring. Leigefornying og grensesnittbyte er der ei deling sluttar å stemme med hensikta ho vart bygd for, og eit lagra resultat frå kvar køyring gjer avviket tydeleg.