Fail-open of fail-closed: wat een VPN-killswitch beslist
Beide termen beschrijven wat er gebeurt als de tunnel weg is, niet hoe sterk de versleuteling is. De scope die je kiest bepaalt of verkeer echt lekt.
De mythe is dat fail-closed de veilige instelling is en fail-open de slordige. Beide beschrijven wat er met verkeer gebeurt zodra de tunnel weg is, en geen van beide verandert hoe goed die tunnel versleutelt. Een fail-closed-beleid met een lange uitzonderingenlijst kan meer lekken dan een fail-open-beleid op een apparaat dat het kantoornetwerk nooit verlaat. Kies de uitkomst die je kunt uitleggen aan de persoon die het verkeer bezit.
Het label beschrijft een uitkomst, niet een sterkte
Het vocabulaire komt uit regelsystemen: fail-open staat werking toe wanneer een component uitvalt, fail-closed weigert die. Toegepast op een VPN is de uitvallende component de tunnel, en de vraag is of het verkeer via een andere route mag doorgaan. Keuze van cipher, sleutellengte en protocol zijn aparte beslissingen.
De verwarring blijft bestaan omdat een killswitch als een beveiligingsfunctie klinkt, en leveranciers hem zo verkopen. Mechanisch is het een routing- en firewallregel die verkeer blokkeert dat de tunnel zou dragen, geïmplementeerd in de client, in het besturingssysteem of op de gateway. Welke laag hem handhaaft, bepaalt ook de dekking, en een regel in de ene laag dekt de andere niet. Een gatewayregel kan een laptop die al naar een ander netwerk is verhuisd niet beschermen.
Hoe elke uitkomst eruitziet
Hetzelfde beleid kan zich heel anders gedragen afhankelijk van de storing die je treft, dus vergelijk de gebeurtenissen en niet de labels.
| 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 |
De laatste rij is degene die mensen vangt die aannemen dat een killswitch één schakelaar is. Een regel die voor de IPv4-routingtabel is geschreven laat de standaardroute IPv6 ongemoeid, en de toepassing kan er rustig gebruik van maken.
De scope bepaalt of het lekt
Vraag wat het beleid dekt voordat je vraagt welke modus het is. Een regel per toepassing beschermt één app en niets anders, een apparaatbrede regel beschermt alles behalve de uitzonderingen, en een gatewayregel beschermt alleen verkeer dat die gateway bereikt. DNS heeft zijn eigen beslissing nodig, want een query naar een lokale resolver kan namen onthullen, zelfs wanneer de payload is geblokkeerd.
Uitzonderingen voor het lokale netwerk bestaan voor printers, casting en captive portals, en elk daarvan is een gat in de blokkade. Documenteer ze naast het beleid, want wie de configuratie erft, leest fail-closed anders als absoluut.
Opnieuw verbinden en blokkeren zijn ook aparte besturingen. Een client kan automatisch opnieuw verbinden zonder ooit te blokkeren, of blokkeren zonder opnieuw te verbinden, en de combinatie bepaalt wat een gebruiker tijdens een storing ervaart.
Bewijs het tijdens een overgang
Het testen van de stabiele toestand bewijst niets. Laat de tunnel opzettelijk vallen en probeer de toepassing die beschermd zou moeten zijn, en controleer daarna of die het netwerk bereikte. Vergelijk de indicator van de client met het resultaat, want een indicator die nog steeds verbonden zegt, is precies het geval waarvoor het beleid bestaat. Als de beschermde toepassing slaagt, doet de naam van de modus er niet toe; je hebt een lek.
Herhaal vanaf een koude start vóór het aanmelden, bij een overgang van Wi-Fi naar mobiel netwerk en met de beschermde app op de achtergrond. Als de blokkade door het clientproces wordt gehandhaafd, test dan ook wat er gebeurt als dat proces wordt gedood in plaats van netjes afgesloten.
Controleer ten slotte het opruimpad. Als een client wordt verwijderd terwijl de regels actief zijn, gebruik dan de gedocumenteerde verwijderingsprocedure van de leverancier in plaats van de firewall van het besturingssysteem uit te zetten, wat ongerelateerde bescherming wegneemt zonder te beantwoorden wie de overgebleven regel bezit.