Hvordan en opdelt tunnel afgør, hvilken trafik der bruger VPN

En opdelt tunnel er en rutepolitik udtrykt som et sæt regler, og klienten er kun det, der installerer dem. Opdelingen sker to steder: matchningsregler, der vælger en vej for hver pakke, og bindinger, der holder en applikation på et interface, uanset hvad tabellen siger. Hvilken mekanisme din klient hviler på, forklarer de fleste af de overraskelser, folk rapporterer.

En politik, du kan udtrykke på én linje, kan testes. En politik beskrevet som hurtigere browsing kan ikke, og den fortæller dig ikke, hvilken regel du skal ændre, når en anmodning går den forkerte vej.

Klienten installerer regler, kernen træffer valget

Når tunnelen kommer op, tilføjer klienten ruter og ofte politikregler til den samme tabel, som dine andre interfaces bruger. Hver pakke når derefter et opslag, der sammenligner dens destination med hvert kandidatpræfiks og beholder det mest specifikke match, mens prioritet afgør uafgjorte forhold mellem regler, der peger på forskellige tabeller. Intet i det opslag ved, at pakken kom fra en browservane snarere end et backupjob. Den regel, der vinder, er den, der fastlægger vejen, og du kan læse den før og efter ændringen.

Derfor kan en opdelt tunnel virke vilkårlig. To destinationer i én applikation kan tage forskellige veje, blot fordi det ene præfiks er smallere end det andet.

Det samme valg findes på hver platform, selvom navnene skifter. Windows skubber beslutningen ind i sin filterplatform, Android udstiller en tilladelsesliste pr. app gennem sin VPN-tjeneste, og macOS knytter tunnelen til en enhed, der stadig adlyder rutetabellen. Microsofts routingnotater er værd at læse for Windows-tilfældet, og en guide skrevet til én platform overføres sjældent uændret til en anden.

Binding pr. app og destinationspræfikser er forskellige værktøjer

En destinationspolitik spørger, hvor pakken er på vej hen, og rådspørger rutetabellen eller en politikregel. En politik pr. app spørger, hvilket program der åbnede soklen, og platformen holder det program på tunnelett interfacet, selv når en mere specifik rute peger et andet sted. Den anden er stærkere, fordi den overlever tabelændringer, men den dækker kun processer, som platformen kan tilskrive. En hjælpeproces, en indlejret browser eller en tjeneste, der åbner sin egen forbindelse, arver måske ikke den binding, du antog.

Ingen af de to tilgange overlever en navnebaseret politik uden hjælp. Adresser til store websteder roterer mellem indholdsnetværk, så fastlåsning af et værtsnavn til få præfikser skaber en regel, der stille holder op med at matche. En politik, der skal følge navne, kræver en resolverbevidst komponent i stedet for en statisk rute.

DNS og sikkerhedskontakten følger deres egne regler

Navneopløsning er en beslutning adskilt fra pakkeruting, og en opdelt tunnel vil normalt have to resolvere: virksomhedens til interne navne, den lokale til alt andet. Klienten kan installere DNS-indstillinger pr. interface, give forespørgsler til en stub-resolver eller lade systemstandarden være urørt. En browser med sin egen krypterede resolver omgår alle tre arrangementer. Test et opslag i stedet for at antage, at resolveren fulgte ruten.

En sikkerhedskontakt lægger et filter ovenpå, og det filter skelner ikke altid en tilsigtet udeladelse fra en utilsigtet lækage. Nogle klienter blokerer alt uden for tunnelen, mens andre tillader de udeladelser, politikken erklærer, så læs, hvilken adfærd din implementerer, før du stoler på nogen af dem.

Kontroller opdelingen fra begge sider

Test den inkluderede vej og den udelukkede vej hver for sig, og vurdér resultatet efter interfacenavn frem for efter en offentlig adresse. Disse kommandoer forudsætter en Linux-vært med tunneleenheden allerede oppe. Erstat 203.0.113.10 med en destination, som din politik ruter indad, og 198.51.100.25 med en, den sender udad.

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'

Læs de første to svar sammen, fordi det interface, der nævnes i hvert, viser, om opdelingen satte den destination på tunnelen. Resolverforespørgslen viser, hvilken server der svarede på det interne navn, og den sidste kommando beviser, at tunneleenheden overhovedet kan bære en anmodning. En fejl på anden linje, mens den første lykkes, betyder, at politikken gør præcis, hvad den fik besked om.

Gentag sættet efter en genopkobling og efter en netværksændring. Leasefornyelse og interfaceudskiftning er der, hvor en opdeling holder op med at matche hensigten, den blev bygget til, og et gemt output fra hver kørsel gør driften tydelig.