Hoe split-tunneling bepaalt welk verkeer de VPN gebruikt

Split-tunneling is een routeringsbeleid dat als een reeks regels is uitgedrukt, en de client is alleen het ding dat ze installeert. De scheiding gebeurt op twee plaatsen: regels die overeenkomen en voor elk pakket een pad kiezen, en bindingen die een toepassing aan één interface houden, wat de tabel ook zegt. Welk mechanisme uw client gebruikt, verklaart de meeste verrassingen die mensen melden.

Een beleid dat u in één regel kunt formuleren, is testbaar. Een beleid dat als sneller browsen wordt beschreven niet, en het zal u niet vertellen welke regel u moet wijzigen wanneer een verzoek de verkeerde kant op gaat.

De client installeert regels, de kernel maakt de keuze

Wanneer de tunnel omhoog komt, voegt de client routes en vaak beleidsregels toe aan dezelfde tabel die uw andere interfaces gebruiken. Elk pakket bereikt dan een opzoeking die de bestemming vergelijkt met elk kandidaatprefix en de meest specifieke overeenkomst houdt, terwijl prioriteit gelijke standen beslecht tussen regels die naar verschillende tabellen wijzen. Niets in die opzoeking weet dat het pakket uit een browsertab en niet uit een back-uptaak kwam. De regel die wint, is degene die het pad vastlegt, en u kunt hem voor en na de wijziging lezen.

Daarom kan een split-tunnel willekeurig lijken. Twee bestemmingen in één toepassing kunnen verschillende paden nemen, alleen omdat het ene prefix smaller is dan het andere.

Dezelfde keuze bestaat op elk platform, al veranderen de namen. Windows duwt de beslissing in zijn filterplatform, Android stelt via zijn VPN-dienst een toelatingslijst per app beschikbaar, en macOS koppelt de tunnel aan een apparaat dat de routeringstabel nog steeds gehoorzaamt. De routeringsnotities van Microsoft zijn de moeite waard voor het Windows-geval, en een gids die voor één platform is geschreven, wordt zelden ongewijzigd naar een ander overgedragen.

Binding per app en bestemmingsprefixen zijn verschillende hulpmiddelen

Een bestemmingsbeleid vraagt waar het pakket heen gaat en raadpleegt de routetabel of een beleidsregel. Een beleid per app vraagt welk programma de socket heeft geopend, en het platform houdt dat programma op de tunnelinterface, zelfs wanneer een specifiekere route elders heen wijst. Het tweede is sterker omdat het tabelwijzigingen overleeft, maar het dekt alleen processen die het platform kan toeschrijven. Een hulpproces, een ingebouwde browser of een dienst die zijn eigen verbinding opent, erft mogelijk niet de binding die u aannam.

Geen van beide benaderingen overleeft een op namen gebaseerd beleid zonder hulp. Adressen van grote sites roteren tussen contentnetwerken, dus een hostnaam aan een paar prefixen vastpinnen levert een regel op die stilzwijgend ophoudt te passen. Een beleid dat namen moet volgen, heeft een resolverbewuste component nodig in plaats van een statische route.

DNS en de kill-switch volgen hun eigen regels

Naamresolutie is een aparte beslissing van pakketroutering, en een split-tunnel wil meestal twee resolvers: die van het bedrijf voor interne namen, de lokale voor al het andere. De client kan DNS-instellingen per interface installeren, vragen aan een tussenresolver geven of de systeemstandaard ongemoeid laten. Een browser met zijn eigen versleutelde resolver omzeilt alle drie de regelingen. Test een opzoeking in plaats van aan te nemen dat de resolver de route volgde.

Een kill-switch voegt een filter bovenop, en dat filter onderscheidt niet altijd een bedoelde uitsluiting van een toevallige lekkage. Sommige clients blokkeren alles buiten de tunnel, terwijl andere de uitsluitingen toestaan die het beleid verklaart, dus lees welk gedrag de uwe implementeert voordat u op een van beide vertrouwt.

Controleer de splitsing van beide kanten

Test het inbegrepen pad en het uitgesloten pad afzonderlijk, en beoordeel het resultaat aan de interfacenaam in plaats van aan een openbaar adres. Deze opdrachten veronderstellen een Linux-host met het tunnelapparaat al omhoog. Vervang 203.0.113.10 door een bestemming die uw beleid naar binnen routeert, en 198.51.100.25 door een die het naar buiten stuurt.

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'

Lees de eerste twee antwoorden samen, want de interface die in elk ervan wordt genoemd, toont of de splitsing die bestemming op de tunnel heeft gezet. De resolvervraag toont welke server het interne naam heeft beantwoord, en de laatste opdracht bewijst dat het tunnelapparaat überhaupt een verzoek kan dragen. Een fout op de tweede regel terwijl de eerste slaagt, betekent dat het beleid precies doet wat ervan is gevraagd.

Herhaal de set na een herverbinding en na een netwerkwijziging. Leasevernieuwing en interfacewisselingen zijn waar een splitsing ophoudt te passen bij de bedoeling waarvoor zij is gebouwd, en een opgeslagen uitvoer van elke run maakt de afwijking duidelijk.