Kill switch продовжує блокувати трафік після відключення VPN

Тунель зник, значок мережі виглядає нормально, а нічого не завантажується. Ви відключили VPN, видалили його або перезавантажилися, а блокування, яке мало захистити вас під час обриву, досі стоїть. Вікно клієнта цього не пояснить, бо блокує не клієнт: рішення було записано в ядро від вашого імені, і нічого не залишилося, щоб його прибрати. У Windows цей стан міститься в Windows Filtering Platform; у Linux це набір правил в iptables або nftables, часто зі знімком, який відтворюється під час завантаження. Далі — порядок, яким користуюся я: прочитати стан, видалити найвужчий об’єкт, що пояснює збій, потім знайти те, що постійно повертає його на місце.

Kill switch — це стан ядра, а не налаштування

Настільні клієнти реалізують блокування, додаючи фільтри, які забороняють трафік поза тунелем. У Windows це фільтри WFP на рівнях connect-redirect і transport, і деякі з них постійні: вони записуються в сховище політик Base Filtering Engine і відновлюються під час завантаження машини, до запуску будь-якого VPN-ПЗ. Клієнти різняться тим, коли прибирають. Одні видаляють фільтри під час відключення, інші лише під час чистого виходу, а ще інші лише якщо спершу вимкнути перемикач. Видаліть програму, поки блокування активне, або убіть процес, і фільтри залишаться.

Відповідник у Linux — правило drop або reject у вихідному шляху, іноді правило forwarding, іноді змінена політика ланцюжка. Ці правила переживають процес, що їх додав, бо це стан ядра: убийте клієнт, зруйнуйте його або вимкніть живлення, і ядро й далі відкидатиме пакети, а скасувати це нічим. Пакет збереження додає другий шар постійності: робить знімок поточного набору правил і відновлює його під час завантаження, тож наступний запуск починається з уже встановленим блокуванням.

Прочитайте стан WFP, перш ніж щось видаляти

Windows постачається з потрібними інструментами. Запустіть консоль із правами адміністратора і вивантажте стан платформи; дамп з’явиться як wfpstate.xml у робочому каталозі.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Шукайте в XML ім’я постачальника, що пішов, дію Block і рівень. Фільтри на connect-redirect і transport — ті, що ламають звичайний трафік; фільтр на рівні receive-accept зазвичай не ваша причина. Якщо Base Filtering Engine взагалі не працює, шукайте інде, бо більше ніщо не може застосовувати ці фільтри.

Перевірте й звичайний вигляд брандмауера, адже більшість дивиться лише один із двох:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Коли вбудовані профілі ввімкнені і жодне правило не збігається з трафіком, що не проходить, блокування йде від стороннього постачальника, а не від Windows Firewall. Ця різниця й визначає, який інструмент ви використаєте для ремонту.

Читайте правила Linux у тому синтаксисі, яким будете видаляти

iptables -S друкує правила в тій самій формі, у якій їх додавали, тож вивід можна одразу використати для видалення. iptables -L -v -n додає лічильники пакетів, і ці лічильники кажуть, чи правило справді збігається з вашими невдалими запитами, чи просто стоїть у ланцюжку.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Читайте політики ланцюжків, а не лише правила: -P OUTPUT DROP блокує трафік, навіть коли жодне правило не збігається. Перевіряйте IPv6 окремо, бо клієнт, що встановлює обидві родини, може залишити блокування IPv6 після зникнення правил IPv4, і тоді симптом залежить від того, якій родині надає перевагу застосунок. Там, де використовується nftables, запустіть і nft list ruleset; два інструменти співіснують через шар сумісності, і один список не обов’язково показує кожне правило, здатне відкинути пакет.

Видаліть найвужчий об’єкт, що пояснює збій

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Постійні фільтри — останній захід. Вони лежать під HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, по одному значенню на фільтр із ключем GUID. Спершу експортуйте ключ, запишіть GUID, які видаляєте, видаляйте лише значення, що належать клієнту, який пішов, потім перезавантажтеся, щоб двигун перебудував стан. Не видаляйте весь ключ і не вимикайте Base Filtering Engine: Windows Firewall і Defender залежать від нього, і ви обміняли б один збій на гірший.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

У Linux візьміть рядок, який надрукував iptables -S, і замініть -A на -D. Видалити одне знайдене правило краще, ніж очистити ланцюжок, бо ваша власна політика лишається недоторканою.

sudo iptables -D OUTPUT -p udp -j REJECT

Якщо drop міститься в ланцюжку, визначеному користувачем, спершу видаліть перехід до цього ланцюжка, а потім приберіть ланцюжок через -X. Встановлення політики ланцюжка в ACCEPT, поки правила drop ще є, допомагає лише пакетам, які взагалі доходять до рішення про політику. Очищення всіх таблиць — останній захід: воно видаляє й правила, додані вами з інших причин, а з увімкненим ufw лишає службу в переконанні, що вона володіє ланцюжками, яких уже немає.

Знайдіть власника, що повертає це на місце

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

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

Перевіряйте реальним трафіком, а не одним ping

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

Збережіть докази: експортований ключ BFE або вивід iptables -S, знятий до зміни. Перш ніж називати це виправленим, підтвердьте рівень, з якого ви видалили об’єкт, власника, який міг би встановити його знову, стан після одного чистого перезавантаження і те, що звичайний перегляд працює без запущеного процесу VPN. Сторінка довідки iptables(8) має точний синтаксис видалення й політики, якщо ви пишете очищення скриптом.