App-baseret vs destinationsbaseret split tunneling: hvilken skal du vælge

App-baseret og destinationsbaseret split tunneling er ikke to indstillinger til samme opgave. Den ene spørger, hvilken proces der sender en pakke; den anden spørger, hvor pakken er på vej hen. En regel bygget til det første spørgsmål fejler lydløst, når trafikken kommer fra en hjælpeproces, og en regel bygget til det andet fejler, når et værtsnavn opløses til en adresse, du aldrig har angivet. Vælg det objekt, der matcher kravet, og bevis det med to testpakker: én der skal bruge tunnelen, og én der ikke må.

De to regler virker på forskellige lag

En appregel håndhæves over netværkslaget, mod den identitet som styresystemet tildeler afsenderen. På Android er det UID'en bag en pakke, og VPN-tjenesten afgør pr. UID, om trafikken kommer ind i tunnelen. Der spørges ikke til destinationen, så den valgte app kan nå alt, og ingen anden app kan nå det interne netværk.

En destinationsregel håndhæves på selve pakken. Tunelgrænsefladen ejer et sæt præfikser, rutetabellen sender matchende trafik derind, og den sendende proces er irrelevant. Derfor dækker en destinationsregel en tjeneste, en printer eller et batchjob, som ingen huskede at angive, og derfor kan den ikke udtrykkes som netop dette program på en platform, hvis klient aldrig ser på processen.

Appregler passer til mobile klienter og administrerede agenter

Android viser valget direkte: VpnService.Builder.addAllowedApplication() og addDisallowedApplication() tager pakkenavne og håndhæver beslutningen pr. UID, som beskrevet i Androids VPN-udviklervejledning. iOS har en tilsvarende mulighed via VPN-regler pr. app baseret på bundle-id'er, som normalt leveres af en MDM-profil i stedet for at blive skrevet i hånden.

Skrivebordsklienter er det svage punkt. De fleste Windows- og macOS-VPN-klienter ruter efter destination og tilbyder slet ingen vælger pr. proces, fordi tunneldriveren ser pakker, ikke processer. Hvis din plan afhænger af at tunele én applikation på en bærbar, så undersøg klientens faktiske muligheder, før du designer omkring det; du vælger måske mellem en destinationsliste og en ekstra maskine.

En følge, folk overser: du kan ikke efterligne en appregel med ruter på de platforme. Tilføjer du en værtsrute til appens server, sendes alles trafik til den server gennem tunnelen, inklusive browseren og opdateringsprogrammet.

Destinationsregler passer til subnetlister og webstedsadgang

WireGuard gør modellen eksplicit. AllowedIPs er kryptonøgle-routing: en indre pakke, hvis destination ligger i en peers liste, krypteres til den peer, og alt andet forlader nettet ukrypteret ad den normale vej. Der er ingen proces at navngive og ingen uklarhed om, hvad der er inkluderet.

OpenVPN når samme sted via den skubbede rutetabel. route-nopull forhindrer serveren i at diktere ruter, hvorefter en klient-side route 10.20.0.0 255.255.0.0 vpn_gateway dækker præcis kontorpræfikset. IPv6 er en separat sætning i hver af disse klienter, og at glemme den er den mest almindelige måde at lække uden om et korrekt udseende IPv4-split.

Et værtsnavn er ikke en rute. Hvis profilen tilbyder et domænefelt, skal du behandle det som et navn, klienten opløser én gang, ikke som et permanent adresseområde; content delivery-netværk og load balancere udleverer andre adresser i morgen.

Hvor begge modeller bryder: hjælpere, delte tjenester, resolvere

Hjælpeprocesser bryder appregler på en måde, der ligner en serverfejl. En browsers opdateringsprogram, en crash-rapportering, en synkroniseringstjeneste, der kører som SYSTEM, og en WebView indlejret i en anden pakke er alle separate identiteter, så hvis du tuneler browseren, kan den faktiske anmodning ende uden for tunnelen. Det omvendte er lige så forvirrende: en udelukket app, der kalder et delt bibliotek inde i en tuneleret proces, har stadig sin trafik gennem tunnelen.

Destinationsregler bryder på delte tjenester og på navne. Filshares, printere, intern DNS og licensserveren ligger alle på adresser, så en enkeltapp-tunnel giver browseren adgang, mens det mappede drev forbliver dødt. Den forskel i dækning er ikke en fejl i nogen af modellerne, men det er grunden til, at en enkeltapp-tunnel så ofte giver at VPN'et er oppe, og sharen er væk.

Resolvere skærer gennem begge. Hvis klienten sætter interne DNS-servere, men styresystemet bruger DNS over HTTPS til en offentlig resolver, kommer svaret udefra tunnelen, og destinationsreglen matcher måske aldrig. Undersøg, hvilken resolver der faktisk svarede, før du konkluderer, at reglen er forkert, og bekræft på klientsiden, om den overhovedet installerede tunnel-resolveren. Et split, der lader DNS ligge uden for tunnelen, ser perfekt ud i rutetabellen og fejler stadig på hvert internt navn.

Arbejdsgang: vælg, anvend, verificer

Start med kravet, ikke med menuen. Hvis målet er kun denne app må bruge tunnelen, har du brug for appregler og en platform, der understøtter dem. Hvis målet er disse netværk er tilgængelige gennem tunnelen, har du brug for præfikser. Hvis svaret er begge, skal du implementere dem som to separate kontroller og skrive ned, hvilken der ejer hvilken fejl.

Anvend den snævrest form, du kan udtrykke, og verificer derefter ved at spørge 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 linjer navngiver den grænseflade, en rigtig destination ville bruge; wg show udskriver den konfigurerede præfikseliste; på Windows svarer Find-NetRoute på det samme spørgsmål, som stakken svarer på, når pakken sendes. Hvis grænsefladen er tunnelen, matchede reglen.

Test derefter en anden pakke, der bør udelukkes, fra en anden applikation, til samme destination. Notér klientversion, regeltype, præfikselisten eller pakkelisten og de to observerede resultater i sagen. Det par af resultater er det, der fortæller den næste ingeniør, om politikken er konfigureret forkert, eller trafikken aldrig hørte til den.