Blockerar en kill switch trafiken innan VPN-appen startar?

En kill switch täcker kanske eller kanske inte fönstret innan appen startar, och skillnaden avgörs av operativsystemets policy och inte av klientens marknadsföringssida. En kryssruta för autostart bevisar att något är schemalagt att starta. Den bevisar inte att blockeringsregler finns i det ögonblick nätverket kommer upp. Det är två händelser, och bara en av dem skyddar trafiken.

Gå igenom checklistan i ordning, eftersom varje steg snävar in vad du faktiskt testar.

Var blockeringen egentligen kommer ifrån

Det finns två familjer av implementering. Antingen installerar plattformen blockeringen, eftersom den känner till tunneln innan någon app körs, eller installerar klienten blockeringen själv efter att den har startat. Den första kan finnas före inloggning. Den andra kan inte finnas före sin process, hur tidigt den processen än är schemalagd. Ta reda på vilken familj du förlitar dig på innan du testar något.

På Android är alltid-på-VPN kombinerat med inställningen som blockerar anslutningar utan VPN plattformspolicy, konfigurerad i systeminställningarna och inte bara inuti en klient. Hanterade enheter kan få den satt åt dig. En klient som bara startar vid uppstart är inte samma mekanism.

Skilj fönstret från tjänsten

Ett stängt fönster är inte bevis för att upprätthållandet har upphört, och ett öppet fönster är inte bevis för att en tunnel är redo. Många klienter skiljer på gränssnittet, daemonen och programmet i aktivitetsfältet. Aktivitetsfältet är det du ser; daemonen är det som håller reglerna.

Testa komponenten, inte ikonen.

Testa startintervallet säkert

Intervallet som ska testas börjar vid omstart eller inloggning och slutar när tunneln autentiserar sig. Bakgrundsprogram ansluter under den perioden, och uppdateringskontroller är de vanliga syndarna. Använd ofarlig aktivitet och leverantörens dokumenterade procedur i stället för att blockera din egen åtkomst. Upprepa sedan efter en normal återanslutning, eftersom en återanslutningsväg och en kallstartsväg kör olika kod.

Ett test som utförs efter att tunneln redan är uppe bevisar ingenting om starten.

Läs omstartsbeteendet om beständighet är kravet. En inställning kan överleva i konfigurationen medan dess upprätthållande börjar senare, och båda fakta räknas: den sparade policyn och ögonblicket då den blir aktiv.

Läs policyn per plattform

Android exponerar alltid på och blockering som separata reglage, och båda måste vara på för skydd före start. Windows har ett koncept med alltid-på-enhetstunnel konfigurerad via policy, vilket inte är samma sak som en tidigt startande klient i användarläge. OpenVPN Connect dokumenterar sitt eget kill switch-beteende per plattform, och det dokumenterade omfånget är det du testar. Flytta inte ett inställningsnamn från ett system till ett annat och anta att betydelsen följde med.

En profil som kräver ett interaktivt lösenord har andra startberoenden än en maskintunnel.

Vad som ska registreras

Skriv ned vilken mekanism som gäller, i vilket skede den blir aktiv och vilken trafik som försöktes före det skedet. Registrera plattformsversionen, eftersom detta beteende ändras mellan utgåvor och mellan hanterade och personliga konfigurationer. Notera om klienten eller systemet äger policyn, eftersom det avgör vem som kan åtgärda en lucka. Testa sedan igen efter varje klient- eller OS-uppdatering.

Om luckan spelar roll är den hållbara lösningen plattformspolicy, inte en kortare startfördröjning.

Det är svaret på den ursprungliga frågan, formulerat som ett villkor: en kill switch skyddar trafiken innan appen startar bara när blockeringen installeras av något som finns före appen.