Blokkeert een kill switch verkeer voordat de VPN-app start?
Bescherming bij het opstarten hangt ervan af wie de blokkade installeert en wanneer, niet van een selectievakje voor automatisch starten. Controleer het platformbeleid voordat u de client vertrouwt.
Een kill switch dekt het venster voordat zijn app start misschien wel of niet, en het verschil wordt bepaald door het beleid van het besturingssysteem, niet door de marketingpagina van de client. Een selectievakje voor automatisch starten bewijst dat er iets gepland staat om te starten. Het bewijst niet dat blokkeerregels bestaan op het moment dat het netwerk omhoog komt. Dat zijn twee gebeurtenissen, en slechts één ervan beschermt verkeer.
Werk de checklist op volgorde af, want elke stap vernauwt wat u feitelijk test.
Waar de blokkade echt vandaan komt
Er zijn twee families van implementatie. Ofwel installeert het platform de blokkade, omdat het de tunnel kent voordat er ook maar een app draait, ofwel de client installeert de blokkade zelf nadat hij is gestart. De eerste kan bestaan vóór het inloggen. De tweede kan niet bestaan vóór zijn proces, hoe vroeg dat proces ook is gepland. Bepaal op welke familie u vertrouwt voordat u iets test.
Op Android is altijd-aan VPN gecombineerd met de instelling die verbindingen zonder VPN blokkeert platformbeleid, geconfigureerd in de systeeminstellingen en niet alleen in een client. Op beheerde apparaten kan het voor u zijn ingesteld. Een client die alleen bij het opstarten begint, is niet hetzelfde mechanisme.
Scheid het venster van de dienst
Een gesloten venster is geen bewijs dat de handhaving is gestopt, en een open venster is geen bewijs dat een tunnel klaar is. Veel clients scheiden de interface, de daemon en de tray-applicatie. De tray is wat u ziet; de daemon is wat de regels vasthoudt.
Test de component, niet het pictogram.
Test het opstartinterval veilig
Het te testen interval begint bij herstart of inloggen en eindigt wanneer de tunnel zich authenticeert. Achtergrondapplicaties verbinden in die periode, en updatecontroles zijn de gebruikelijke boosdoeners. Gebruik onschadelijke activiteit en de gedocumenteerde procedure van de leverancier in plaats van uw eigen toegang te blokkeren. Herhaal daarna na een normale herverbinding, want een herverbindingspad en een koudstartpad voeren andere code uit.
Een test die wordt uitgevoerd nadat de tunnel al omhoog is, bewijst niets over het opstarten.
Lees het herstartgedrag als persistentie de eis is. Een instelling kan in de configuratie overleven terwijl de handhaving later begint, en beide feiten tellen: het opgeslagen beleid en het moment waarop het actief wordt.
Lees het beleid per platform
Android toont altijd-aan en blokkeren als afzonderlijke schakelaars, en beide moeten aan staan voor bescherming vóór het starten. Windows heeft een via beleid geconfigureerd concept van een altijd-aan apparaattunnel, dat niet hetzelfde is als een vroeg startende client in gebruikersmodus. OpenVPN Connect documenteert zijn eigen kill switch-gedrag per platform, en de gedocumenteerde reikwijdte is wat u test. Neem geen instellingsnaam van het ene systeem over naar het andere en ga er niet van uit dat de betekenis is meegereisd.
Een profiel dat een interactief wachtwoord vereist, heeft andere opstartafhankelijkheden dan een machinetunnel.
Wat te registreren
Noteer welk mechanisme van kracht is, in welke fase het actief wordt en welk verkeer vóór die fase is geprobeerd. Registreer de platformversie, want dit gedrag verandert tussen releases en tussen beheerde en persoonlijke configuraties. Noteer of de client of het systeem het beleid bezit, omdat dat bepaalt wie een gat kan dichten. Test daarna opnieuw na elke client- of OS-update.
Als het gat ertoe doet, is de duurzame oplossing platformbeleid, niet een kortere opstartvertraging.
Dat is het antwoord op de oorspronkelijke vraag, als voorwaarde geformuleerd: een kill switch beschermt verkeer voordat de app start alleen wanneer de blokkade wordt geïnstalleerd door iets dat bestaat voordat de app bestaat.