Kill switch блокує VPN-сервер ще до того, як піде будь-який трафік
Який етап блокує kill switch: пошук кінцевої точки, зовнішній маршрут, зворотний шлях і застарілі винятки для партнерів — з лічильниками замість здогадок.
Kill switch дають збій у напрямку, якого люди не очікують: вони створені блокувати трафік, поки тунель опущений, а пакети, що будують тунель, самі є трафіком. У цьому вся помилка. Набір правил, що відкидає все, що не виходить через тунель, відкидає й рукостискання, яке мало його підняти, тому клієнт повторює в циклі, а помилка приписується тому етапу, який перевіряється першим. Перш ніж розширювати міжмережевий екран, з'ясуйте, який із трьох етапів відхиляється: пошук імені, зовнішній пакет до партнера чи відповідь, що повертається.
Як тунель і його власний транспорт залежать один від одного
Читайте VPN-клієнт як два стани мережі, що ділять один шлях сокета. Поки тунелю немає, клієнт відкриває сокет на фізичному адаптері й надсилає зашифровані кадри на адресу та порт партнера. Лише після успіху цього обміну він створює тунельний пристрій і встановлює маршрути. Kill switch — це політика про другий стан, написана так широко, що діє на обидва.
Правила на основі інтерфейсу — звичайна форма: приймайте те, що виходить через tun0 або wg0, відкидайте решту вихідного шляху. Таке формулювання не може виключити власне з'єднання клієнта із сервером, тому коректна реалізація додає цей виняток явно, і ви також, коли пишете правила вручну. Правила за застосунками в Windows і macOS обходять частину цього, зіставляючи процес, а не інтерфейс, але процес усе одно має вийти до того, як тунель з'явиться.
Три етапи в тому порядку, у якому вони відбуваються
Перший етап — розв'язання імені. Коли профіль зберігає ім'я хоста замість буквальної адреси, клієнту потрібна відповідь DNS, перш ніж щось надіслати. Профіль, що спрямовує DNS до розв'язувача тунелю, створює глухий кут: розв'язувач доступний лише через тунель, який пошук мав увімкнути. Розв'язання поза тунелем або прив'язка кінцевої точки до адреси знімають цю двозначність.
Другий етап — зовнішній пакет, який має пережити спочатку маршрутизацію, а потім міжмережевий екран, саме в такому порядку. wireguard-tools виконує маршрутну половину цього для WireGuard: позначає власні пакети й додає правило політики, щоб вони оминали щойно встановлений маршрут за замовчуванням; сторінка підручника wg-quick описує це правило й таблицю, яку воно використовує. Відновіть цю маршрутизацію вручну або дозвольте другому інструменту переписати правила, і позначені пакети можуть бути відправлені назад у тунель, який вони мали створити.
Третій етап — зворотний шлях. Рукостискання без відповіді не доводить відкидання на виході; воно так само узгоджується з вхідним правилом сервера або пристроєм NAT, що забув зіставлення. Розділіть це, перш ніж чіпати клієнт.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Клієнти записують виявлений симптом, а не етап, що зазнав невдачі, тому таблиця зазвичай швидша за журнал.
Лічильники вирішують швидше за журнали
У Linux, nft list ruleset або iptables -vnL OUTPUT друкує лічильник пакетів для кожного правила. Підключіться один раз, дозвольте збій, потім знову прочитайте лічильники. Правило, лічильник якого зсунувся, — це правило, у яке влучило рукостискання; якщо ніде нічого не зсунулося, пакет так і не дійшов до міжмережевого екрана. Я бачив, як набір правил відкинув власне рукостискання, і про це сказали лише лічильники.
Щоб відрізнити «ніколи не дійшов до міжмережевого екрана» від «ніколи не покинув хост», спостерігайте за самим інтерфейсом. ip -s link show dev wlan0 повідомляє про надіслані пакети, а tcpdump -ni wlan0 udp port 51820 показує кадри. Якщо він лишається пласким, поки клієнт повторює спроби, несправність вище netfilter: бракує маршруту до партнера, правило політики вказує на пристрій, якого ще немає, або помилка сокета, яку клієнт ковтає.
Перевіряйте винятки на документаційних адресах, як-от 203.0.113.10, щоб помилка не могла прощупати чужий хост.
Застарілий виняток кінцевої точки читається як збій сервера
Найбільш оманлива версія з'являється після того, як адреса партнера змінилася: служба динамічних адрес перемістила її, хост перебудували, або вихідна адреса вашої мережі інша. Виняток досі називає стару адресу, тому пакети до нової потрапляють під правило відкидання. Та сама конфігурація працювала вчора, і саме тому люди починають із діагностики сервера.
Ім'я хоста всередині правила міжмережевого екрана вас не врятує. У nftables ім'я розв'язується під час завантаження набору правил, тому воно закріплює ту адресу, яка існувала в цей момент, і застаріває, як буквальна. Стале рішення — оновлювати виняток, коли кінцева точка змінюється, і тримати його вузьким: одна адреса партнера, один транспортний порт. Діапазон, достатньо широкий, щоб пережити зміну адреси, достатньо широкий і для того, щоб випустити сторонній трафік.
Коли kill switch працює на хості сервера
Та сама залежність є на іншому кінці, і там її легше проґавити. Якщо машина, що слугує вашим VPN-сервером, також запускає настільний клієнт із kill switch або профіль міжмережевого екрана, скопійований з ноутбука, його правила відкидання діють на службу, що завершує тунелі. Відповіді на рукостискання клієнта відкидаються, тому кожен клієнт не може підключитися, поки сервер виглядає здоровим, а його тунельний інтерфейс простоює.
Цьому хосту потрібні три вузькі дозволи перед відкиданням: порт прослуховування на фізичному інтерфейсі, тунельний інтерфейс для розшифрованого трафіку й пересилання з тунелю до того, чого клієнти мають досягати. Прочитайте встановлений набір за допомогою nft list ruleset, iptables -S, або pfctl -sr , перш ніж щось змінювати, і пам'ятайте, що збережений набір правил переживає перезавантаження, тому помилка там переживає процес, який її створив.
Порядок відновлення, що тримає машину закритою
Працюйте від профілю назовні. Прочитайте адресу й порт партнера, які використовує клієнт, підтвердьте, що ім'я хоста розв'язується без тунелю, а потім додайте один виняток для цієї адреси й порту лише на фізичному адаптері. Підключіться знову й спостерігайте за лічильником надсилання; завершене рукостискання — сигнал, що другий етап виправлено.
Залиште решту політики відкидання на місці під час перевірки. Нешкідлива перевірка — спробувати з'єднання зі сторонньою документаційною адресою й переконатися, що воно досі завершується тайм-аутом, що показує: kill switch працює, а не вимкнений. Затягніть виняток, коли тунель стане стабільним, і не залишайте постійного дозволу всього для клієнтської програми лише тому, що це зручно.
Якщо тунель піднімається, а застосунок усе одно зазнає невдачі, решта етапів — не цей: розділений DNS, MTU і маршрутизація за застосунками кожен дають підключений тунель зі зламаним трафіком, і кожен має свою першу перевірку.