Бір уақытта екі 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сіз қосылымдарды бөгейтін жүйелік параметр. Android VPN нұсқаулығы платформа көзқарасын қаласаңыз, сол қызмет моделін сипаттайды.
Қамту — маңызды бөлік. „Тек 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.
Содан кейін адамдар өткізіп жіберетін қадамды жасаңыз: туннельді әдейі тоқтатыңыз және сәтсіз болуын күткен трафиктің шынымен сәтсіз болатынын растаңыз. Қосылған белгіше — интерфейс күйі, орындалу емес.
Қашан екі клиент дұрыс емес дизайн болады
Егер екінші қолданбаның артындағы жалғыз талап қосымша қорғаныс болса, оны алып тастаңыз. Өзара әрекеттесетін екі бөгеу саясаты біреуінен гөрі болжауға қиын, ал әр қайта қосылу ешбір жеткізуші сынамайтын күйге түсу мүмкіндігі.
Егер шын мәнінде тізбектеу керек болса, мысалы, коммерциялық секіріс арқылы жететін корпоративтік шлюз, бір ғана орындау нүктесі бар дизайнды таңдаңыз. Бұл әдетте бір әдепкі маршрут үшін жарысатын екі жұмыс үстелі қолданбасы емес, тізбекті қолдайтын маршрутизатор немесе бір клиент дегенді білдіреді. Басқарылатын құрылғыда рұқсат етілген клиентті ұстаңыз және қалғанының бәрін қамтудан тыс деп есептеңіз, науада не көрсетсе де.
Екеуін де ұстамас бұрын бақылау тізімі
Тізімді ретімен орындаңыз; сәтсіз болған бірінші тармақ — түзетілуі керек тармақ.
- Әдепкі маршрут пен шешуші нақты бір клиентке тиесілі екенін растаңыз.
- Екінші клиент ашық болуын қаласаңыз, оның серверінің соңғы нүктесіне анық рұқсат беріңіз және әр клиент жаңартуынан кейін қайта тексеріңіз.
- Туннельдердің бірі құлағанда күтілетін нәтижені жазып қойыңыз және дәл сол жағдайды сынап көріңіз.
- Қайта іске қосқаннан кейін, іске қосылу реті басқа болғанда ақау жолын тексеріңіз.
- Басқарылатын профильде тоқтаңыз және бірдеңе қоспас бұрын иесінен сұраңыз.
Егер үшінші қадам сәтсіз болса, адал жауап — сізге тек бір клиент саясат береді. Қайсысына сенетініңізді шешіңіз де, екіншісін жіберіңіз.