Kill switch pr. app kontra lockdown af hele enheden: hvad ændrer sig
Beslut ud fra det beskyttede sæt, ikke etiketten: hvad stopper for udelukkede apps, baggrundshjælpere og nye forbindelser, og hvordan du tester hvert tilfælde.
En kill switch pr. app lyder som det forsigtige valg: kun arbejdsklienten mister sit netværk, når tunnelen falder, og alt andet bliver ved med at virke. Så opdager nogen, at den personlige browser alligevel indlæste en side, at synkroniseringshjælperen fra samme pakke blev ved med at prøve, og at et cachelagret navn stadig blev opløst til en adresse, der aldrig rørte tunnelen. Etiketten på funktionen og det sæt af forbindelser, den faktisk beskytter, er to forskellige ting. Fastlæg det beskyttede sæt først, fordi det sæt afgør, om håndhævelse pr. app eller en lockdown af hele enheden er den ærlige beskrivelse.
Start med sættet, ikke etiketten
En politik pr. app beskytter udvalgte programmer. En enhedslockdown sigter mod en bredere netværksgrænse, normalt med dokumenterede undtagelser for lokal udskrivning, administrationstrafik eller captive-portaler. Ingen af etiketterne er komplette, før du kan svare på tre spørgsmål: hvad sker der med udelukkede apps, hvad sker der med de hjælpere, som de apps starter, og hvad sker der med forbindelser, der åbnes, mens beskyttelsen er utilgængelig.
Skriv svarene ned, før du rører en klientindstilling. Hvis kravet er "denne lønkørsel-klient må aldrig tale med internettet uden for tunnelen, og min browser må", er sættet lille, og håndhævelse pr. app passer. Hvis kravet er "intet på denne enhed når internettet uden beskyttelse, undtagen opdateringstjenesten", vil ingen politik pr. app frembringe det, fordi de apps, du ikke navngav, er problemet.
Håndhævelse pr. app matcher identifikatorer, ikke programnavne
Android eksponerer VPN pr. app via pakker, og dets VpnService-dokumentation beskriver, hvordan det spiller sammen med altid-til og blokering. iOS konfigurerer VPN pr. app via en administrationsprofil og matcher efter app eller efter domæne. Windows og Linux har slet ingen rute pr. proces, så den samme idé tilnærmes med en firewallregel afgrænset til et program eller med en regel, der matcher den ejende bruger.
Grænsen er identifikatoren, og identifikatorer er nemme at gå udenom. Et program, der giver en URL videre til systembrowseren eller åbner et dokument i en fremviser, krydser ind i en proces, som din politik aldrig navngav. En afslut-ved-nedbrud-indstilling er heller ikke et pakkefilter: den dræber det program, du konfigurerede, mens en underproces, en køarbejder eller en browservane kan holde en eksisterende socket i live.
Lockdown dækker det, en politik pr. app ikke kan se
En lockdown af hele enheden fjerner valget. Hver udgående pakke, der ikke hører til tunnelen, droppes, inklusive trafik fra processer, som din app-politik aldrig kendte. På Android er det altid-til-VPN kombineret med indstillingen, der blokerer forbindelser, og håndhævelsen sker i systemet, ikke i klientvinduet. På en computer er det en vedvarende firewallregel eller en standardrute, der peger på en uopnåelig gateway.
Prisen er, at alt andet stopper, så undtagelserne bliver en del af designet i stedet for en eftertanke. Lokale printere, tjenesteopdagelse, login på captive-portaler, administrationsagenter og OS-opdateringer har hver brug for et dokumenteret hul, fordi hver af dem er en vej, der forbliver åben, når tunnelen er nede. Lockdown er kun så stærk som den korteste post på den liste.
DNS, IPv6 og baggrundshjælpere skjuler lækagerne
At en beskyttet app ikke kan opløse et navn, beviser ikke, at cachelagrede svar eller direkte IP-trafik er blokeret. Hvis resolveren stadig kan nås uden for tunnelen, opløses navnet, og forbindelsen fejler, hvilket ligner en fungerende kill switch og ikke er det. Værre: en cachelagret post kan pege på en adresse, som tunnelen ikke bærer, så forbindelsen går direkte ud, mens appen rapporterer en VPN-fejl.
IPv6 har sin egen regel behov på enhver platform, der kører det, fordi en v4-dropregel ikke dækker en v6-rute. På mobil kan en privat DNS-indstilling flytte opløsningen ind i en krypteret kanal, som enhedspolitikken ikke inspicerer. Og baggrundshjælpere er den sædvanlige synder på skrivebordet: en opdaterings- eller synkroniseringsproces starter før VPN-klienten og holder sin egen forbindelse, så den ser aldrig den ændrede rute.
Test tre apps og to overgange
| Test | What it proves |
|---|---|
| Included app, by name and by direct IP | the policy is applied, not just the resolver |
| Excluded app, same checks | the exclusion is intentional and documented |
| Helper or updater process | nothing inherited an older route |
| Tunnel drop, then Wi-Fi to cellular | the block survives the transition |
Kør hver række to gange, en gang med et værtsnavn og en gang med en bogstavelig adresse, og en gang mere over IPv6, hvis netværket tilbyder det. Et bestået resultat betyder, at den inkluderede app stoppede, den udelukkede opførte sig, som du skrev, og hjælperen ikke smuttede ud. Notér den direkte adfærd, du besluttede var acceptabel, så den næste administrator kan skelne en bevidst undtagelse fra en fejl.
Beskriv derefter resultatet i én sætning, der navngiver appene og betingelserne, for eksempel: lønkørsel-klienten har ingen rute uden for tunnelen, browseren er direkte efter design, og alt andet stopper, når tunnelen er nede. Hvis den sætning er svær at skrive, er politikken stadig to politikker, der kæmper mod hinanden.