Дзве праграмы 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.
Потым зрабіце крок, які людзі прапускаюць: наўмысна спыніце тунель і пераканайцеся, што трафік, які мае зламацца, сапраўды ламаецца. Падключаная іконка — гэта стан інтэрфейса, а не забеспячэнне правілаў.
Калі два кліенты — няправільны дызайн
Калі адзінае патрабаванне да другой праграмы — больш аховы, прыбярыце яе. Дзве ўзаемадзейныя палітыкі блакавання менш прадказальныя, чым адна, і кожнае перападключэнне — шанц апынуцца ў стане, які не тэстуе ні адзін пастаўшчык.
Калі вам сапраўды патрэбны ланцужок, напрыклад карпаратыўны шлюз праз камерцыйны хоп, выбірайце схему з адзінай кропкай кантролю. Звычайна гэта маршрутызатар або адзін кліент, які падтрымлівае ланцужок, а не дзве настольныя праграмы, якія змагаюцца за той самы маршрут па змаўчанні. На кіраванай прыладзе трымайцеся санкцыянаванага кліента, а ўсё астатняе лічыце па-за межамі, што б яно ні паказвала ў трэі.
Кантрольны спіс перад тым, як пакінуць абодва
Прайдзіце спіс па парадку; першы непройдзены пункт і трэба выпраўляць.
- Пераканайцеся, што роўна адзін кліент валодае маршрутам па змаўчанні і рэзалверам.
- Калі хочаце, каб другі кліент працаваў, дазвольце яўна канцавую кропку яго сервера і правярайце пасля кожнага абнаўлення кліента.
- Запішыце чаканы вынік пры падзенні любога тунеля і праверце менавіта гэты выпадак.
- Праверце шлях адмовы пасля перазагрузкі, калі парадак запуску іншы.
- На кіраваным профілі спыніцеся і спытайце ўладальніка, перш чым нешта дадаваць.
Калі трэці крок не праходзіць, сумленны адказ такі: палітыку дае толькі адзін кліент. Вырашыце, якому давяраеце, і адпусціце другі.