Fail-open of fail-closed: wat 'n VPN-kill switch bepaal
Albei terme beskryf wat gebeur wanneer die tonnel weg is, nie hoe sterk die versleuteling is nie. Die omvang wat jy kies, bepaal of verkeer werklik lek.
Die mite is dat fail-closed die veilige instelling is en fail-open die sorgelose een. Albei beskryf wat met verkeer gebeur sodra die tonnel weg is, en nie een verander hoe goed daardie tonnel versleutel nie. 'n Fail-closed-beleid met 'n lang uitsonderingslys kan meer lek as 'n fail-open-beleid op 'n toestel wat nooit die kantoornetwerk verlaat nie. Kies die uitkoms wat jy aan die persoon wat die verkeer besit, kan verduidelik.
Die etiket beskryf 'n uitkoms, nie 'n sterkte nie
Die woordeskat kom uit beheerstelsels: fail-open laat werking toe wanneer 'n komponent faal, fail-closed weier dit. Toegepas op 'n VPN is die falende komponent die tonnel, en die vraag is of die verkeer toegelaat word om op 'n ander pad voort te gaan. Syferkeuse, sleutellengte en protokol is aparte besluite.
Die verwarring bly voortbestaan omdat 'n kill switch na 'n sekuriteitsfunksie klink, en verkopers bemark dit as een. Meganies is dit 'n roete- en brandmuurreël wat verkeer blokkeer wat die tonnel veronderstel was om te dra, geïmplementeer in die kliënt, in die bedryfstelsel of op die gateway. Watter laag dit ook al afdwing, definieer ook die dekking daarvan, en 'n reël in een laag dek nie 'n ander nie. 'n Gateway-reël kan nie 'n skootrekenaar beskerm wat al na 'n ander netwerk geskuif het nie.
Hoe elke uitkoms lyk
Dieselfde beleid kan baie anders optree na gelang van watter faling jy tref, so vergelyk die gebeure eerder as die etikette.
| 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 |
Die laaste ry is die een wat mense vang wat aanneem 'n kill switch is 'n enkele skakelaar. 'n Reël wat vir die IPv4-roetetabel geskryf is, laat die IPv6-standaardroete onaangeraak, en die toepassing kan dit gerieflik gebruik.
Omvang bepaal of dit lek
Vra wat die beleid dek voordat jy vra watter modus dit is. 'n Reël per toepassing beskerm een app en niks anders nie, 'n reël vir die hele toestel beskerm alles behalwe die uitsonderings, en 'n gateway-reël beskerm net verkeer wat daardie gateway bereik. DNS het sy eie besluit nodig, want 'n navraag na 'n plaaslike oplosser kan name openbaar maak selfs wanneer die vrag geblokkeer is.
Uitsonderings vir die plaaslike netwerk bestaan vir drukkers, casting en captive portals, en elkeen is 'n gat in die blokkade. Dokumenteer hulle langs die beleid, want die persoon wat die konfigurasie erf, sal andersins fail-closed as absoluut lees.
Herverbinding en blokkering is ook aparte beheermaatreëls. 'n Kliënt kan outomaties herverbind sonder om ooit te blokkeer, of blokkeer sonder om te herverbind, en die kombinasie bepaal wat 'n gebruiker tydens 'n onderbreking ervaar.
Bewys dit tydens 'n oorgang
Die toets van die bestendige toestand bewys niks. Laat die tonnel doelbewus val en probeer die toepassing wat veronderstel is om beskerm te word, en kyk dan of dit die netwerk bereik het. Vergelyk die kliënt se aanwyser met die resultaat, want 'n aanwyser wat steeds verbind sê, is juis die geval waarvoor die beleid bestaan. As die beskermde toepassing slaag, maak die modus se naam nie saak nie; jy het 'n lek.
Herhaal vanaf 'n koue aanskakeling voor aanmelding, oor 'n Wi-Fi-na-sellulêr-oorskakeling, en met die beskermde app in die agtergrond. As die blokkade deur die kliëntproses afgedwing word, toets ook wat gebeur wanneer daardie proses gedood word eerder as netjies toegemaak word.
Laastens, kyk na die opruimingspad. As 'n kliënt gedeïnstalleer word terwyl sy reëls aktief is, gebruik die verkoper se gedokumenteerde verwyderingsprosedure in plaas daarvan om die bedryfstelsel se brandmuur te deaktiveer, wat onverwante beskerming verwyder sonder om te antwoord wie die oorblywende reël besit.