Hoe split-tunneling bepaal watter verkeer die VPN gebruik

Split-tunneling is ’n routeringsbeleid wat as ’n stel reëls uitgedruk word, en die kliënt is net die ding wat hulle installeer. Die skeiding gebeur op twee plekke: reëls wat ooreenstem en vir elke pakkie ’n pad kies, en bindings wat ’n toepassing aan een interface hou, wat die tabel ook al sê. Watter meganisme jou kliënt gebruik, verduidelik die meeste verrassings wat mense rapporteer.

’n Beleid wat jy in een reël kan stel, is toetsbaar. ’n Beleid wat as vinniger blaai beskryf word, is nie, en dit sal jou nie sê watter reël om te verander wanneer ’n versoek die verkeerde kant op gaan nie.

Die kliënt installeer reëls, die kernel maak die keuse

Wanneer die tonnel opkom, voeg die kliënt roetes en dikwels beleidsreëls by dieselfde tabel wat jou ander interfaces gebruik. Elke pakkie bereik dan ’n opsoek wat sy bestemming teen elke kandidaat-prefiks vergelyk en die mees spesifieke ooreenkoms hou, terwyl prioriteit die bande tussen reëls wat na verskillende tabelle wys, beslis. Niks in daardie opsoek weet dat die pakkie van ’n blaaier-oortjie eerder as ’n rugsteuntaak kom nie. Die reël wat wen, is die een wat die pad stel, en jy kan dit voor en ná die verandering lees.

Daarom kan ’n split-tonnel arbitrêr lyk. Twee bestemmings in een toepassing kan verskillende paaie neem bloot omdat een prefiks smaller as die ander is.

Dieselfde keuse bestaan op elke platform, hoewel die name verander. Windows skuif die besluit na sy filterplatform, Android stel ’n per-toepassing-allowlist deur sy VPN-diens bloot, en macOS heg die tonnel aan ’n toestel wat steeds die routeringstabel gehoorsaam. Microsoft se routeringsnotas is die moeite werd om vir die Windows-geval te lees, en ’n gids wat vir een platform geskryf is, word selde onveranderd na ’n ander oorgedra.

Per-toepassing-binding en bestemmingsprefikse is verskillende gereedskap

’n Bestemmingsbeleid vra waar die pakkie heen gaan en raadpleeg die roetetabel of ’n beleidsreël. ’n Per-toepassing-beleid vra watter program die sokket geopen het, en die platform hou daardie program op die tonnel-interface, selfs wanneer ’n meer spesifieke roete elders heen wys. Die tweede is sterker omdat dit tabelveranderinge oorleef, maar dit dek net prosesse wat die platform kan toeskryf. ’n Hulpverwerker, ’n ingebedde blaaier of ’n diens wat sy eie verbinding open, erwe moontlik nie die binding wat jy aanvaar het nie.

Geen van die twee benaderings oorleef ’n name-gebaseerde beleid sonder hulp nie. Adresse vir groot werwe roteer oor inhoudsnetwerke, so om ’n hostnaam aan ’n paar prefikse vas te pen, produseer ’n reël wat stilweg ophoor pas. ’n Beleid wat name moet volg, het ’n resolver-bewuste komponent nodig eerder as ’n statiese roete.

DNS en die noodskakelaar volg hul eie reëls

Naamoplossing is ’n aparte besluit van pakkie-routering, en ’n split-tonnel wil gewoonlik twee resolvers hê: die maatskappy s’n vir interne name, die plaaslike een vir alles anders. Die kliënt kan per-interface DNS-instellings installeer, navrae aan ’n stub-resolver gee of die stelselstandaard onaangeraak laat. ’n Blaaier met sy eie geënkripteerde resolver omseil al drie reëlings. Toets ’n opsoek eerder as om te aanvaar dat die resolver die roete gevolg het.

’n Noodskakelaar voeg ’n filter bo-op, en daardie filter onderskei nie altyd ’n beoogde uitsluiting van ’n toevallige lek nie. Sommige kliënte blokkeer alles buite die tonnel, terwyl ander die uitsluitings toelaat wat die beleid verklaar, so lees watter gedrag joune implementeer voordat jy op enige van die twee vertrou.

Kontroleer die splitsing van beide kante

Toets die ingeslote pad en die uitgeslote pad afsonderlik, en beoordeel die resultaat aan die interface-naam eerder as aan ’n publieke adres. Hierdie opdragte aanvaar ’n Linux-gasheer met die tonneltoestel reeds op. Vervang 203.0.113.10 met ’n bestemming wat jou beleid binne roeteer, en 198.51.100.25 met een wat dit buite stuur.

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 die eerste twee antwoorde saam, want die interface wat in elkeen genoem word, wys of die splitsing daardie bestemming op die tonnel geplaas het. Die resolver-navraag wys watter bediener die interne naam beantwoord het, en die laaste opdrag bewys dat die tonneltoestel enige versoek kan dra. ’n Mislukking op die tweede reël terwyl die eerste slaag, beteken die beleid doen presies wat hom gesê is.

Herhaal die stel ná ’n heropverbinding en ná ’n netwerkverandering. Huurhernuwing en interface-wisseling is waar ’n splitsing ophoor om by die bedoeling te pas waarvoor dit gebou is, en ’n gestoorde uitset van elke lopie maak die afwyking duidelik.