Appbasert vs. destinasjonsbasert split tunneling: kva du bør velje

Appbasert og destinasjonsbasert split tunneling er ikkje to innstillingar for same oppgåva. Den eine spør kva prosess som sender ei pakke; den andre spør kvar pakka er på veg. Ein regel bygd for det første spørsmålet sviktar stille når trafikken kjem frå ein hjelpeprosess, og ein regel bygd for det andre sviktar når eit vertsnamn blir løyst til ei adresse du aldri lista opp. Vel objektet som passar kravet, og prov det med to testpakkar: éin som må bruke tunnelen og éin som ikkje må.

Dei to reglane treff på ulike lag

Ein appregel blir handheva over nettverkslaget, mot identiteten operativsystemet gjev avsendaren. På Android er det UID-en bak ei pakke, og VPN-tenesta avgjer per UID om trafikken går inn i tunnelen. Ingenting om destinasjonen blir spurt om, så den valde appen kan nå alt, og ingen annan app kan nå det interne nettverket.

Ein destinasjonsregel blir handheva på sjølve pakka. Tunnelflata eig eit sett med prefiks, rutetabellen sender samsvarande trafikk inn i han, og prosessen som sender er irrelevant. Difor dekkjer ein destinasjonsregel ei teneste, ein skrivar eller ein batchjobb ingen hugska å liste opp, og difor kan han ikkje uttrykkjast som akkurat dette programmet på ein plattform der klienten aldri ser på prosessen.

Appreglar passar for mobile klientar og styrte agentar

Android viser valet direkte: VpnService.Builder.addAllowedApplication() og addDisallowedApplication() tek pakkenamn og handhevar avgjerda per UID, som skildra i VPN-utviklarrettleiinga til Android. iOS har ein ekvivalent via VPN-reglar per app basert på bundle-identifikatorar, vanlegvis levert av ein MDM-profil i staden for skriven for hand.

Skrivebordsklientar er det svake punktet. Dei fleste Windows- og macOS-VPN-klientar rutar etter destinasjon og tilbyr ingen veljar per prosess i det heile, fordi tunneldrivaren ser pakkar, ikkje prosessar. Viss planen din er avhengig av å tunele éin applikasjon på ein berbar PC, sjekk dei faktiske evnene til klienten før du designar rundt det; du vel kanskje mellom ei destinasjonsliste og ein ekstra maskin.

Ei følgje folk overser: du kan ikkje etterlikne ein appregel med ruter på desse plattformene. Legg du til ei vertsrute for tenaren til appen, blir all trafikk send gjennom tunnelen til den tenaren, inkludert nettlesaren og oppdateringsprogrammet.

Destinasjonsreglar passar for subnettlister og nåbarheit til nettstader

WireGuard gjer modellen eksplisitt. AllowedIPs er kryptonøkkelrutting: ei indre pakke der destinasjonen fell innanfor lista til ein peer blir kryptert til den peeren, og alt anna forlèt nettet ukryptert via vanleg veg. Det er ingen prosess å namngje og inga uklårheit om kva som er inkludert.

OpenVPN når same stad via den dytta rutetabellen. route-nopull hindrar tenaren i å diktere ruter, og deretter dekkjer ein klientside-route 10.20.0.0 255.255.0.0 vpn_gateway nøyaktig kontorprefikset. IPv6 er ei eiga setning i kvar av desse klientane, og å gløyme henne er den vanlegaste måten å lekkje rundt ein riktig utsjåande IPv4-splitt.

Eit vertsnamn er ikkje ei rute. Viss profilen tilbyr eit domenefelt, handsam det som eit namn klienten løyser éin gong, ikkje som eit permanent adresseområde; innhaldsleveringsnettverk og lastbalansarar gjev andre adresser i morgon.

Der begge modellane bryt: hjelparar, delte tenester, løysarar

Hjelpeprosessar bryt appreglar på ein måte som ser ut som ein tenarfeil. Oppdateringsprogrammet til ein nettlesar, ein krasjrapportør, ei synkroniseringsteneste som køyrer som SYSTEM og ein WebView innebygd i ein annan pakke er alle separate identitetar, så å tunele nettlesaren kan la den faktiske førespurnaden bli ståande utanfor tunnelen. Det motsette er like forvirrande: ein ekskludert app som kallar eit delt bibliotek inne i ein tunellert prosess får framleis trafikken gjennom tunnelen.

Destinasjonsreglar bryt på delte tenester og på namn. Filutdelingar, skrivarar, intern DNS og lisens-tenaren ligg alle på adresser, så ein einappstunnel gjev nettlesaren tilgang medan den tilkopla disken blir ståande død. Den skilnaden i dekning er ikkje ein feil i nokon av modellane, men det er grunnen til at ein einappstunnel så ofte gjev at VPN-en er oppe og utdelinga er borte.

Løysarar skjer gjennom begge. Viss klienten set interne DNS-tenarar, men operativsystemet brukar DNS over HTTPS mot ein offentleg løysar, kjem svaret utanfrå tunnelen, og destinasjonsregelen treff kanskje aldri. Sjekk kva løysar som faktisk svara før du konkluderer med at regelen er feil, og stadfest på klientsida om han i det heile installerte tunnelløysaren. Ein splitt som lèt DNS liggje utanfor tunnelen ser perfekt ut i rutetabellen og feilar likevel på kvart internt namn.

Framgangsmåte: vel, bruk, stadfest

Start med kravet, ikkje med menyen. Viss målet er at berre denne appen kan bruke tunnelen, treng du appreglar og ein plattform som støttar dei. Viss målet er at desse netta er nåbare gjennom tunnelen, treng du prefiks. Viss svaret er begge, implementer dei som to separate kontrollar og skriv ned kven som eig kva feil.

Bruk den smalaste forma du kan uttrykkje, og stadfest deretter ved å spørje rutetabellen i staden for statusikonet til klienten:

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

Dei to første linjene namngjev grensesnittet ein reell destinasjon ville bruke; wg show skriv ut den konfigurerte prefikslista; på Windows svarar Find-NetRoute på det same spørsmålet stakken vil svare på når pakka blir send. Viss grensesnittet er tunnelen, treff regelen.

Test deretter ei andre pakke som bør utelukkast, frå ein annan applikasjon, til same destinasjon. Noter klientversjonen, regeltypen, prefikslista eller pakkelista og dei to observerte resultata i saka. Det paret med resultat er det som fortel neste ingeniør om policyen er feilkonfigurert eller trafikken aldri høyrde til han.