Kill switch застосунку проти kill switch брандмауера: що блокує кожен

Kill switch у списку функцій майже нічого не каже про те, що відбувається, коли тунель падає. Одна реалізація закриває вибрані процеси, інша встановлює фільтри пакетів на межі операційної системи, а третя просто намагається перепідключитися. Різниця проявляється в секундах після збою, а не на екрані налаштувань. Пройдіть ці перевірки по порядку і зупиніться на першій, на яку не можете чесно відповісти, бо саме там закінчується ваше реальне покриття.

Спочатку назвіть механізм примусу

Завершення процесів — це функція життєвого циклу застосунку. Вона знаходить вибрані програми після виявленого збою тунелю і закриває їх. Усе, що не є головним процесом, виживає: допоміжні служби, фонова синхронізація і будь-який застосунок, запущений секундою пізніше, мають власний життєвий цикл і власний час.

Фільтрування пакетів — це функція операційної системи. Воно відмовляє трафіку, що не йде дозволеним шляхом, що є сильнішою обіцянкою, але лише в межах того, що правило справді покриває. Родина адрес, інтерфейс, виключені застосунки та винятки вирішують це, а не напис у клієнті.

Чи переживає блокування клієнта?

Поставте чотири запитання в цьому порядку: що відбувається під час збою, ручного виходу, виходу з системи та перезавантаження. Правило, яке підтримує сам клієнт, зазвичай видаляється під час коректного завершення і часто залишається після збою. Правило, встановлене в сховищі платформи, може поводитися навпаки: переживати і клієнта, і іноді видалення.

Закрийте клієнт посеред довгого завантаження і подивіться, чи передавання зупиняється чи продовжується.

Шукайте стандартні діри

IPv6 — перша. Правило, написане для адрес IPv4, залишає трафік IPv6 недоторканим, і багато клієнтів пишуть лише половину v4. Друга — інтерфейс: USB-тетеринг, другий Wi-Fi адаптер і стільниковий модем можуть не входити до правила, обмеженого основним з'єднанням. Виключені застосунки і винятки локальної мережі — третя.

У Windows можна прочитати встановлені правила замість того, щоб довіряти перемикачу: Get-NetFirewallRule -DisplayName '*VPN*' і netsh wfp show filters обидва показують, що існує. У Linux iptables -S, ip6tables -S і nft list ruleset покривають звичайні випадки, і порівняння всіх трьох — це суть.

DNS — звичайний витік

Блокування TCP, коли UDP 53 залишається відкритим, дає вам дуже переконливий kill switch, який усе ще відповідає на кожен запит імені хоста. Те саме стосується випадку, коли DNS передається розв'язувачу на іншому інтерфейсі, або коли клієнт блокує лише v4, а розв'язувач доступний через v6.

Коли тунель опущений, розв'яжіть одне відоме ім'я і подивіться, чи повертається відповідь. Якщо повертається, трафік не заблокований повністю, хоч би що казав значок стану.

Перевіряйте перехід, а не перемикач

Вимкнення VPN з його власного меню — це коректне завершення, і коректний випадок кожна реалізація обробляє добре. Важливий перехід — грубий: убійте процес тунелю, витягніть мережу, дайте серверу перестати відповідати. Потім запустіть запит і подивіться, чи він провалиться, чи тихо використає фізичний канал.

Результат з одного ноутбука не переноситься на телефон чи маршрутизатор. Різні API платформ, різні типові значення, а в Android різниця різка: always-on з блокуванням застосовує система, а не клієнт, тому він продовжує працювати, коли клієнт не працює. Посібник з VPN для Android описує цей поділ.

Залиште шлях назад

Блокування на рівні системи має протилежний режим відмови. Фільтри, що переживають клієнта, можуть залишити машину зовсім без мережі після видалення, а це звернення до підтримки без очевидної причини. Перед увімкненням будь-якого kill switch, який пише правила платформи, занотуйте, як його видаляють, і тримайте шлях відновлення від постачальника там, де зможете його знайти.

Якщо ви не можете відповісти на перевірки збою, IPv6, DNS і переходу для свого клієнта, ставтеся до нього як до перемикача рівня застосунку з відомими дірами і плануйте відповідно.