Бир убакта эки 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.
Анан адамдар өткөрүп жиберген кадамды жасаңыз: туннелди атайын токтотуңуз жана ийгиликсиз болушун күткөн трафиктин чын эле ийгиликсиз болушун ырастаңыз. Туташкан белгиче — интерфейс абалы, аткаруу эмес.
Кайсы учурда эки кардар туура эмес дизайн болот
Эгер экинчи колдонмонун артындагы жалгыз талап кошумча коргоо болсо, аны алып салыңыз. Өз ара аракеттенүүчү эки бөгөттөө саясаты бирөөнөн аз болжолдуу, ал эми ар бир кайра туташуу эч бир жеткирүүчү сынабаган абалга түшүү мүмкүнчүлүгү.
Эгер чын эле тизмектөө керек болсо, мисалы, коммерциялык секирүү аркылуу жетүүчү корпоративдик шлюз, бир гана аткаруу чекити бар дизайнды тандаңыз. Бул адатта бир демейки маршрут үчүн жарышкан эки иш такта колдонмосу эмес, тизмекти колдогон маршрутизатор же бир кардар дегенди билдирет. Башкарылуучу түзмөктө уруксат берилген кардарды кармаңыз жана калганын камтуудан тыш деп эсептеңиз, науада эмне көрсөтсө да.
Экөөнү тең кармаар алдындагы текшерүү тизмеси
Тизмени ирети менен аткарыңыз; ийгиликсиз болгон биринчи пункт — оңдолушу керек пункт.
- Демейки маршрут жана чечүүчү так бир кардарга таандык экенин ырастаңыз.
- Экинчи кардар ачык болушун кааласаңыз, анын серверинин акыркы чекитине ачык уруксат бериңиз жана ар бир кардар жаңыртуусунан кийин кайра текшериңиз.
- Туннелдердин бири кулаганда күтүлгөн натыйжаны жазып коюңуз жана дал ошол учурду сынап көрүңүз.
- Кайра иштеткенден кийин, иштетүү ирети башка болгондо бузулуу жолун текшериңиз.
- Башкарылуучу профилде токтоп, бир нерсе кошор алдында ээсинен сураңыз.
Эгер үчүнчү кадам ийгиликсиз болсо, акыйкат жооп — сизге бир гана кардар саясат берет. Кайсынысына ишенериңизди чечип, экинчисин коё бериңиз.