Blokkerer en kill switch trafikken før VPN-appen starter?

En kill switch dekker kanskje eller kanskje ikke vinduet før appen starter, og forskjellen avgjøres av operativsystemets policy og ikke av klientens markedsføringsside. En avkrysningsboks for automatisk start beviser at noe er planlagt å starte. Den beviser ikke at blokkeringsregler finnes i det øyeblikket nettverket kommer opp. Det er to hendelser, og bare én av dem beskytter trafikken.

Gå gjennom sjekklisten i rekkefølge, fordi hvert trinn snevrer inn det du faktisk tester.

Hvor blokkeringen egentlig kommer fra

Det finnes to familier av implementering. Enten installerer plattformen blokkeringen, fordi den kjenner tunnelen før noen app kjører, eller klienten installerer blokkeringen selv etter at den har startet. Den første kan finnes før innlogging. Den andre kan ikke finnes før prosessen sin, uansett hvor tidlig den prosessen er planlagt. Finn ut hvilken familie du baserer deg på før du tester noe.

På Android er alltid-på VPN kombinert med innstillingen som blokkerer tilkoblinger uten VPN, plattformpolicy, konfigurert i systeminnstillingene og ikke bare inne i en klient. Administrerte enheter kan få den satt for deg. En klient som bare starter ved oppstart, er ikke samme mekanisme.

Skill vinduet fra tjenesten

Et lukket vindu er ikke bevis for at håndhevelsen har stoppet, og et åpent vindu er ikke bevis for at en tunnel er klar. Mange klienter skiller grensesnittet, daemonen og programmet i systemkurven. Systemkurven er det du ser; daemonen er det som holder reglene.

Test komponenten, ikke ikonet.

Test oppstartsintervallet trygt

Intervallet som skal testes, begynner ved omstart eller innlogging og slutter når tunnelen autentiserer. Bakgrunnsprogrammer kobler til i den perioden, og oppdateringssjekker er de vanlige synderne. Bruk harmløs aktivitet og leverandørens dokumenterte prosedyre i stedet for å blokkere din egen tilgang. Gjenta deretter etter en normal gjentilkobling, fordi en gjentilkoblingsvei og en kaldstartvei kjører forskjellig kode.

En test som utføres etter at tunnelen allerede er oppe, beviser ingenting om oppstarten.

Les omstartsatferden hvis vedvarende beskyttelse er kravet. En innstilling kan overleve i konfigurasjonen mens håndhevelsen begynner senere, og begge fakta teller: den lagrede policyen og øyeblikket den blir aktiv.

Les policyen per plattform

Android eksponerer alltid på og blokkering som separate brytere, og begge må være på for beskyttelse før start. Windows har et konsept med alltid-på enhetstunnel konfigurert gjennom policy, som ikke er det samme som en klient i brukermodus som starter tidlig. OpenVPN Connect dokumenterer sin egen kill switch-atferd per plattform, og det dokumenterte omfanget er det du tester. Ikke flytt et innstillingsnavn fra ett system til et annet og anta at betydningen fulgte med.

En profil som krever et interaktivt passord, har andre oppstartsavhengigheter enn en maskintunnel.

Hva som skal registreres

Skriv ned hvilken mekanisme som gjelder, på hvilket trinn den blir aktiv, og hvilken trafikk som ble forsøkt før det trinnet. Registrer plattformversjonen, fordi denne atferden endres mellom utgivelser og mellom administrerte og personlige konfigurasjoner. Noter om klienten eller systemet eier policyen, siden det avgjør hvem som kan rette en mangel. Test deretter på nytt etter enhver klient- eller OS-oppdatering.

Hvis mangelen betyr noe, er den varige løsningen plattformpolicy, ikke en kortere oppstartsforsinkelse.

Det er svaret på det opprinnelige spørsmålet, formulert som en betingelse: en kill switch beskytter trafikken før appen starter bare når blokkeringen installeres av noe som finnes før appen.