Fail-open срещу fail-closed: какво решава предпазният прекъсвач на VPN
Двата термина описват какво се случва, когато тунелът го няма, а не колко силно е криптирането. Обхватът, който изберете, решава дали трафикът наистина изтича.
Митът е, че fail-closed е сигурната настройка, а fail-open е нехайната. И двете описват какво се случва с трафика, след като тунелът изчезне, и нито едното не променя колко добре този тунел криптира. Политика fail-closed с дълъг списък изключения може да изтече повече от политика fail-open на устройство, което никога не напуска офисната мрежа. Изберете изхода, който можете да обясните на човека, който отговаря за трафика.
Етикетът описва изход, а не сила
Речникът идва от системите за управление: fail-open разрешава работа, когато компонент се повреди, fail-closed я забранява. Приложено към VPN, повреденият компонент е тунелът и въпросът е дали трафикът може да продължи по друг път. Изборът на шифър, дължината на ключа и протоколът са отделни решения.
Объркването се задържа, защото предпазният прекъсвач звучи като функция за сигурност и доставчиците го продават като такава. Механично това е правило за маршрутизиране и защитна стена, което блокира трафика, който тунелът е трябвало да пренася, изпълнявано в клиента, в операционната система или на шлюза. Който слой го налага, той определя и обхвата му, а правило в един слой не покрива друг. Правило на шлюза не може да защити лаптоп, който вече е преминал в друга мрежа.
Как изглежда всеки изход
Една и съща политика може да се държи много различно в зависимост от това на какъв отказ попаднете, затова сравнявайте събитията, а не етикетите.
| 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 |
Последният ред е този, който хваща хората, смятащи предпазния прекъсвач за един-единствен ключ. Правило, написано за IPv4 таблицата за маршрути, оставя IPv6 маршрута по подразбиране незасегнат и приложението може спокойно да го използва.
Обхватът решава дали има изтичане
Питайте какво покрива политиката, преди да питате кой е режимът. Правило за отделно приложение защитава едно приложение и нищо друго, правило за цялото устройство защитава всичко без изключенията, а правило на шлюза защитава само трафика, който стига до този шлюз. DNS се нуждае от собствено решение, защото заявка до локален резолвер може да разкрие имена дори когато полезният товар е блокиран.
Изключенията за локална мрежа съществуват заради принтери, предаване на екран и портали за вход, и всяко от тях е дупка в блока. Документирайте ги до политиката, защото човекът, който наследи конфигурацията, иначе ще прочете fail-closed като абсолют.
Повторното свързване и блокирането също са отделни средства за управление. Клиентът може да се свързва автоматично, без никога да блокира, или да блокира без да се свързва, а комбинацията определя какво изживява потребителят при прекъсване.
Докажете го по време на преход
Тестването на устойчивото състояние не доказва нищо. Прекъснете тунела умишлено и опитайте приложението, което трябва да е защитено, след което проверете дали е достигнало мрежата. Сравнете индикатора на клиента с резултата, защото индикатор, който все още казва „свързан“, е точно случаят, за който съществува политиката. Ако защитеното приложение успее, името на режима няма значение; имате изтичане.
Повторете от студено стартиране преди вход, при преминаване от Wi-Fi към мобилна мрежа и със защитеното приложение на заден план. Ако блокът се налага от процеса на клиента, тествайте и какво става, когато този процес бъде убит, а не затворен чисто.
Накрая проверете пътя за почистване. Ако клиент бъде деинсталиран, докато правилата му са активни, използвайте документираната от доставчика процедура за премахване, вместо да изключвате защитната стена на операционната система, което премахва несвързана защита, без да отговаря на въпроса кой притежава останалото правило.