Kill switch per app versus vergrendeling van het hele apparaat: wat verandert

Een kill switch per app klinkt als de voorzichtige keuze: alleen de werkclient verliest zijn netwerk wanneer de tunnel wegvalt, en al het andere blijft werken. Dan merkt iemand dat de persoonlijke browser toch een pagina laadde, dat de synchronisatiehulp uit hetzelfde pakket bleef proberen, en dat een gecachte naam nog steeds werd omgezet naar een adres dat de tunnel nooit raakte. Het label op de functie en de set verbindingen die hij werkelijk beschermt, zijn twee verschillende dingen. Bepaal eerst de beschermde set, want die set bepaalt of handhaving per app of een apparaatbrede vergrendeling de eerlijke beschrijving is.

Begin met de set, niet met het label

Een beleid per app beschermt geselecteerde applicaties. Een apparaatvergrendeling richt zich op een bredere netwerkgrens, meestal met gedocumenteerde uitzonderingen voor lokaal printen, beheerverkeer of captive portals. Geen van beide labels is compleet voordat u drie vragen kunt beantwoorden: wat er met uitgesloten apps gebeurt, wat er gebeurt met hulpen die die apps starten, en wat er gebeurt met verbindingen die worden geopend terwijl bescherming niet beschikbaar is.

Schrijf die antwoorden op voordat u een clientinstelling aanraakt. Als de eis is "deze loonclient mag nooit buiten de tunnel met internet praten, en mijn browser mag dat wel", is de set klein en past handhaving per app. Als de eis is "niets op dit apparaat bereikt internet zonder bescherming, behalve de updatedienst", levert geen enkel beleid per app dat, omdat de apps die u niet noemde het probleem zijn.

Handhaving per app koppelt identificaties, niet programmanamen

Android stelt VPN per app beschikbaar via pakketten, en de VpnService-documentatie beschrijft hoe dat samengaat met altijd-aan-werking en blokkering. iOS configureert VPN per app via een beheerprofiel en koppelt op app of op domein. Windows en Linux hebben helemaal geen route per proces, dus hetzelfde idee wordt benaderd met een firewallregel die tot een programma beperkt is of met een regel die op de eigenaar-gebruiker past.

De grens is de identificatie, en identificaties zijn makkelijk te omzeilen. Een applicatie die een URL aan de systeembrowser geeft, of een document in een viewer opent, stapt over naar een proces dat uw beleid nooit noemde. Een optie om te beëindigen bij wegvallen is ook geen packetfilter: hij doodt de app die u hebt geconfigureerd, terwijl een kindproces, een wachtrijwerker of een browsertab een bestaande socket in leven kan houden.

Vergrendeling dekt wat een beleid per app niet kan zien

Een apparaatbrede vergrendeling neemt de keuze weg. Elk uitgaand pakket dat niet bij de tunnel hoort, wordt weggegooid, inclusief verkeer van processen waarvan uw app-beleid nooit wist. Op Android is dat altijd-aan-VPN in combinatie met de instelling die verbindingen blokkeert, en de handhaving gebeurt in het systeem, niet in het clientvenster. Op een desktop is het een blijvende firewallregel of een standaardroute naar een onbereikbare gateway.

De prijs is dat al het andere stopt, dus de uitzonderingen worden deel van het ontwerp in plaats van een gedachte achteraf. Lokale printers, servicedetectie, inloggen op captive portals, beheeragenten en OS-updates hebben elk een gedocumenteerd gat nodig, omdat elk een pad is dat open blijft wanneer de tunnel plat ligt. De vergrendeling is slechts zo sterk als de kortste vermelding op die lijst.

DNS, IPv6 en achtergrondhulpen verbergen de lekken

Dat een beschermde app een naam niet kan omzetten, bewijst niet dat gecachte antwoorden of direct IP-verkeer geblokkeerd zijn. Als de resolver buiten de tunnel nog bereikbaar is, wordt de naam omgezet en mislukt de verbinding, wat op een werkende kill switch lijkt en het niet is. Erger nog: een gecachet record kan naar een adres wijzen dat de tunnel niet draagt, zodat de verbinding direct naar buiten gaat terwijl de app een VPN-fout meldt.

IPv6 heeft op elk platform dat het draait een eigen regel nodig, omdat een dropregel voor v4 geen v6-route dekt. Op mobiel kan een instelling voor privé-DNS de omzetting naar een versleuteld kanaal verplaatsen dat het apparaatbeleid niet inspecteert. En achtergrondhulpen zijn op de desktop de gebruikelijke schuldige: een updater- of synchronisatieproces in de systeemvak start vóór de VPN-client en houdt zijn eigen verbinding, dus het ziet de gewijzigde route nooit.

Test drie apps en twee overgangen

Voer elke rij twee keer uit, één keer met een hostnaam en één keer met een letterlijk adres, en nog één keer via IPv6 als het netwerk dat biedt. Een pass betekent dat de inbegrepen app stopte, de uitgesloten app zich gedroeg zoals u opschreef, en de hulp niet ontsnapte. Leg het directe gedrag vast dat u aanvaardbaar vond, zodat de volgende beheerder een bewuste uitzondering van een storing kan onderscheiden.

Beschrijf daarna het resultaat in één zin die de apps en de voorwaarden noemt, bijvoorbeeld: de loonclient heeft geen route buiten de tunnel, de browser is bewust direct, en al het andere stopt wanneer de tunnel plat ligt. Als die zin moeilijk te schrijven is, is het beleid nog steeds twee beleidsregels die met elkaar worstelen.