Split tunneling op basis van app of bestemming: welke kiezen

Split tunneling op basis van app en op basis van bestemming zijn geen twee instellingen voor dezelfde taak. De ene vraagt welk proces een pakket verstuurt; de andere vraagt waar dat pakket naartoe gaat. Een regel die voor de eerste vraag is gebouwd, faalt stil wanneer het verkeer van een hulpproces komt, en een regel voor de tweede faalt wanneer een hostnaam wordt omgezet naar een adres dat u nooit hebt opgenomen. Kies het object dat bij de eis past en bewijs het met twee testpakketten: een dat de tunnel moet gebruiken en een dat dat niet mag.

De twee regels grijpen op verschillende lagen aan

Een appregel wordt boven de netwerklaag afgedwongen, tegen de identiteit die het besturingssysteem aan de afzender geeft. Op Android is dat de UID achter een pakket, en de VPN-dienst beslist per UID of verkeer de tunnel in gaat. Er wordt niets over de bestemming gevraagd, dus de gekozen app kan alles bereiken en geen enkele andere app kan het interne netwerk bereiken.

Een bestemmingsregel wordt op het pakket zelf afgedwongen. De tunnelinterface bezit een reeks prefixen, de routingtabel stuurt overeenkomend verkeer erin, en het verzendende proces is irrelevant. Daarom dekt een bestemmingsregel een dienst, een printer of een batchtaak die niemand had opgenomen, en daarom kan die niet als precies dit programma worden uitgedrukt op een platform waarvan de client nooit naar het proces kijkt.

Appregels passen bij mobiele clients en beheerde agents

Android biedt de keuze direct aan: VpnService.Builder.addAllowedApplication() en addDisallowedApplication() nemen pakketnamen en dwingen de beslissing per UID af, zoals beschreven in de VPN-ontwikkelaarsgids van Android. iOS heeft een equivalent via VPN-regels per app op basis van bundel-identificaties, meestal geleverd via een MDM-profiel in plaats van met de hand getypt.

Desktopclients zijn het zwakke punt. De meeste Windows- en macOS-VPN-clients routeren op bestemming en bieden helemaal geen selectie per proces, omdat het tunnelstuurprogramma pakketten ziet, geen processen. Als uw plan afhangt van het tunnelen van één applicatie op een laptop, controleer dan de werkelijke mogelijkheden van de client voordat u daaromheen ontwerpt; misschien kiest u tussen een bestemmingslijst en een tweede machine.

Een gevolg dat mensen missen: op die platforms kunt u een appregel niet met routes nabootsen. Een hostroute voor de server van de app toevoegen tunnelt het verkeer van iedereen naar die server, inclusief de browser en de updater.

Bestemmingsregels passen bij subnetlijsten en bereikbaarheid van sites

WireGuard maakt het model expliciet. AllowedIPs is cryptosleutelroutering: een innerlijk pakket waarvan de bestemming binnen de lijst van een peer valt, wordt naar die peer versleuteld, en al het andere verlaat het netwerk onversleuteld via het normale pad. Er is geen proces te benoemen en geen onduidelijkheid over wat is inbegrepen.

OpenVPN bereikt dezelfde plek via de geduwde routingtabel. route-nopull verhindert dat de server routes dicteert, waarna een client-side route 10.20.0.0 255.255.0.0 vpn_gateway precies het kantoorprefix dekt. IPv6 is in elk van deze clients een aparte instructie, en het vergeten daarvan is de meest voorkomende manier om te lekken rond een correct uitziende IPv4-split.

Een hostnaam is geen route. Als het profiel een domeinveld biedt, behandel het dan als een naam die de client één keer oplost, niet als een permanent adresbereik; content delivery-netwerken en load balancers geven morgen andere adressen.

Waar beide modellen breken: hulpprogramma's, gedeelde diensten, resolvers

Hulpprocessen breken appregels op een manier die op een serverfout lijkt. De updater van een browser, een crashrapporteur, een synchronisatiedienst die als SYSTEM draait en een WebView die in een ander pakket is ingebed, zijn allemaal afzonderlijke identiteiten, dus het tunnelen van de browser kan het werkelijke verzoek buiten de tunnel laten. Het omgekeerde is net zo verwarrend: een uitgesloten app die een gedeelde bibliotheek binnen een getunnelde proces aanroept, heeft zijn verkeer nog steeds door de tunnel.

Bestemmingsregels breken op gedeelde diensten en op namen. Bestandsshares, printers, interne DNS en de licentieserver leven allemaal op adressen, dus een tunnel voor één app geeft de browser toegang terwijl de gekoppelde schijf dood blijft. Dat verschil in dekking is geen fout in een van beide modellen, maar het is de reden dat een tunnel voor één app zo vaak oplevert dat de VPN aan staat en de share weg is.

Resolvers snijden door beide. Als de client interne DNS-servers instelt maar het besturingssysteem DNS over HTTPS naar een publieke resolver gebruikt, komt het antwoord van buiten de tunnel en past de bestemmingsregel misschien nooit. Controleer welke resolver daadwerkelijk antwoordde voordat u concludeert dat de regel fout is, en bevestig aan de clientkant of die de tunnelresolver überhaupt heeft geïnstalleerd. Een split die DNS buiten de tunnel laat, ziet er in de routingtabel perfect uit en faalt toch op elke interne naam.

Draaiboek: kiezen, toepassen, verifiëren

Begin bij de eis, niet bij het menu. Als het doel is dat alleen deze app de tunnel mag gebruiken, hebt u appregels en een platform nodig dat die ondersteunt. Als het doel is dat deze netwerken via de tunnel bereikbaar zijn, hebt u prefixen nodig. Als het antwoord beide is, implementeer ze dan als twee afzonderlijke besturingen en noteer welke welke fout bezit.

Pas de smalste vorm toe die u kunt uitdrukken en verifieer daarna door de routingtabel te vragen in plaats van het statuspictogram van de client:

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 eerste twee regels benoemen de interface die een echte bestemming zou gebruiken; wg show drukt de geconfigureerde prefixlijst af; op Windows beantwoordt Find-NetRoute dezelfde vraag die de stack beantwoordt wanneer het pakket wordt verzonden. Als de interface de tunnel is, heeft de regel gematcht.

Test daarna een tweede pakket dat zou moeten worden uitgesloten, vanuit een andere applicatie, naar dezelfde bestemming. Noteer in het ticket de clientversie, het regeltype, de prefix- of pakketlijst en de twee waargenomen resultaten. Dat paar resultaten is wat de volgende engineer vertelt of het beleid verkeerd is geconfigureerd of dat het verkeer er nooit bij hoorde.