Дві програми VPN одночасно: який kill switch справді діє?
Другий клієнт VPN ніколи не успадковує kill switch першого. Яка політика діє, вирішують три умови — і як перевірити свою.
Два клієнти VPN можуть працювати поруч, але їхні kill switch не зливаються в одну політику. Кожен клієнт встановлює правила для свого тунелю, і жоден не знає про існування іншого. Я натрапив на це, коли першим був підключений робочий клієнт: друга програма не могла завершити рукостискання, десять хвилин висіла на «Connecting», а перший тунель тихо ніс усе. Чи буде друга програма захищена, залежить від трьох умов, а не від того, чи обидві іконки кажуть Підключено.
На що насправді поширюється kill switch
В операційній системі немає єдиного прапорця kill switch. Клієнт, який його рекламує, встановлює набір правил: відкидати все, що не виходить через мій тунель, і часто fail closed, коли тунель зникає. У Linux це зазвичай ланцюг nftables або iptables, у Windows набір фільтрів Windows Filtering Platform, в Android і iOS власна маршрутизація тунельної служби плюс системне налаштування, яке блокує з’єднання без VPN. Посібник з VPN для Android описує цю модель служби, якщо потрібен погляд платформи.
Обсяг — це те, що має значення. Правило на кшталт «дозволяти лише пакети на вихідному інтерфейсі wg0» не цікавиться, чи існує другий тунель. Якщо інший клієнт підніме wg1, правила першого клієнта вважатимуть ці пакети звичайним трафіком: зазвичай відкинуть, іноді пропустять. Так чи інакше вирішує перший клієнт, і він гадки не має, що друга програма чекає.
Три умови, які вирішують, хто буде під захистом
Перебирати всі комбінації не потрібно. Три запитання вирішують справу за кілька хвилин.
- Чи допускає платформа другий тунель узагалі? Більшість телефонів на Android і iPhone приймають лише одну активну службу VPN на профіль користувача, тож друга програма ніколи не має тунелю й нічого не контролює. Ви отримуєте одну політику — від програми, яка зайняла місце.
- Який процес володіє маршрутом за замовчуванням? Windows, macOS і Linux спокійно несуть два тунелі. Маршрут за замовчуванням належить тому клієнту, який налаштував його останнім або з кращою метрикою, а другий клієнт підключений, але простоює. У Linux режим маршруту за замовчуванням у wg-quick використовує маршрутизацію за політикою з приватною таблицею та правилом fwmark, тому другий тунель wg-quick додає конкуруюче правило, а не замінює перше.
- Чи може другий клієнт дістатися до свого сервера? Якщо перший kill switch працює за принципом «заборонено за замовчуванням», зовнішня кінцева точка другої програми — просто ще одна відкинута адреса. Воно мовчки повторює спроби й ніколи не повідомляє про помилку.
Коротка версія для гілок підтримки:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Два з цих рядків виглядають однаково з іконки в треї, тому іконка тут — найгірший з доступних доказів.
Що ламається першим і як це виглядає
Клієнт, який застряг на «Connecting», коли другий здоровий, — майже завжди голод за кінцевою точкою: робочий kill switch відкидає рукостискання другого клієнта до його власного сервера. Перевірте це дешево, призупинивши блокувальні правила першого клієнта на одну спробу. Якщо другий підключається одразу, запитання закрите.
DNS — друга відмова. Клієнти налаштовують конфігурацію резолвера для свого інтерфейсу, а деякі просто перезаписують глобальний список. Коли підняті обидва тунелі, запити можуть виходити через одну сторону, поки резолвер належить іншій. Відключіть будь-яку програму — і той, хто вижив, залишиться з недоступним сервером імен: сторінки зависають на хвилину й потім знову розв’язуються, а VPN усе ще показує підключення.
Третій — миготіння маршрутів. Перепідключення перевпорядковують маршрут за замовчуванням, а kill switch, прив’язаний до інтерфейсу, за ним не йде. Трафік, який мить тому був у тунелі, тепер підпадає під правило відкидання, і для користувача це виглядає як VPN, що випадково перестає працювати.
Перевірте, яка політика діє насправді
Робіть це з безпечним трафіком, а не з тим, чого вам буде шкода.
У Linux запитайте ядро, хто перемагає і до чого прив’язаний брандмауер. ip -4 route show default називає тунель, що володіє виходом. ip rule show показує, чи задіяна маршрутизація за політикою. sudo nft list ruleset | grep -n oifname показує, чи прив’язані скидання до назви інтерфейсу, мітки або всього вихідного ланцюга.
У Windows та сама історія живе в метриці маршруту й списку фільтрів: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric і Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". У macOS — netstat -rn -f inet | head -5 і scutil --dns | head -20.
Потім зробіть крок, який люди пропускають: навмисно зупиніть тунель і переконайтеся, що трафік, який має зламатися, справді ламається. Підключена іконка — це стан інтерфейсу, а не забезпечення правил.
Коли два клієнти — неправильний дизайн
Якщо єдина вимога до другої програми — більше захисту, приберіть її. Дві взаємодійні політики блокування менш передбачувані, ніж одна, і кожне перепідключення — шанс опинитися в стані, який не тестує жоден постачальник.
Якщо вам справді потрібен ланцюжок, наприклад корпоративний шлюз через комерційний хоп, обирайте схему з єдиною точкою контролю. Зазвичай це маршрутизатор або один клієнт, що підтримує ланцюжок, а не дві настільні програми, які змагаються за той самий маршрут за замовчуванням. На керованому пристрої тримайтеся санкціонованого клієнта, а все інше вважайте поза межами, що б воно не показувало в треї.
Контрольний список перед тим, як залишити обидва
Пройдіть список по порядку; перший не пройдений пункт і треба виправляти.
- Переконайтеся, що рівно один клієнт володіє маршрутом за замовчуванням і резолвером.
- Якщо хочете, щоб другий клієнт працював, дозвольте явно кінцеву точку його сервера й перевіряйте після кожного оновлення клієнта.
- Запишіть очікуваний результат при падінні будь-якого тунелю й перевірте саме цей випадок.
- Перевірте шлях відмови після перезавантаження, коли порядок запуску інший.
- На керованому профілі зупиніться й запитайте власника, перш ніж щось додавати.
Якщо третій крок не проходить, чесна відповідь така: політику дає лише один клієнт. Вирішіть, якому довіряєте, і відпустіть другий.