Две 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.
Потоа направете го чекорот што луѓето го прескокнуваат: намерно запрете го тунелот и потврдете дека сообраќајот што очекувате да не успее навистина не успева. Поврзана икона е состојба на интерфејсот, не спроведување.
Кога два клиенти се погрешен дизајн
Ако единственото барање зад втората апликација е повеќе заштита, отстранете ја. Две политики за блокирање што дејствуваат една на друга се помалку предвидливи од една, и секое повторно поврзување е шанса да завршите во состојба што ниту еден добавувач не ја тестира.
Ако навистина ви треба ланчено поврзување, на пример корпоративен гејтвеј преку комерцијален хоп, изберете дизајн со една точка на спроведување. Тоа обично значи рутер или еден клиент што го поддржува ланцот, а не две десктоп апликации што се натпреваруваат за истата стандардна рута. На управуван уред држете се до одобрениот клиент, а сето друго третирајте како вон опсег, што и да покажува во тацната.
Контролна листа пред да ги задржите двата
Поминете ја листата по ред; првата ставка што откажува е таа што треба да се поправи.
- Потврдете дека точно еден клиент ја поседува стандардната рута и резолверот.
- Ако сакате вториот клиент да работи, дозволете изречно крајната точка на неговиот сервер и проверувајте повторно по секое ажурирање на клиентот.
- Запишете го очекуваниот исход кога паѓа кој било тунел и тестирајте го токму тој случај.
- Проверете ја патеката на отказ по рестарт, кога редоследот на стартување е различен.
- На управуван профил застанете и прашајте го сопственикот пред да додадете нешто.
Ако третиот чекор не успее, искрениот одговор е дека само еден клиент ви дава политика. Одлучете кому му верувате и пуштете го другиот.