Appbaserad eller destinationsbaserad split tunneling: vilken ska du välja

Appbaserad och destinationsbaserad split tunneling är inte två inställningar för samma uppgift. Den ena frågar vilken process som skickar ett paket; den andra frågar vart paketet är på väg. En regel byggd för den första frågan misslyckas tyst när trafiken kommer från en hjälpprocess, och en regel byggd för den andra misslyckas när ett värdnamn löses upp till en adress du aldrig listade. Välj det objekt som matchar kravet och bevisa det med två testpaket: ett som måste använda tunneln och ett som inte får.

De två reglerna träffar på olika lager

En appregel tillämpas ovanför nätverkslagret, mot den identitet som operativsystemet ger avsändaren. På Android är det UID:n bakom ett paket, och VPN-tjänsten avgör per UID om trafiken går in i tunneln. Ingenting om destinationen frågas, så den valda appen kan nå allt och ingen annan app kan nå det interna nätet.

En destinationsregel tillämpas på själva paketet. Tunnelgränssnittet äger en uppsättning prefix, routingtabellen skickar matchande trafik dit, och den skickande processen är irrelevant. Därför täcker en destinationsregel en tjänst, en skrivare eller ett batchjobb som ingen kom ihåg att lista, och därför kan den inte uttryckas som just detta program på en plattform vars klient aldrig tittar på processen.

Appregler passar mobila klienter och hanterade agenter

Android visar valet direkt: VpnService.Builder.addAllowedApplication() och addDisallowedApplication() tar paketnamn och verkställer beslutet per UID, som beskrivs i Androids VPN-utvecklarguide. iOS har en motsvarighet via VPN-regler per app baserade på bundle-identifierare, vanligen levererade av en MDM-profil i stället för skrivna för hand.

Skrivbordsklienter är den svaga punkten. De flesta VPN-klienter för Windows och macOS routar efter destination och erbjuder ingen väljare per process alls, eftersom tunneldrivrutinen ser paket, inte processer. Om din plan bygger på att tunna en enda applikation på en bärbar dator, kontrollera klientens faktiska förmåga innan du designar runt det; du väljer kanske mellan en destinationslista och en andra maskin.

En följd som folk missar: på dessa plattformar kan du inte imitera en appregel med rutter. Lägger du till en värdrutt för appens server tunnlas allas trafik till den servern, inklusive webbläsaren och uppdateringsprogrammet.

Destinationsregler passar subnätlistor och nåbarhet till webbplatser

WireGuard gör modellen explicit. AllowedIPs är kryptonyckelrouting: ett inre paket vars destination faller inom en peers lista krypteras till den peeren, och allt annat lämnar nätet okrypterat via den normala vägen. Det finns ingen process att namnge och ingen oklarhet om vad som ingår.

OpenVPN når samma plats via den pushade routingtabellen. route-nopull hindrar servern från att diktera rutter, och därefter täcker en klientsidig route 10.20.0.0 255.255.0.0 vpn_gateway exakt kontorsprefixet. IPv6 är ett eget uttalande i var och en av dessa klienter, och att glömma det är det vanligaste sättet att läcka runt en korrekt utseende IPv4-split.

Ett värdnamn är inte en rutt. Om profilen erbjuder ett domänfält, behandla det som ett namn klienten löser upp en gång, inte som ett permanent adressområde; content delivery-nätverk och lastbalanserare ger andra adresser i morgon.

Där båda modellerna brister: hjälpprocesser, delade tjänster, resolvers

Hjälpprocesser bryter appregler på ett sätt som ser ut som ett serverfel. En webbläsares uppdateringsprogram, en kraschrapportör, en synkroniseringstjänst som körs som SYSTEM och en WebView inbäddad i ett annat paket är alla separata identiteter, så att tunna webbläsaren kan lämna den faktiska begäran utanför tunneln. Det omvända är lika förvirrande: en exkluderad app som anropar ett delat bibliotek inne i en tunnlad process får fortfarande sin trafik genom tunneln.

Destinationsregler brister på delade tjänster och på namn. Filresurser, skrivare, intern DNS och licensservern ligger alla på adresser, så en enappstunnel ger webbläsaren åtkomst medan den mappade enheten förblir död. Den skillnaden i täckning är inte en bugg i någon av modellerna, men det är anledningen till att en enappstunnel så ofta ger att VPN:en är uppe och resursen är borta.

Resolvers skär genom båda. Om klienten ställer in interna DNS-servrar men operativsystemet använder DNS över HTTPS mot en offentlig resolver, kommer svaret utanför tunneln och destinationsregeln kanske aldrig matchar. Kontrollera vilken resolver som faktiskt svarade innan du drar slutsatsen att regeln är fel, och bekräfta på klientsidan om den ens installerade tunnelresolvern. En split som lämnar DNS utanför tunneln ser perfekt ut i routingtabellen och misslyckas ändå på varje internt namn.

Arbetsgång: välj, tillämpa, verifiera

Börja med kravet, inte med menyn. Om målet är att bara denna app får använda tunneln behöver du appregler och en plattform som stöder dem. Om målet är att dessa nät är nåbara genom tunneln behöver du prefix. Om svaret är båda, implementera dem som två separata kontroller och skriv ned vilken som äger vilket fel.

Tillämpa den smalaste form du kan uttrycka och verifiera sedan genom att fråga routingtabellen i stället för 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 två första raderna namnger det gränssnitt en verklig destination skulle använda; wg show skriver ut den konfigurerade prefixlistan; på Windows svarar Find-NetRoute på samma fråga som stacken svarar på när paketet skickas. Om gränssnittet är tunneln träffade regeln.

Testa sedan ett andra paket som borde uteslutas, från en annan applikation, till samma destination. Notera klientversionen, regeltypen, prefixlistan eller paketlistan och de två observerade resultaten i ärendet. Det paret resultat är det som berättar för nästa ingenjör om policyn är felkonfigurerad eller om trafiken aldrig hörde dit.