Always-on VPN чи kill switch: що ви насправді ввімкнули?

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

Перевірка 1: блокування — це окремий перемикач?

На Android 10 і новіших збережений профіль VPN відкриває за значком шестерні два незалежні перемикачі: Always-on VPN і Block connections without VPN. Лише другий і є kill switch. З одним always-on тунель справді повертається після обриву, а будь-який застосунок посеред запиту може вийти в мережу через Wi-Fi або мобільні дані, поки це не станеться.

Керовані пристрої зберігають той самий поділ в API політик. setAlwaysOnVpnPackage() приймає назву пакета й прапорець lockdownEnabled; адміністратор, який задав пакет і залишив прапорець false, збудував постійний тунель, а не закритий пристрій. Формулювання в консолі рідко робить цю різницю видимою.

Читайте стан з пристрою, а не з консолі: adb shell settings get global always_on_vpn_app і adb shell settings get global always_on_vpn_lockdown. Якщо перша повертає null, на рівні платформи не нав'язано жодного пакета; якщо друга повертає 0, платформа нічого не блокує. Посібник з VPN для Android описує це як окремі можливості, а не один режим.

Перевірка 2: який шар володіє блокуванням?

Написи живуть у клієнті, а блокування зазвичай у міжмережевому екрані, тому те саме слово на кожній платформі означає інше. Рядки нижче варто підтвердити, перш ніж вірити будь-якому з них.

Windows — найясніший приклад напису, який не блокує. Там Always On описує стійкість тунелю: тунель пристрою для автентифікації машини й користувацький тунель для облікового запису, що ввійшов, налаштовані через XML профілю або Add-VpnConnection. Ніщо в цьому профілі не зупиняє вихідний пакет, коли тунелю немає, а вихідна фільтрація типово не ввімкнена, тому ноутбук у Wi-Fi продовжує працювати, поки VPN лежить.

WireGuard ділиться так само, але за клієнтом. WireGuard for Windows має параметр Block untunneled traffic для кожного тунелю, який ставить правила фільтра; інструменти Linux такого перемикача не мають. wg-quick додає маршрут для кожного запису AllowedIPs і правило fwmark, а wg-quick down видаляє обидва, тож фізичний маршрут за замовчуванням знову бере роботу на себе, не втративши жодного пакета.

На платформах Apple always-on приходить як функція профілю керування для контрольованих пристроїв і виражається правилами on-demand, а не прапорцем. Питання, на яке треба відповісти з корисного навантаження: чи невдалий тунель відмовляє в трафіку, чи лише просить інше з'єднання. Назва пункту меню про це не скаже.

Перевірка 3: міряйте проміжок, а не значок

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

Найдешевша перевірка навмисно зупиняє тунель і потім намагається вийти. Коли тунель лежить, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com, що повертає 200, означає, що політика fail-open; тайм-аут або відмова в з'єднанні означають, що щось усе ще блокує. ip route get 1.1.1.1 називає інтерфейс, який поніс би пакет, і це зазвичай інформативніше за значок у лотку, а systemctl status wg-quick@wg0 показує, чи інтерфейс прибрано охайно.

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

Перевірка 4: визначте винятки до того, як замикати

Два винятки структурні. Клієнт мусить дістатися до самого сервера VPN, тому набір правил, що відкидає все, заважає й перепідключенню, яке повернуло б захист. Captive portal теж недоступний через тунель, який не піднято, тож заблокованому пристрою в готельному Wi-Fi потрібен задокументований спосіб відкрити портал, а не імпровізований.

Мінімальна форма: кінцева точка дозволена, усе інше відкинуто:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Ставтеся до цього рядка кінцевої точки як до змінної, а не константи. Провайдери змінюють адреси, і застарілий виняток — звична причина, чому робочий kill switch стає пристроєм, який не може перепідключитися. Локальні принтери, спільні ресурси NAS і сервіси розробки належать до того самого записаного списку, інакше їх виявляють по одному зверненню до підтримки.

Перевірка 5: запишіть, що ви насправді довели

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

Перш ніж вважати це завершеним:

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