Fail-open kontra fail-closed: hvad en VPN-kill switch afgør
Begge begreber beskriver, hvad der sker, når tunnelen er væk, ikke hvor stærk krypteringen er. Det omfang, du vælger, afgør, om trafikken reelt lækker.
Myten er, at fail-closed er den sikre indstilling, og fail-open er den skødesløse. Begge beskriver, hvad der sker med trafikken, når tunnelen er væk, og ingen af dem ændrer, hvor godt den tunnel krypterer. En fail-closed-politik med en lang undtagelsesliste kan lække mere end en fail-open-politik på en enhed, der aldrig forlader kontornettet. Vælg det udfald, du kan forklare den person, der ejer trafikken.
Etiketten beskriver et udfald, ikke en styrke
Ordforrådet kommer fra styresystemer: fail-open tillader drift, når en komponent svigter, fail-closed afviser den. Anvendt på en VPN er den svigtende komponent tunnelen, og spørgsmålet er, om trafikken må fortsætte ad en anden vej. Valget af cipher, nøglelængde og protokol er separate beslutninger.
Forvirringen består, fordi en kill switch lyder som en sikkerhedsfunktion, og leverandører markedsfører den som sådan. Mekanisk er den en routing- og firewallregel, der blokerer trafik, som tunnelen skulle have båret, implementeret i klienten, i styresystemet eller på gatewayen. Det lag, der håndhæver den, definerer også dens dækning, og en regel i ét lag dækker ikke et andet. En gatewayregel kan ikke beskytte en bærbar computer, der allerede er flyttet til et andet netværk.
Sådan ser hvert udfald ud
Den samme politik kan opføre sig meget forskelligt alt efter, hvilket svigt du rammer, så sammenlign hændelserne frem for etiketterne.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
Den sidste række er den, der fanger dem, der tror, at en kill switch er én enkelt kontakt. En regel skrevet til IPv4-routingtabellen lader IPv6-standardruten være urørt, og applikationen kan sagtens bruge den.
Omfanget afgør, om det lækker
Spørg, hvad politikken dækker, før du spørger, hvilken tilstand det er. En regel for hver applikation beskytter én app og intet andet, en regel for hele enheden beskytter alt undtagen undtagelserne, og en gatewayregel beskytter kun trafik, der når den gateway. DNS har brug for sin egen beslutning, fordi en forespørgsel sendt til en lokal resolver kan afsløre navne, selv når nyttelasten er blokeret.
Undtagelser for det lokale netværk findes til printere, casting og captive portals, og hver af dem er et hul i blokeringen. Dokumentér dem ved siden af politikken, for den person, der arver konfigurationen, vil ellers læse fail-closed som absolut.
Genopkobling og blokering er også separate kontroller. En klient kan genopkoble automatisk uden nogensinde at blokere, eller blokere uden at genopkoble, og kombinationen bestemmer, hvad en bruger oplever under et udfald.
Bevis det under en overgang
At teste den stabile tilstand beviser intet. Tag tunnelen ned med vilje, og prøv den applikation, der skulle være beskyttet, og kontroller derefter, om den nåede netværket. Sammenlign klientens indikator med resultatet, for en indikator, der stadig siger forbundet, er netop det tilfælde, politikken findes for. Hvis den beskyttede applikation lykkes, er tilstandens navn ligegyldigt; du har en lækage.
Gentag fra en kold opstart før login, ved skift fra Wi-Fi til mobilt netværk og med den beskyttede app i baggrunden. Hvis blokeringen håndhæves af klientprocessen, test også, hvad der sker, når den proces dræbes i stedet for at blive lukket pænt.
Til sidst skal du kontrollere oprydningsvejen. Hvis en klient afinstalleres, mens dens regler er aktive, brug leverandørens dokumenterede fjernelsesprocedure i stedet for at slå styresystemets firewall fra, hvilket fjerner urelateret beskyttelse uden at svare på, hvem der ejer den tilbageværende regel.