Appbasert vs. destinasjonsbasert split tunneling: hva du bør velge

Appbasert og destinasjonsbasert split tunneling er ikke to innstillinger for samme oppgave. Den ene spør hvilken prosess som sender en pakke; den andre spør hvor pakken er på vei. En regel bygget for det første spørsmålet svikter stille når trafikken kommer fra en hjelpeprosess, og en regel bygget for det andre svikter når et vertsnavn løses til en adresse du aldri listet opp. Velg objektet som passer kravet, og bevis det med to testpakker: én som må bruke tunnelen og én som ikke må.

De to reglene treffer på ulike lag

En appregel håndheves over nettverkslaget, mot identiteten operativsystemet gir avsenderen. På Android er det UID-en bak en pakke, og VPN-tjenesten avgjør per UID om trafikken går inn i tunnelen. Ingenting om destinasjonen spørres, så den valgte appen kan nå alt, og ingen annen app kan nå det interne nettverket.

En destinasjonsregel håndheves på selve pakken. Tunnelflaten eier et sett med prefikser, rutetabellen sender samsvarende trafikk inn i den, og prosessen som sender er irrelevant. Derfor dekker en destinasjonsregel en tjeneste, en skriver eller en batchjobb ingen husket å liste opp, og derfor kan den ikke uttrykkes som akkurat dette programmet på en plattform der klienten aldri ser på prosessen.

Appregler passer for mobile klienter og styrte agenter

Android viser valget direkte: VpnService.Builder.addAllowedApplication() og addDisallowedApplication() tar pakkenavn og håndhever avgjørelsen per UID, som beskrevet i Androids VPN-utviklerveiledning. iOS har en ekvivalent via VPN-regler per app basert på bundle-identifikatorer, vanligvis levert av en MDM-profil i stedet for skrevet for hånd.

Skrivebordsklienter er det svake punktet. De fleste Windows- og macOS-VPN-klienter ruter etter destinasjon og tilbyr ingen velger per prosess i det hele tatt, fordi tunneldriveren ser pakker, ikke prosesser. Hvis planen din avhenger av å tunele én applikasjon på en bærbar PC, sjekk klientens faktiske evner før du designer rundt det; du velger kanskje mellom en destinasjonsliste og en ekstra maskin.

En følge folk overser: du kan ikke etterligne en appregel med ruter på disse plattformene. Legger du til en vertsrute for appens server, sendes alles trafikk til den serveren gjennom tunnelen, inkludert nettleseren og oppdateringsprogrammet.

Destinasjonsregler passer for subnettlister og nåbarhet til nettsteder

WireGuard gjør modellen eksplisitt. AllowedIPs er kryptonøkkelrutting: en indre pakke hvis destinasjon faller innenfor en peers liste krypteres til den peeren, og alt annet forlater nettet ukryptert via normal vei. Det er ingen prosess å navngi og ingen uklarhet om hva som er inkludert.

OpenVPN når samme sted via den dyttede rutetabellen. route-nopull hindrer serveren i å diktere ruter, og deretter dekker en klientside-route 10.20.0.0 255.255.0.0 vpn_gateway nøyaktig kontorprefikset. IPv6 er en egen setning i hver av disse klientene, og å glemme den er den vanligste måten å lekke rundt en riktig utseende IPv4-splitt.

Et vertsnavn er ikke en rute. Hvis profilen tilbyr et domene felt, behandle det som et navn klienten løser én gang, ikke som et permanent adresseområde; innholdsleveringsnettverk og lastbalanserere gir andre adresser i morgen.

Der begge modellene bryter: hjelpere, delte tjenester, løsere

Hjelpeprosesser bryter appregler på en måte som ser ut som en serverfeil. En nettlesers oppdateringsprogram, en krasjrapportør, en synkroniseringstjeneste som kjører som SYSTEM og en WebView innebygd i en annen pakke er alle separate identiteter, så å tunele nettleseren kan la den faktiske forespørselen bli stående utenfor tunnelen. Det motsatte er like forvirrende: en ekskludert app som kaller et delt bibliotek inne i en tunelert prosess får fortsatt trafikken gjennom tunnelen.

Destinasjonsregler bryter på delte tjenester og på navn. Filutdelinger, skrivere, intern DNS og lisensserveren ligger alle på adresser, så en enappstunnel gir nettleseren tilgang mens den tilkoblede disken blir stående død. Den forskjellen i dekning er ikke en feil i noen av modellene, men det er grunnen til at en enappstunnel så ofte gir at VPN-en er oppe og utdelingen er borte.

Løsere skjærer gjennom begge. Hvis klienten setter interne DNS-servere, men operativsystemet bruker DNS over HTTPS mot en offentlig løser, kommer svaret utenfra tunnelen, og destinasjonsregelen treffer kanskje aldri. Sjekk hvilken løser som faktisk svarte før du konkluderer med at regelen er feil, og bekreft på klientsiden om den i det hele tatt installerte tunnelløseren. En splitt som lar DNS ligge utenfor tunnelen ser perfekt ut i rutetabellen og feiler likevel på hvert internt navn.

Fremgangsmåte: velg, bruk, verifiser

Start med kravet, ikke med menyen. Hvis målet er at bare denne appen kan bruke tunnelen, trenger du appregler og en plattform som støtter dem. Hvis målet er at disse nettene er nåbare gjennom tunnelen, trenger du prefikser. Hvis svaret er begge, implementer dem som to separate kontroller og skriv ned hvilken som eier hvilken feil.

Bruk den smaleste formen du kan uttrykke, og verifiser deretter ved å spørre rutetabellen i stedet for klientens statusikon:

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

De to første linjene navngir grensesnittet en reell destinasjon ville bruke; wg show skriver ut den konfigurerte prefikslisten; på Windows svarer Find-NetRoute på det samme spørsmålet stakken vil svare på når pakken sendes. Hvis grensesnittet er tunnelen, traff regelen.

Test deretter en andre pakke som bør utelukkes, fra en annen applikasjon, til samme destinasjon. Noter klientversjonen, regeltypen, prefikslisten eller pakkelisten og de to observerte resultatene i saken. Det paret med resultater er det som forteller neste ingeniør om policyen er feilkonfigurert eller trafikken aldri hørte til den.