Bir vaqtda ikkita VPN ilovasi: qaysi kill switch haqiqatan amal qiladi?
Ikkinchi VPN mijozi hech qachon birinchisining kill switch’ini meros olmaydi. Qaysi siyosat amal qilishini uch shart hal qiladi va siznikini qanday tekshirish mumkin.
Ikki VPN mijozi yonma-yon ishlashi mumkin, ammo ularning kill switch’lari yagona siyosatga birlashmaydi. Har bir mijoz o’z tuneli uchun qoidalar o’rnatadi va hech biri ikkinchisining borligini bilmaydi. Men buni avval ish mijozi ulangan holatda uchratdim: ikkinchi ilova qo’l berib ko’rishishni yakunlay olmadi, o’n daqiqa „Connecting“ holatida qoldi va birinchi tunnel hamma narsani jimgina olib yurdi. Ikkinchi ilova himoyalanishi uch shartga bog’liq, ikkala ikonka Ulangan deyishiga emas.
Kill switch aslida nima bilan cheklangan
Operatsion tizimda bitta kill switch bayrog’i yo’q. Bunday narsani reklama qilgan mijoz qoidalar to’plamini o’rnatadi: tunelimdan chiqmaydigan hamma narsani tashla va tunnel yo’qolganda ko’pincha fail closed ish tut. Linuxda bu odatda nftables yoki iptables zanjiri, Windowsda Windows Filtering Platform filtrlari to’plami, Android va iOSda tunnel xizmatining o’z yo’naltirishi hamda VPNsiz ulanishlarni bloklaydigan tizim sozlamasi. Android VPN qo’llanmasi platforma nuqtai nazarini istasangiz, o’sha xizmat modelini tasvirlaydi.
Qamrov eng muhim qismdir. „Faqat wg0 chiqish interfeysidagi paketlarga ruxsat ber“ kabi qoida ikkinchi tunnel bor-yo’qligiga e’tibor bermaydi. Boshqa mijoz wg1ni ko’tarsa, birinchi mijozning qoidalari bu paketlarni oddiy trafik deb qabul qiladi: odatda tashlanadi, ba’zan ruxsat beriladi. Har holda qaror qiluvchi birinchi mijozdir va ikkinchi ilova kutayotganidan bexabar.
Kim qamrab olinishini hal qiluvchi uch shart
Har bir kombinatsiyani sanab chiqish shart emas. Uch savol buni bir necha daqiqada hal qiladi.
- Platforma umuman ikkinchi tunnelga ruxsat beradimi? Aksariyat Android telefonlar va iPhone’lar foydalanuvchi profili bo’yicha faqat bitta faol VPN xizmatini qabul qiladi, shuning uchun ikkinchi ilova hech qachon tunnelga ega bo’lmaydi va hech narsani ta’minlamaydi. Siz bitta siyosat olasiz: joyni yutgan ilovadan.
- Standart marshrut qaysi jarayonga tegishli? Windows, macOS va Linux ikkita tunnelni bemalol ko’taradi. Standart marshrut uni oxirgi bo’lib yoki yaxshiroq metrika bilan sozlagan mijozga tegishli, ikkinchi mijoz esa ulangan, ammo bo’sh. Linuxda wg-quick’ning standart marshrut rejimi xususiy jadval va fwmark qoidasi bilan siyosat asosidagi yo’naltirishdan foydalanadi, shuning uchun ikkinchi wg-quick tunnel birinchisini almashtirish o’rniga raqobatchi qoida qo’shadi.
- Ikkinchi mijoz o’z serveriga yeta oladimi? Agar birinchi kill switch standart rad bo’lsa, ikkinchi ilovaning tashqi so’nggi nuqtasi shunchaki yana bir tashlangan manzildir. Jimgina qayta urinadi va hech qachon xato haqida xabar bermaydi.
Qisqa versiya, qo’llab-quvvatlash mavzulari uchun:
| 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 |
Bu satrlardan ikkitasi tizim patnisidagi ikonkadan bir xil ko’rinadi, shuning uchun ikonka bu yerda mavjud eng yomon dalildir.
Birinchi nima buziladi va u qanday ko’rinadi
Boshqasi sog’lom bo’lganda „Connecting“da tiqilib qolgan mijoz deyarli har doim so’nggi nuqta ochligidir: ishlab turgan kill switch ikkinchi mijozning o’z serveriga qo’l berib ko’rishishini tashlaydi. Buni arzon yo’l bilan tekshirish uchun birinchi mijozning bloklash qoidalarini bitta urinish uchun to’xtatib turing. Ikkinchisi darhol ulansa, savol javob topgan.
DNS ikkinchi nosozlikdir. Mijozlar hal qiluvchi konfiguratsiyasini o’z interfeysi uchun o’rnatadi va ba’zilari global ro’yxatning ustiga shunchaki yozib yuboradi. Ikkala tunnel ham ochiq bo’lganda so’rovlar bir tomondan chiqishi mumkin, hal qiluvchi esa boshqa tomonga tegishli bo’ladi. Ilovalardan birini uzing va omon qolgani yetib bo’lmaydigan nom serverini saqlab qoladi: sahifalar bir daqiqa tiqilib qoladi, so’ng yana hal qilinadi, VPN esa hali ham ulangan ko’rinadi.
Uchinchisi marshrut tebranishidir. Qayta ulanishlar standart marshrutni qayta tartiblaydi va interfeysga bog’langan kill switch unga ergashmaydi. Bir lahza oldin tunnel ichida bo’lgan trafik endi tashlash qoidasiga mos keladi, bu esa foydalanuvchi tomonida tasodifan ishlashdan to’xtagan VPN kabi o’qiladi.
Qaysi siyosat haqiqatan kuchda ekanini tekshiring
Buni zararsiz trafik bilan qiling, achinadigan narsangiz bilan emas.
Linuxda yadrodan kim g’alaba qozonishini va xavfsizlik devori nimaga bog’lanishini so’rang. ip -4 route show default chiqishga ega tunnelni nomlaydi. ip rule show siyosat asosidagi yo’naltirish o’yinda yoki yo’qligini ko’rsatadi. sudo nft list ruleset | grep -n oifname tashlashlar interfeys nomiga, belgiga yoki butun chiqish zanjiriga bog’langanini ko’rsatadi.
Windowsda xuddi shu hikoya marshrut metrikasida va filtrlar ro’yxatida yashaydi: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric va Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOSda netstat -rn -f inet | head -5 va scutil --dns | head -20.
Keyin odamlar tashlab ketadigan qadamni bajaring: tunnelni ataylab to’xtating va muvaffaqiyatsiz bo’lishini kutgan trafik haqiqatan muvaffaqiyatsiz bo’lishini tasdiqlang. Ulangan ikonka interfeys holatidir, ijro emas.
Qachon ikkita mijoz noto’g’ri dizayn hisoblanadi
Agar ikkinchi ilova ortidagi yagona talab ko’proq himoya bo’lsa, uni olib tashlang. O’zaro ta’sir qiluvchi ikkita bloklash siyosati bittadan kamroq bashorat qilinadi va har bir qayta ulanish hech bir sotuvchi sinamaydigan holatga tushish imkoniyatidir.
Agar haqiqatan zanjirlash kerak bo’lsa, masalan, tijorat sakrashi orqali erishiladigan korporativ shlyuz, bitta ijro nuqtasi bo’lgan dizaynni tanlang. Bu odatda bir xil standart marshrut uchun kurashayotgan ikkita ish stoli ilovasi emas, zanjirni qo’llab-quvvatlaydigan router yoki bitta mijoz demakdir. Boshqariladigan qurilmada ruxsat etilgan mijozni saqlang va qolgan hamma narsani qamrovdan tashqarida deb hisoblang, patnisda nima ko’rsatsa ham.
Ikkalasini ham saqlashdan oldin tekshiruv ro’yxati
Ro’yxatni tartib bilan ishlang; muvaffaqiyatsiz bo’lgan birinchi band tuzatilishi kerak bo’lgan banddir.
- Standart marshrut va hal qiluvchi aniq bitta mijozga tegishli ekanini tasdiqlang.
- Agar ikkinchi mijoz ochiq bo’lishini istasangiz, uning serverining so’nggi nuqtasiga aniq ruxsat bering va har bir mijoz yangilanishidan keyin qayta tekshiring.
- Tunnellardan biri tushganda kutilgan natijani yozib qo’ying va aynan o’sha holatni sinab ko’ring.
- Qayta ishga tushirgandan keyin, ishga tushish tartibi boshqacha bo’lganda nosozlik yo’lini tekshiring.
- Boshqariladigan profilda to’xtang va biror narsa qo’shishdan oldin egasidan so’rang.
Agar uchinchi qadam muvaffaqiyatsiz bo’lsa, halol javob shuki, sizga faqat bitta mijoz siyosat beradi. Qaysi biriga ishonishingizni hal qiling va ikkinchisini qo’yib yuboring.