Hur delad tunnel avgör vilken trafik som använder VPN:en

En delad tunnel är en routingpolicy uttryckt som en uppsättning regler, och klienten är bara det som installerar dem. Uppdelningen sker på två ställen: matchande regler som väljer en väg för varje paket, och bindningar som håller en applikation på ett gränssnitt vad tabellen än säger. Vilken mekanism din klient lutar sig mot förklarar de flesta överraskningar folk rapporterar.

En policy du kan uttrycka på en rad är testbar. En policy beskriven som snabbare surf är det inte, och den kommer inte att säga vilken regel du ska ändra när en begäran går fel väg.

Klienten installerar regler, kärnan gör valet

När tunneln kommer upp lägger klienten till rutter och ofta policyregler i samma tabell som dina andra gränssnitt använder. Varje paket når sedan en sökning som jämför destinationen med varje kandidatprefix och behåller den mest specifika träffen, medan prioritet avgör oavgjorda lägen mellan regler som pekar på olika tabeller. Inget i den sökningen vet att paketet kom från en webbläsarflik och inte från ett säkerhetskopieringsjobb. Regeln som vinner är den som sätter vägen, och du kan läsa den före och efter ändringen.

Därför kan en delad tunnel verka godtycklig. Två destinationer i en applikation kan ta olika vägar bara för att det ena prefixet är smalare än det andra.

Samma val finns på varje plattform, även om namnen ändras. Windows skjuter in beslutet i sin filterplattform, Android exponerar en tillåtelselista per app via sin VPN-tjänst, och macOS knyter tunneln till en enhet som fortfarande lyder routingtabellen. Microsofts routinganteckningar är värda att läsa för Windows-fallet, och en guide skriven för en plattform överförs sällan oförändrad till en annan.

Bindning per app och destinationsprefix är olika verktyg

En destinationspolicy frågar vart paketet tar vägen och rådgör med rutttabellen eller en policyregel. En policy per app frågar vilket program som öppnade socketen, och plattformen håller det programmet på tunnelns gränssnitt även när en mer specifik rutt pekar någon annanstans. Den andra är starkare eftersom den överlever tabelländringar, men den täcker bara processer som plattformen kan tillskriva. En hjälpprocess, en inbäddad webbläsare eller en tjänst som öppnar sin egen anslutning ärver kanske inte den bindning du antog.

Ingen av de två metoderna överlever en namnbaserad policy utan hjälp. Adresser till stora webbplatser roterar mellan innehållsnätverk, så att fästa ett värdnamn vid några prefix ger en regel som tyst slutar matcha. En policy som måste följa namn behöver en resolvermedveten komponent i stället för en statisk rutt.

DNS och säkerhetsbrytaren följer sina egna regler

Namnuppslagning är ett beslut skilt från paketrouting, och en delad tunnel vill oftast ha två resolvrar: företagets för interna namn, den lokala för allt annat. Klienten kan installera DNS-inställningar per gränssnitt, lämna frågor till en mellanresolver eller låta systemstandarden vara orörd. En webbläsare med egen krypterad resolver kringgår alla tre arrangemangen. Testa en sökning i stället för att anta att resolvern följde rutten.

En säkerhetsbrytare lägger ett filter ovanpå, och det filtret skiljer inte alltid en avsedd undantag från ett oavsiktligt läckage. Vissa klienter blockerar allt utanför tunneln medan andra tillåter de undantag som policyn deklarerar, så läs vilket beteende din implementerar innan du litar på något av dem.

Kontrollera uppdelningen från båda sidor

Testa den inkluderade vägen och den uteslutna vägen var för sig, och bedöm resultatet efter gränssnittsnamn och inte efter en offentlig adress. De här kommandona förutsätter en Linux-värd med tunneleenheten redan uppe. Ersätt 203.0.113.10 med en destination som din policy routar inåt, och 198.51.100.25 med en som den skickar utåt.

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 två första svaren tillsammans, eftersom gränssnittet som nämns i varje svar visar om uppdelningen lade den destinationen på tunneln. Resolverfrågan visar vilken server som svarade på det interna namnet, och det sista kommandot bevisar att tunneleenheten alls kan bära en begäran. Ett fel på den andra raden medan den första lyckas betyder att policyn gör precis det den blev tillsagd.

Upprepa uppsättningen efter en återanslutning och efter en nätverksändring. Leaseförnyelse och gränssnittsbyte är där en uppdelning slutar stämma med den avsikt den byggdes för, och en sparad utskrift från varje körning gör avvikelsen tydlig.