Две 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 е default-deny, външната крайна точка на второто приложение е просто още една изхвърлена дестинация. То опитва отново тихо и никога не съобщава грешка.
Кратката версия, за теми в поддръжката:
| 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 все още показва свързано.
Третото е flapping на маршрутите. Повторните свързвания пренареждат маршрута по подразбиране, а 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.
След това направете стъпката, която хората пропускат: спрете тунела нарочно и потвърдете, че трафикът, който очаквате да се провали, наистина се проваля. Свързаната икона е състояние на интерфейса, не налагане.
Кога два клиента са грешен дизайн
Ако единственото изискване зад второто приложение е повече защита, премахнете го. Две взаимодействащи блокиращи политики са по-малко предвидими от една и всяко повторно свързване е шанс да попаднете в състояние, което никой доставчик не тества.
Ако наистина ви трябва верижно свързване, например корпоративен шлюз, достигнат през търговски скок, изберете дизайн с една точка на налагане. Това обикновено означава рутер или един клиент, който поддържа веригата, а не две настолни приложения, които се състезават за същия маршрут по подразбиране. На управлявано устройство задръжте одобрения клиент и третирайте всичко останало като извън обхвата, каквото и да показва в трея.
Контролен списък, преди да задържите и двете
Минете списъка по ред; първият елемент, който се провали, е този за поправяне.
- Потвърдете, че точно един клиент притежава маршрута по подразбиране и резолвера.
- Ако искате вторият клиент да работи, разрешете изрично крайната точка на неговия сървър и проверявайте отново след всяка актуализация на клиента.
- Запишете очаквания резултат, когато някой от тунелите падне, и тествайте точно този случай.
- Проверете пътя на отказа след рестарт, когато редът на стартиране е различен.
- На управляван профил спрете и попитайте собственика, преди да добавите каквото и да е.
Ако третата стъпка се провали, честният отговор е, че само един клиент ви дава политика. Решете на кой вярвате и пуснете другия.