Kill switch per app kontra låsning av hela enheten: vad som förändras

En kill switch per app låter som det försiktiga valet: bara arbetsklienten förlorar sitt nätverk när tunneln faller, och allt annat fortsätter att fungera. Sedan upptäcker någon att den personliga webbläsaren ändå laddade en sida, att synkroniseringshjälparen som följde med samma paket fortsatte att försöka, och att ett cachelagrat namn fortfarande löstes upp till en adress som aldrig rörde tunneln. Etiketten på funktionen och den mängd anslutningar som den faktiskt skyddar är två olika saker. Bestäm den skyddade mängden först, eftersom den mängden avgör om tvingande per app eller en låsning av hela enheten är den ärliga beskrivningen.

Börja med mängden, inte etiketten

En policy per app skyddar utvalda program. En enhetslåsning siktar på en bredare nätverksgräns, vanligtvis med dokumenterade undantag för lokal utskrift, hanteringstrafik eller captive-portaler. Ingen av etiketterna är komplett förrän du kan svara på tre frågor: vad som händer med uteslutna appar, vad som händer med de hjälpare som apparna startar, och vad som händer med anslutningar som öppnas medan skyddet inte är tillgängligt.

Skriv ner svaren innan du rör en klientinställning. Om kravet är "den här löneklienten får aldrig prata med internet utanför tunneln, och min webbläsare får", är mängden liten och tvingande per app passar. Om kravet är "ingenting på den här enheten når internet utan skydd, utom uppdateringstjänsten", kommer ingen policy per app att producera det, eftersom apparna du inte namngav är problemet.

Tvingande per app matchar identifierare, inte programnamn

Android exponerar VPN per app via paket, och dess VpnService-dokumentation beskriver hur det samspelar med alltid-på-läge och blockering. iOS konfigurerar VPN per app via en hanteringsprofil och matchar efter app eller efter domän. Windows och Linux har ingen rutt per process alls, så samma idé närmas med en brandväggsregel som begränsas till ett program eller med en regel som matchar den ägande användaren.

Gränsen är identifieraren, och identifierare är lätta att kringgå. Ett program som lämnar en URL till systemwebbläsaren, eller öppnar ett dokument i en visare, går över till en process som din policy aldrig namngav. Ett alternativ att avsluta vid avbrott är inte heller ett paketfilter: det dödar appen du konfigurerade, medan en barnprocess, en köarbetare eller en webbläsarflik kan hålla en befintlig socket vid liv.

Låsningen täcker det en policy per app inte kan se

En låsning av hela enheten tar bort valet. Varje utgående paket som inte hör till tunneln släpps, inklusive trafik från processer som din app-policy aldrig kände till. På Android är det alltid-på-VPN kombinerat med inställningen som blockerar anslutningar, och tvingandet sker i systemet, inte i klientfönstret. På en dator är det en bestående brandväggsregel eller en standardrutt mot en onåbar gateway.

Priset är att allt annat stoppar, så undantagen blir en del av designen i stället för en eftertanke. Lokala skrivare, tjänsteupptäckt, inloggning på captive-portaler, hanteringsagenter och OS-uppdateringar behöver var och en ett dokumenterat hål, eftersom var och en är en väg som förblir öppen när tunneln är nere. Låsningen är bara så stark som den kortaste posten på den listan.

DNS, IPv6 och bakgrundshjälpare döljer läckorna

Att en skyddad app inte kan lösa ett namn bevisar inte att cachelagrade svar eller direkt IP-trafik är blockerade. Om resolvern fortfarande går att nå utanför tunneln löses namnet upp och anslutningen misslyckas, vilket ser ut som en fungerande kill switch och inte är det. Värre: en cachelagrad post kan peka på en adress som tunneln inte bär, så anslutningen går direkt ut medan appen rapporterar ett VPN-fel.

IPv6 behöver sin egen regel på varje plattform som kör det, eftersom en släppregel för v4 inte täcker en v6-rutt. På mobil kan en inställning för privat DNS flytta upplösningen in i en krypterad kanal som enhetspolicyn inte inspekterar. Och bakgrundshjälpare är den vanliga boven på skrivbordet: en uppdaterings- eller synkroniseringsprocess i aktivitetsfältet startar före VPN-klienten och håller sin egen anslutning, så den ser aldrig den ändrade rutten.

Testa tre appar och två övergångar

Kör varje rad två gånger, en gång med ett värdnamn och en gång med en bokstavlig adress, och en gång till över IPv6 om nätverket erbjuder det. Ett godkänt resultat betyder att den inkluderade appen stoppade, den uteslutna betedde sig som du skrev och hjälparen inte slank ut. Anteckna det direkta beteende som du bedömde som acceptabelt, så att nästa administratör kan skilja ett medvetet undantag från ett fel.

Beskriv sedan resultatet i en mening som namnger apparna och villkoren, till exempel: löneklienten har ingen rutt utanför tunneln, webbläsaren är direkt enligt design, och allt annat stoppar när tunneln är nere. Om den meningen är svår att skriva är policyn fortfarande två policyer som kämpar mot varandra.