Чому kill switch обриває трафік під час зміни сервера

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

Що клієнт робить між двома серверами

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

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

Новій кінцевій точці потрібна діра в блокуванні

Щоб збудувати тунель, клієнт має надсилати пакети на адресу і порт нового сервера через фізичний інтерфейс, наприклад UDP 51820 для типового профілю WireGuard або 1194 і 443 для OpenVPN, що б не вказував ваш власний профіль. Цей трафік не знаходиться всередині тунелю, який щойно створюється, тому блокування для всього пристрою його ковтає, якщо немає відповідного правила дозволу.

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

Назви параметрів і значення за замовчуванням різняться залежно від клієнта і версії, тому читайте документований список для свого, а не вгадуйте зі скриншотів. Довідник налаштувань OpenVPN Connect за адресою openvpn.net/connect-docs/app-settings-windows — один із прикладів того, як клієнт описує свої параметри блокування і розділеного тунелю.

Fail-closed — це машина станів, а не перемикач

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

Механізм різниться за платформами, і збій також. Фільтри Windows Filtering Platform мають ваги, тому блокуючий фільтр, що переважує ваш дозвіл, продовжує відкидати пакети, хоча дозвіл існує, а фільтри, залишені вбитим процесом клієнта можуть тримати машину без мережі після того, як застосунок зник. Клієнти macOS зазвичай записують правила pf в якір, де порядок правил і швидкі рішення визначають, яке правило застосовується. Клієнти Linux зазвичай керують ланцюжком nftables або iptables з політикою drop і явними дозволами для кінцевої точки, інтерфейсу тунелю та loopback. Режим always-on VPN в Android з опцією блокування з'єднань без VPN — найсуворіший у групі, бо система застосовує блокування до всього пристрою, а не до окремого застосунку.

WireGuard потребує окремої примітки, бо AllowedIPs — це селектор маршрутизації, а не блокувальник. Він вирішує, які призначення потрапляють у тунель; він нічого не робить, щоб пакет без тунелю не вийшов через Wi-Fi. У конфігурації лише з WireGuard і без правила брандмауера kill switch насправді є відсутністю маршруту, і після відкинутого рукостискання через фізичний інтерфейс може вийти справжній пакет.

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

Стежте за пакетами, а не за індикатором стану. У Linux запустіть у одному терміналі повільний ping до публічної адреси, а в іншому перехопіть транспортний порт тунелю на фізичному інтерфейсі:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

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

У Windows netsh wfp show state записує знімок, у якому можна шукати блокуючі фільтри, що досі присутні, поки клієнт стверджує, що відключений. У macOS sudo pfctl -sr перелічує завантажені правила та їхній порядок. Зіставте будь-який знімок із власним журналом клієнта; хронологія вашого ping скаже, чи блокування закінчилося пізно, чи не закінчилося ніколи.

Звичайне затемнення проти завислого блокування

Певна перерва і є сенсом цієї функції, тому спершу оцініть ситуацію, а потім змінюйте будь-яке налаштування:

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

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