Split tunneling eftir forriti eða eftir áfangastað: hvað á að velja

Split tunneling eftir forriti og eftir áfangastað eru ekki tvær stillingar fyrir sama verk. Önnur spyr hvaða ferli sendir pakkann; hin spyr hvert pakkinn er að fara. Regla sem byggð er fyrir fyrstu spurninguna bregst hljóðlaust þegar umferðin kemur frá hjálparferli, og regla fyrir hina bregst þegar hýsilnafn leysist í vistfang sem þú skráðir aldrei. Veldu hlutinn sem passar við kröfuna og sannaðu með tveimur prófunarpökkum: einn sem verður að nota göngin og einn sem má ekki.

Reglurnar tvær virka á mismunandi lögum

Regla fyrir forrit er framfylgt ofan við netlagið, gegn auðkenninu sem stýrikerfið gefur sendandanum. Á Android er það UID-ið bak við pakka, og VPN-þjónustan ákveður fyrir hvert UID hvort umferð fari inn í göngin. Ekkert er spurt um áfangastaðinn, svo valið forrit kemst að hverju sem er og ekkert annað forrit kemst að innra netinu.

Regla fyrir áfangastað er framfylgt á pakkann sjálfan. Gönguviðmótið á sér mengi forskeyta, leiðatöflunni sendir samsvarandi umferð þangað, og sendandi ferli skiptir ekki máli. Þess vegna nær regla fyrir áfangastað yfir þjónustu, prentara eða runuverk sem enginn mundi eftir að skrá, og þess vegna er ekki hægt að orða hana sem einmitt þetta forrit á vettvangi þar sem biðlarinn lítur aldrei á ferlið.

Reglur fyrir forrit henta farsímabiðlurum og stýrðum umboðum

Android sýnir valið beint: VpnService.Builder.addAllowedApplication() og addDisallowedApplication() taka pökkunöfn og framfylgja ákvörðuninni fyrir hvert UID, eins og lýst er í VPN-þróunarhandbók Android. iOS hefur samsvarandi fyrirkomulag í gegnum VPN-reglur fyrir hvert forrit sem byggjast á auðkennum pakka og eru venjulega afhentar með MDM-sniði frekar en slegnar inn handvirkt.

Skjáborðsbiðlarar eru veiki punkturinn. Flestir VPN-biðlarar fyrir Windows og macOS leiða eftir áfangastað og bjóða alls ekki upp á val fyrir hvert ferli, því akstursforrit ganganna sér pakka, ekki ferli. Ef áætlun þín byggist á að tunna einu forriti á fartölvu skaltu athuga raunverulega getu biðlarans áður en þú hannar í kringum hana; kannski ertu að velja milli lista yfir áfangastaði og seinni vélar.

Afleiðing sem fólk missir: þú getur ekki líkt eftir reglu fyrir forrit með leiðum á þessum vettvangi. Að bæta við hýsilleið fyrir þjón forritsins tunnar umferð allra til þess þjóns, þar á meðal vafrans og uppfærsluforritsins.

Reglur fyrir áfangastað henta undirnetslistum og aðgengi að svæðum

WireGuard gerir líkanið skýrt. AllowedIPs er dulritunarlyklaleiðsla: innri pakki sem áfangastaður hans fellur innan lista jafningja er dulritaður til þess jafningja, og allt annað fer ódulritað eftir venjulegu leiðinni. Það er ekkert ferli að nefna og engin óvissa um hvað er innifalið.

OpenVPN nær sama stað í gegnum ýttu leiðatöfluna. route-nopull kemur í veg fyrir að þjónninn boði leiðir, og eftir það nær biðlarahluta route 10.20.0.0 255.255.0.0 vpn_gateway nákvæmlega forskeyti skrifstofunnar. IPv6 er sérstök yfirlýsing í hverjum þessara biðlara, og að gleyma henni er algengasta leiðin til að leka í kringum rétt útlitandi IPv4-skiptingu.

Hýsilnafn er ekki leið. Ef sniðið býður upp á lénsreit skaltu meðhöndla hann sem nafn sem biðlarinn leysir einu sinni, ekki sem varanlegt vistfangabil; efnisveitunet og hleðslujafnarar gefa önnur vistföng á morgun.

Hvar bæði líkönin brotna: hjálparar, sameiginlegar þjónustur, leysarar

Hjálparferli brjóta reglur fyrir forrit á þann hátt að út lítur eins og þjónnbilun. Uppfærsluforrit vafra, hrunaskýrslur, samstillingarþjónusta sem keyrir sem SYSTEM og WebView innbyggt í annan pakka eru öll aðskilin auðkenni, svo að tunna vafrann getur skilið raunverulegu beiðnina utan ganganna. Hið gagnstæða er jafn ruglingslegt: útilokað forrit sem kallar á sameiginlegt safn inni í tunnuðu ferli fer samt um göngin.

Reglur fyrir áfangastað brotna á sameiginlegum þjónustum og á nöfnum. Skráardeilingar, prentarar, innra DNS og leyfisþjónninn lifa öll á vistföngum, svo göng fyrir eitt forrit veita vafranum aðgang á meðan varpaða drifið er dautt. Sá munur á umfangi er ekki galli í hvorugu líkaninu, en hann er ástæðan fyrir því að göng fyrir eitt forrit leiða svo oft af sér að VPN-ið er í gangi og deilingin er horfin.

Leysarar skera í gegnum bæði. Ef biðlarinn stillir innri DNS-þjóna en stýrikerfið notar DNS yfir HTTPS til opinbers leysara kemur svarið utan ganganna og reglan fyrir áfangastað passar kannski aldrei. Athugaðu hvaða leysari svaraði í raun áður en þú ályktar að reglan sé röng, og staðfestu hjá biðlaranum hvort hann setti leysara ganganna upp yfirhöfuð. Skipting sem skilur DNS utan ganganna lítur fullkomlega út í leiðatöflunni og bregst samt á hverju innra nafni.

Verkferill: velja, beita, staðfesta

Byrjaðu á kröfunni, ekki valmyndinni. Ef markmiðið er aðeins þetta forrit megi nota göngin þarftu reglur fyrir forrit og vettvang sem styður þær. Ef markmiðið er að þessi net séu aðgengileg í gegnum göngin þarftu forskeyti. Ef svarið er bæði skaltu útfæra þau sem tvær aðskildar stýringar og skrifa niður hvor á hvaða bilun.

Beittu því þrengsta formi sem þú getur orðað og staðfestu svo með því að spyrja leiðatöfluna frekar en stöðutákn biðlarans:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Fyrstu tvær línurnar nefna viðmótið sem raunverulegur áfangastaður myndi nota; wg show prentar stillta forskeytalistann; á Windows svarar Find-NetRoute sömu spurningu og staflinn svarar þegar pakkinn er sendur. Ef viðmótið er göngin passaði reglan.

Prófaðu svo annan pakka sem ætti að vera útilokaður, frá öðru forriti, á sama áfangastað. Skráðu í miðann biðlarautgáfu, tegund reglu, forskeyta- eða pakkalistann og tvær niðurstöðurnar sem sáust. Það par niðurstaðna segir næsta verkfræðingi hvort stefnan er rangt stillt eða hvort umferðin hafi aldrei átt við hana.