Fail-open või fail-closed: mida otsustab VPN-i turvalüliti
Mõlemad terminid kirjeldavad, mis juhtub siis, kui tunnel on kadunud, mitte kui tugev on krüpteerimine. Valitud ulatus otsustab, kas liiklus tõesti lekitab.
Müüt on, et fail-closed on turvaline seade ja fail-open hoolimatu. Mõlemad kirjeldavad, mis juhtub liiklusega pärast seda, kui tunnel on kadunud, ja kumbki ei muuda, kui hästi see tunnel krüpteerib. Fail-closed-poliitika pika erandite loendiga võib lekitada rohkem kui fail-open-poliitika seadmes, mis ei lahku kunagi kontorivõrgust. Valige tulemus, mida suudate selgitada inimesele, kellele liiklus kuulub.
Silt kirjeldab tulemust, mitte tugevust
Sõnavara pärineb juhtimissüsteemidest: fail-open lubab töötamist, kui komponent ebaõnnestub, fail-closed keelab selle. VPN-i puhul on ebaõnnestuv komponent tunnel ja küsimus on, kas liiklusel lubatakse jätkuda mõnel muul teel. Šifri valik, võtme pikkus ja protokoll on eraldi otsused.
Segadus püsib, sest turvalüliti kõlab turvafunktsioonina ja müüjad turundavad seda nii. Mehaaniliselt on see marsruutimis- ja tulemüürireegel, mis blokeerib liiklust, mida tunnel pidi kandma, rakendatud kliendis, operatsioonisüsteemis või lüüsil. Milline kiht seda rakendab, määrab ka selle katvuse, ja ühe kihi reegel ei kata teist. Lüüsi reegel ei suuda kaitsta sülearvutit, mis on juba teise võrku liikunud.
Kuidas iga tulemus välja näeb
Sama poliitika võib käituda väga erinevalt sõltuvalt sellest, millisele tõrkele satute, seega võrrelge sündmusi, mitte silte.
| 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 |
Viimane rida püüab need, kes eeldavad, et turvalüliti on üks lüliti. IPv4 marsruuditabeli jaoks kirjutatud reegel jätab IPv6 vaikimisi marsruudi puutumata ja rakendus võib seda mõnuga kasutada.
Ulatus otsustab, kas see lekib
Küsige, mida poliitika katab, enne kui küsite, mis režiim see on. Rakendusepõhine reegel kaitseb ühte rakendust ja mitte midagi muud, seadmepõhine reegel kaitseb kõike peale erandite ja lüüsi reegel kaitseb ainult liiklust, mis selle lüüsini jõuab. DNS vajab oma otsust, sest kohalikule lahendajale saadetud päring võib paljastada nimesid ka siis, kui kasulik koormus on blokeeritud.
Kohaliku võrgu erandid on printerite, ekraani jagamise ja sisselogimisportaalide jaoks ja igaüks neist on blokaadis auk. Dokumenteerige need poliitika kõrval, sest konfiguratsiooni pärija loeb fail-closed'i muidu absoluutsena.
Ühenduse taastamine ja blokeerimine on samuti eraldi juhtimisvahendid. Klient võib automaatselt uuesti ühenduda ilma kunagi blokeerimata või blokeerida ilma uuesti ühendumata, ja kombinatsioon määrab, mida kasutaja katkestuse ajal kogeb.
Tõestage seda ülemineku ajal
Püsiseisundi testimine ei tõesta midagi. Laske tunnel tahtlikult maha ja proovige rakendust, mis peaks olema kaitstud, seejärel kontrollige, kas see jõudis võrku. Võrrelge kliendi indikaatorit tulemusega, sest indikaator, mis ütleb endiselt ühendatud, on täpselt see juhtum, mille jaoks poliitika olemas on. Kui kaitstud rakendus õnnestub, ei loe režiimi nimi; teil on leke.
Korrake külmalt käivitusest enne sisselogimist, Wi-Fi-lt mobiilivõrku lülitumisel ja kaitstud rakendusega taustal. Kui blokeeringut rakendab kliendiprotsess, testige ka seda, mis juhtub, kui see protsess tappa, mitte korralikult sulgeda.
Lõpuks kontrollige puhastusteed. Kui klient desinstallitakse, kui selle reeglid on aktiivsed, kasutage müüja dokumenteeritud eemaldamisprotseduuri, mitte operatsioonisüsteemi tulemüüri väljalülitamist, mis eemaldab seotud kaitse, vastamata, kellele jäänud reegel kuulub.