Kill switch per app kontra låsing av hele enheten: hva endres
Bestem ut fra det beskyttede settet, ikke etiketten: hva som stopper for ekskluderte apper, bakgrunnshjelpere og nye tilkoblinger, og hvordan du tester hvert tilfelle.
En kill switch per app høres ut som det forsiktige valget: bare arbeidsklienten mister nettverket når tunnelen faller, og alt annet fortsetter å virke. Så oppdager noen at den personlige nettleseren likevel lastet en side, at synkroniseringshjelperen fra samme pakke fortsatte å prøve, og at et hurtiglagret navn fortsatt ble slått opp til en adresse som aldri rørte tunnelen. Etiketten på funksjonen og settet med tilkoblinger den faktisk beskytter, er to forskjellige ting. Bestem det beskyttede settet først, fordi det settet avgjør om håndheving per app eller en låsing av hele enheten er den ærlige beskrivelsen.
Start med settet, ikke etiketten
En policy per app beskytter utvalgte applikasjoner. En enhetslåsing sikter mot en bredere nettverksgrense, vanligvis med dokumenterte unntak for lokal utskrift, administrasjonstrafikk eller captive-portaler. Ingen av etikettene er komplette før du kan svare på tre spørsmål: hva som skjer med ekskluderte apper, hva som skjer med hjelperne disse appene starter, og hva som skjer med tilkoblinger som åpnes mens beskyttelsen ikke er tilgjengelig.
Skriv ned svarene før du rører en klientinnstilling. Hvis kravet er "denne lønnsasjonsklienten skal aldri snakke med internett utenfor tunnelen, og nettleseren min kan", er settet lite og håndheving per app passer. Hvis kravet er "ingenting på denne enheten når internett uten beskyttelse, unntatt oppdateringstjenesten", vil ingen policy per app produsere det, fordi appene du ikke navnga, er problemet.
Håndheving per app matcher identifikatorer, ikke programnavn
Android eksponerer VPN per app gjennom pakker, og VpnService-dokumentasjonen beskriver hvordan det samspiller med alltid-på-drift og blokkering. iOS konfigurerer VPN per app gjennom en administrasjonsprofil og matcher etter app eller etter domene. Windows og Linux har ingen rute per prosess i det hele tatt, så den samme ideen tilnærmes med en brannmurregel begrenset til et program eller med en regel som matcher den eierende brukeren.
Grensen er identifikatoren, og identifikatorer er lette å omgå. Et program som overlater en URL til systemnettleseren, eller åpner et dokument i en fremviser, går over i en prosess som policyen din aldri navnga. Et alternativ for å avslutte ved brudd er heller ikke et pakkefilter: det dreper appen du konfigurerte, mens en barneprosess, en køarbeider eller en nettleserfane kan holde en eksisterende socket i live.
Låsing dekker det en policy per app ikke kan se
En låsing av hele enheten fjerner valget. Hver utgående pakke som ikke tilhører tunnelen, droppes, inkludert trafikk fra prosesser som app-policyen din aldri kjente. På Android er det alltid-på-VPN kombinert med innstillingen som blokkerer tilkoblinger, og håndhevingen skjer i systemet, ikke i klientvinduet. På en datamaskin er det en vedvarende brannmurregel eller en standardrute mot en utilgjengelig gateway.
Prisen er at alt annet stopper, så unntakene blir en del av designet i stedet for en ettertanke. Lokale skrivere, tjenesteoppdagelse, pålogging på captive-portaler, administrasjonsagenter og OS-oppdateringer trenger hver et dokumentert hull, fordi hver av dem er en vei som forblir åpen når tunnelen er nede. Låsingen er bare så sterk som den korteste oppføringen på listen.
DNS, IPv6 og bakgrunnshjelpere skjuler lekkasjene
At en beskyttet app ikke klarer å slå opp et navn, beviser ikke at hurtiglagrede svar eller direkte IP-trafikk er blokkert. Hvis oppløseren fortsatt er tilgjengelig utenfor tunnelen, løses navnet opp og tilkoblingen feiler, noe som ser ut som en fungerende kill switch og ikke er det. Verre: en hurtiglagret post kan peke på en adresse tunnelen ikke bærer, så tilkoblingen går direkte ut mens appen rapporterer en VPN-feil.
IPv6 trenger sin egen regel på hver plattform som kjører det, fordi en droppregel for v4 ikke dekker en v6-rute. På mobil kan en innstilling for privat DNS flytte oppløsningen inn i en kryptert kanal som enhetspolicyen ikke inspiserer. Og bakgrunnshjelpere er den vanlige syndebukken på skrivebordet: en oppdaterings- eller synkroniseringsprosess starter før VPN-klienten og holder sin egen tilkobling, så den ser aldri den endrede ruten.
Test tre apper og to overganger
| 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 |
Kjør hver rad to ganger, én gang med et vertsnavn og én gang med en bokstavelig adresse, og én gang til over IPv6 hvis nettverket tilbyr det. Bestått betyr at den inkluderte appen stoppet, den ekskluderte oppførte seg som du skrev, og hjelperen ikke smatt ut. Noter den direkte oppførselen du bestemte var akseptabel, slik at neste administrator kan skille et bevisst unntak fra en feil.
Beskriv deretter resultatet i én setning som navngir appene og betingelsene, for eksempel: lønnsasjonsklienten har ingen rute utenfor tunnelen, nettleseren er direkte etter design, og alt annet stopper når tunnelen er nede. Hvis den setningen er vanskelig å skrive, er policyen fortsatt to policyer som kjemper mot hverandre.