Fail-open o fail-closed: ano ang itinatakda ng kill switch ng VPN
Inilalarawan ng dalawang termino ang nangyayari kapag wala na ang tunnel, hindi ang tindi ng encryption. Ang saklaw na pipiliin mo ang nagtatakda kung talagang tumatagas ang trapiko.
Mito na ang fail-closed ay ang ligtas na setting at ang fail-open ay ang pabaya. Inilalarawan ng dalawa ang nangyayari sa trapiko kapag wala na ang tunnel, at wala sa kanila ang nagbabago kung gaano kahusay nag-e-encrypt ang tunnel na iyon. Ang patakarang fail-closed na may mahabang listahan ng eksepsiyon ay maaaring tumagas nang higit pa sa patakarang fail-open sa isang device na hindi kailanman lumalabas ng network ng opisina. Piliin ang kinalabasan na maipapaliwanag mo sa may-ari ng trapiko.
Inilalarawan ng label ang kinalabasan, hindi ang lakas
Galing ang bokabularyo sa mga control system: pinapayagan ng fail-open ang operasyon kapag nabigo ang isang bahagi, tinatanggihan ito ng fail-closed. Kapag inilapat sa isang VPN, ang bahaging nabigo ay ang tunnel, at ang tanong ay kung pinapayagan ang trapiko na magpatuloy sa ibang landas. Ang pagpili ng cipher, haba ng susi, at protocol ay magkakahiwalay na desisyon.
Nanatili ang kalituhan dahil ang kill switch ay parang feature ng seguridad, at ganoon ito ibinebenta ng mga vendor. Sa mekanikal na paraan ito ay patakaran sa routing at firewall na humaharang sa trapikong dapat dalhin ng tunnel, na ipinatutupad sa kliyente, sa operating system, o sa gateway. Alinmang layer ang nagpapatupad nito ay siya ring nagtatakda ng saklaw, at ang patakaran sa isang layer ay hindi sumasaklaw sa iba. Ang patakaran sa gateway ay hindi makakaprotekta sa laptop na lumipat na sa ibang network.
Itsura ng bawat kinalabasan
Ang parehong patakaran ay maaaring kumilos nang ibang-iba depende sa failure na makaharap mo, kaya ihambing ang mga pangyayari at hindi ang mga label.
| 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 |
Ang huling hilera ang humuhuli sa mga nag-aakalang ang kill switch ay isang switch lamang. Ang patakarang isinulat para sa IPv4 routing table ay iniiwan ang default na ruta ng IPv6 na hindi ginalaw, at masaya itong magagamit ng aplikasyon.
Saklaw ang nagtatakda kung tumatagas
Itanong kung ano ang sinasaklaw ng patakaran bago itanong kung anong mode ito. Ang patakaran kada aplikasyon ay nagpoprotekta sa isang app at wala nang iba, ang patakaran para sa buong device ay nagpoprotekta sa lahat maliban sa mga eksepsiyon, at ang patakaran sa gateway ay nagpoprotekta lamang sa trapikong nakakarating sa gateway na iyon. Kailangan ng DNS ng sariling desisyon, dahil ang query na ipinadala sa lokal na resolver ay maaaring magbunyag ng mga pangalan kahit naka-block ang payload.
May mga eksepsiyon sa lokal na network para sa mga printer, casting, at captive portal, at bawat isa ay butas sa pagharang. Idokumento ang mga ito sa tabi ng patakaran, dahil ang taong magmamana ng configuration ay babasahin ang fail-closed bilang ganap kung hindi.
Ang muling pagkonekta at pagharang ay magkahiwalay ding kontrol. Ang kliyente ay maaaring awtomatikong muling kumonekta nang hindi kailanman humaharang, o humarang nang hindi muling kumokonekta, at ang kombinasyon ang nagtatakda kung ano ang nararanasan ng user sa isang pagkawala ng serbisyo.
Patunayan ito sa panahon ng paglipat
Walang pinapatunayan ang pagsubok sa steady state. Sadyang patumbahin ang tunnel at subukan ang aplikasyong dapat protektado, pagkatapos ay tingnan kung nakarating ito sa network. Ihambing ang indicator ng kliyente sa resulta, dahil ang indicator na nagsasabing konektado pa rin ay siya mismong kaso na dahilan ng patakaran. Kung nagtagumpay ang protektadong aplikasyon, hindi mahalaga ang pangalan ng mode; may tagas ka.
Ulitin mula sa cold boot bago mag-sign in, sa paglipat mula Wi-Fi patungong cellular, at habang nasa background ang protektadong app. Kung ang proseso ng kliyente ang nagpapatupad ng pagharang, subukan din ang nangyayari kapag ang prosesong iyon ay pinatay sa halip na maayos na isinara.
Sa huli, tingnan ang landas ng paglilinis. Kung i-uninstall ang isang kliyente habang aktibo ang mga patakaran nito, gamitin ang dokumentadong pamamaraan ng pag-alis ng vendor sa halip na patayin ang firewall ng operating system, na nag-aalis ng walang kaugnayang proteksyon nang hindi sinasagot kung kanino ang natirang patakaran.