Чи переживає аварійний вимикач VPN перезавантаження? Як це перевірити

Перезавантаження — найпоширеніший спосіб, у який люди перевіряють аварійний вимикач, і саме цей тест найчастіше бреше. Прапорець у клієнті — лише налаштування; важливо, чи щось застосовує блокування між моментом, коли мережевий стек піднімається, і моментом, коли тунель справді встановлено. У Windows цим чимось зазвичай є фільтр у Windows Filtering Platform, у Linux — набір правил, який завантажує юніт, у macOS — якір pf, в Android — власні прапорці системи для постійного підключення та блокування. Ці рішення поводяться дуже по-різному під час перезавантаження, і лише рішення на рівні платформи перебувають на місці до того, як хтось зможе увійти.

Перезавантаження ставить три окремі питання

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

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

Знайдіть об’єкт, який відновлює блокування

У Linux правила netfilter живуть у ядрі. Ніщо не записує їх назад під час завантаження, якщо ви це не влаштували: iptables-save плюс netfilter-persistent, nftables.service завантажує /etc/nftables.conf, або юніт systemd, який виконує ваш власний скрипт. Перевірте, що ввімкнено, а не те, що ви пам’ятаєте як налаштоване.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Друга команда записує wfpstate.xml у поточний каталог. Шукайте фільтри з дією блокування, які вже існують до підключення клієнта. Base Filtering Engine запускається рано під час завантаження і відновлює фільтри, додані з постійним прапорцем, тому одні аварійні вимикачі блокують трафік ще до появи будь-якого вікна клієнта, а інші ні. У macOS sudo pfctl -s info повідомляє, чи ввімкнено pf, sudo pfctl -s rules показує, що завантажено, а клієнти VPN зазвичай прикріплюють свої правила до якоря, а не до основного набору. Правило, яке називає utun3, після наступного завантаження може вказувати на інший інтерфейс, бо цей номер призначається під час роботи.

Стежте за розривом між підйомом мережі та підйомом тунелю

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

На хостах із systemd читайте порядок, а не вгадуйте його. Виконайте systemctl cat на юнітах VPN і міжмережевого екрана і пошукайте After= або Before= щодо network-pre.target і network-online.target. Юніт міжмережевого екрана, упорядкований після network-online.target, програє інтерфейсу; той, який потрібен і впорядкований до network-pre.target, виграє. У Windows еквівалентні питання — тип запуску служби та її залежності, бо служба, встановлена як Manual, не може блокувати процес під час завантаження. Якщо ваша вимога охоплює трафік до входу, її задовольняє лише рішення на рівні пристрою: тунель пристрою Always On VPN автентифікується сертифікатом машини і підключається до того, як користувач увійде, і Microsoft документує конфігурацію тунелю пристрою окремо від користувацького тунелю. Android іде іншим шляхом, примусово вмикає VPN і блокує з’єднання без нього з боку системи, а не з процесу застосунку.

Виконайте тест, потім порівняйте дві шкали часу

Перезавантажтеся з призначенням, яке нічого не коштує, якщо витече, і фіксуйте стан під час розриву, а не після нього. Найчистіший метод — зонд часу завантаження: юніт oneshot або заплановане завдання, яке запускається якнайраніше, записує маршрут за замовчуванням і стан міжмережевого екрана, пробує один запит із коротким тайм-аутом і додає рядок до локального файлу. Порівняйте цей запис із часом запуску служби VPN з journalctl -b -u або системного журналу.

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

Закрийте розрив, не відрізаючи собі шлях назад

Якщо під час завантаження блокування немає, опустіть застосування на рівень нижче замість додавання другого правила клієнта. Збережіть набір правил і завантажуйте його з юніта, впорядкованого до того, як мережа стане придатною, і переконайтеся, що цьому юніту не потрібні DNS-запит або мережеве монтування, які він має захищати. Обсяг важливий не менше часу: правила, що збігаються за ID користувача або cgroup, залишають кожен системний демон поза блокуванням, а набір, який обробляє лише IPv4, залишає IPv6 і DNS доступними.

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

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