Fail-open ali fail-closed: kaj odloči kill switch v VPN
Oba pojma opisujeta, kaj se zgodi, ko tunela ni več, ne pa, kako močno je šifriranje. Obseg, ki ga izberete, odloči, ali promet res uhaja.
Mit je, da je fail-closed varna nastavitev, fail-open pa malomarna. Oba opisujeta, kaj se zgodi s prometom, ko tunel izgine, in nobeden ne spremeni, kako dobro ta tunel šifrira. Politika fail-closed z dolgim seznamom izjem lahko uhaja bolj kot politika fail-open na napravi, ki nikoli ne zapusti pisarniškega omrežja. Izberite izid, ki ga lahko razložite lastniku prometa.
Oznaka opisuje izid, ne moči
Besedišče prihaja iz krmilnih sistemov: fail-open dovoli delovanje, ko komponenta odpove, fail-closed ga zavrne. Pri VPN je komponenta, ki odpove, tunel, in vprašanje je, ali se prometu dovoli nadaljevanje po drugi poti. Izbira šifre, dolžina ključa in protokol so ločene odločitve.
Zmeda ostaja, ker kill switch zveni kot varnostna funkcija, in ponudniki ga tako tržijo. Mehansko je to pravilo usmerjanja in požarnega zidu, ki blokira promet, ki bi ga moral nositi tunel, izvedeno v odjemalcu, v operacijskem sistemu ali na prehodu. Kateri koli sloj ga uveljavlja, določa tudi njegovo pokritost, in pravilo v enem sloju ne pokrije drugega. Pravilo na prehodu ne more zaščititi prenosnika, ki se je že preselil v drugo omrežje.
Kako izgleda vsak izid
Ista politika se lahko obnaša zelo različno glede na to, na katero okvaro naletite, zato primerjajte dogodke, ne oznak.
| 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 |
Zadnja vrstica je tista, ki ujame tiste, ki mislijo, da je kill switch eno samo stikalo. Pravilo, napisano za usmerjevalno tabelo IPv4, pusti privzeto pot IPv6 nedotaknjeno, in aplikacija jo lahko mirno uporablja.
Obseg odloči, ali uhaja
Vprašajte, kaj politika pokriva, preden vprašate, kateri način je. Pravilo za posamezno aplikacijo ščiti eno aplikacijo in nič drugega, pravilo za celotno napravo ščiti vse razen izjem, pravilo na prehodu pa le promet, ki doseže ta prehod. DNS potrebuje svojo odločitev, ker lahko poizvedba, poslana lokalnemu razreševalniku, razkrije imena tudi, ko je vsebina blokirana.
Izjeme za lokalno omrežje obstajajo za tiskalnike, predvajanje zaslona in prijavne portale, in vsaka je luknja v blokadi. Dokumentirajte jih ob politiki, ker bo oseba, ki konfiguracijo podeduje, sicer brala fail-closed kot absolut.
Ponovno povezovanje in blokiranje sta prav tako ločeni kontroli. Odjemalec se lahko samodejno ponovno poveže, ne da bi kdaj blokiral, ali blokira brez ponovnega povezovanja, kombinacija pa določa, kaj uporabnik doživi med prekinitvijo.
Dokažite to med prehodom
Preizkušanje ustaljenega stanja ne dokaže ničesar. Namerno podrite tunel in preizkusite aplikacijo, ki bi morala biti zaščitena, nato preverite, ali je dosegla omrežje. Primerjajte indikator odjemalca z rezultatom, ker je indikator, ki še vedno pravi povezano, natanko tisti primer, za katerega politika obstaja. Če zaščitena aplikacija uspe, ime načina ni pomembno; imate uhajanje.
Ponovite s hladnega zagona pred prijavo, ob prehodu z Wi-Fi na mobilno omrežje in z zaščiteno aplikacijo v ozadju. Če blokado uveljavlja proces odjemalca, preizkusite tudi, kaj se zgodi, ko je ta proces ubit, namesto da bi se čisto zaprl.
Na koncu preverite pot čiščenja. Če je odjemalec odstranjen, medtem ko so njegova pravila aktivna, uporabite dokumentirani postopek odstranitve ponudnika, namesto da izklopite požarni zid operacijskega sistema, ki odstrani nepovezano zaščito, ne da bi odgovoril, kdo je lastnik preostalega pravila.