Два 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, правила првог клијента третирају те пакете као обичан саобраћај: обично одбачене, понекад дозвољене. У сваком случају одлучује први клијент и нема појма да друга апликација чека.

Три услова која одлучују ко ће бити покривен

Не морате да набрајате сваку комбинацију. Три питања то решавају за неколико минута.

1. Дозвољава ли платформа уопште други тунел? Већина Android телефона и iPhone уређаја прихвата само једну активну VPN услугу по корисничком профилу, тако да друга апликација никада нема тунел и ништа не спроводи. Добијате једну политику — од апликације која је освојила место.
2. Који процес поседује подразумевану руту? Windows, macOS и Linux мирно носе два тунела. Подразумевана рута припада клијенту који ју је подесио последњи или са бољом метриком, а други клијент је повезан али неактиван. На Linux-у режим подразумеване руте у wg-quick користи рутирање по политици са приватном табелом и fwmark правилом, тако да други wg-quick тунел додаје конкурентско правило уместо да замени прво.
3. Може ли други клијент да дође до сопственог сервера? Ако је први kill switch подразумевано одбијање, спољна крајња тачка друге апликације је само још једно одбачено одредиште. Поново покушава тихо и никада не пријављује грешку.

Кратка верзија, за теме подршке:

Два од тих редова изгледају исто са иконе у системској касети, зато је икона најгори доступни доказ овде.

Шта прво отказује и како то изгледа

Клијент заглављен на „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.

Затим урадите корак који људи прескачу: намерно зауставите тунел и потврдите да саобраћај који очекујете да не успе заиста не успе. Повезана икона је стање интерфејса, не спровођење.

Када су два клијента погрешан дизајн

Ако је једини захтев иза друге апликације више заштите, уклоните је. Две политике блокирања које делују једна на другу мање су предвидиве од једне, и свако поновно повезивање је шанса да завршите у стању које ниједан добављач не тестира.

Ако вам заиста треба ланчано повезивање, на пример корпоративни гејтвеј преко комерцијалног хопа, изаберите дизајн са једном тачком спровођења. То обично значи рутер или један клијент који подржава ланац, а не две десктоп апликације које се такмиче за исту подразумевану руту. На управљаном уређају држите се одобреног клијента, а све остало третирајте као ван обима, шта год оно показивало у системској касети.

Контролна листа пре него што задржите оба

Прођите листу по реду; прва ставка која не прође је она коју треба исправити.

• Потврдите да тачно један клијент поседује подразумевану руту и резолвер.
• Ако желите да други клијент ради, дозволите изричито крајњу тачку његовог сервера и проверите поново после сваког ажурирања клијента.
• Запишите очекивани исход када падне било који тунел и тестирајте баш тај случај.
• Проверите пут отказа после рестарта, када је редослед покретања другачији.
• На управљаном профилу зауставите се и питајте власника пре него што било шта додате.

Ако трећи корак не прође, искрен одговор је да вам политику даје само један клијент. Одлучите коме верујете и пустите други.