Fail-open sau fail-closed: ce decide un kill switch de VPN
Ambii termeni descriu ce se întâmplă când tunelul nu mai există, nu cât de puternică este criptarea. Anvergura pe care o alegi decide dacă traficul chiar se scurge.
Mitul este că fail-closed este setarea sigură și fail-open cea neglijentă. Ambele descriu ce se întâmplă cu traficul după ce tunelul dispare, și niciuna nu schimbă cât de bine criptează acel tunel. O politică fail-closed cu o listă lungă de excepții poate scurge mai mult decât o politică fail-open pe un dispozitiv care nu părăsește niciodată rețeaua biroului. Alege rezultatul pe care îl poți explica persoanei care deține traficul.
Eticheta descrie un rezultat, nu o forță
Vocabularul vine din sistemele de control: fail-open permite funcționarea când o componentă cedează, fail-closed o refuză. Aplicat la un VPN, componenta care cedează este tunelul, iar întrebarea este dacă traficului i se permite să continue pe altă cale. Alegerea cifrului, lungimea cheii și protocolul sunt decizii separate.
Confuzia persistă pentru că un kill switch sună ca o funcție de securitate, iar furnizorii îl vând ca atare. Mecanic este o regulă de rutare și de firewall care blochează traficul pe care tunelul trebuia să îl transporte, implementată în client, în sistemul de operare sau pe gateway. Stratul care o aplică îi definește și acoperirea, iar o regulă dintr-un strat nu o acoperă pe cea din altul. O regulă pe gateway nu poate proteja un laptop care a trecut deja pe altă rețea.
Cum arată fiecare rezultat
Aceeași politică se poate comporta foarte diferit în funcție de defecțiunea pe care o întâlnești, așa că compară evenimentele, nu etichetele.
| 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 |
Ultimul rând este cel care îi prinde pe cei care presupun că un kill switch este un singur întrerupător. O regulă scrisă pentru tabela de rutare IPv4 lasă ruta implicită IPv6 neatinsă, iar aplicația o poate folosi liniștită.
Anvergura decide dacă se scurge
Întreabă ce acoperă politica înainte de a întreba ce mod este. O regulă per aplicație protejează o aplicație și nimic altceva, o regulă pentru întregul dispozitiv protejează tot, cu excepția excepțiilor, iar o regulă pe gateway protejează doar traficul care ajunge la acel gateway. DNS are nevoie de propria decizie, pentru că o interogare trimisă la un resolver local poate dezvălui nume chiar și când încărcătura este blocată.
Excepțiile pentru rețeaua locală există pentru imprimante, transmisia ecranului și portalurile captive, iar fiecare este o gaură în blocare. Documentează-le lângă politică, pentru că persoana care moștenește configurația va citi altfel fail-closed ca absolut.
Reconectarea și blocarea sunt și ele controale separate. Un client se poate reconecta automat fără să blocheze vreodată, sau poate bloca fără să se reconecteze, iar combinația determină ce trăiește un utilizator în timpul unei întreruperi.
Demonstrează-l în timpul unei tranziții
Testarea stării stabile nu demonstrează nimic. Doboară tunelul intenționat și încearcă aplicația care ar trebui să fie protejată, apoi verifică dacă a ajuns la rețea. Compară indicatorul clientului cu rezultatul, pentru că un indicator care încă spune conectat este exact cazul pentru care există politica. Dacă aplicația protejată reușește, numele modului nu contează; ai o scurgere.
Repetă de la o pornire la rece înainte de autentificare, la trecerea de la Wi-Fi la rețeaua mobilă și cu aplicația protejată în fundal. Dacă blocarea este aplicată de procesul clientului, testează și ce se întâmplă când acel proces este ucis, nu închis curat.
În final, verifică traseul de curățare. Dacă un client este dezinstalat în timp ce regulile sale sunt active, folosește procedura de eliminare documentată de furnizor în loc să dezactivezi firewallul sistemului de operare, care elimină protecție nelegată fără să răspundă cui îi aparține regula rămasă.