Nima uchun Android'da IKEv2 nostandart UDP portida ishlamaydi

Mahalliy IKEv2 shakli manzilni oladi, portni emas. Mijoz buni qo'llab-quvvatlashiga ishonch hosil qiling, serverning ikkala portini belgilang, so'ng ramkalash va jurnallarni ko'ring.

Shlyuz IKEv2 ga UDP 4443 da biron sababga ko'ra javob beradi, profilda Server nomli maydon bor, siz xost nomi va portni kiritasiz, telefon esa serverga yeta olmasligini yoki manzilni hal qila olmasligini bildiradi. Hech narsa bloklanmayapti. Android'ning mahalliy shakli xostni kutadi, Windows'da ham xuddi shunday. Moslashtirilgan port server sozlamasi bo'lishidan oldin mijoz imkoniyatidir va uni faqat ba'zi mijozlar ifodalashga ruxsat beradi. Uch qismni tartib bilan ko'rib chiqing: mijoz nima deya oladi, server nimani tinglaydi va ikki tomon paketlarni bir xil ramkalaydimi.

Telefon aslida nima yubordi

Nom uchun yaratilgan maydondagi host:port satri nom sifatida hal qilinadi. Hal qiluvchi vpn.example.net:4443 uchun hech narsa qaytarmaydi, va siz ko'rayotgan xato portda vaqt tugashi emas, balki nomni hal qilish yoki yetib bo'lmaslik xatosi. Bu farq muhim, chunki qisqaroq nom yoki boshqa tarmoq bilan qayta urinish shakl tahlil qila olmaydigan satrni hech qachon tuzatmaydi.

Android'dagi mahalliy IKEv2 profili, Windows'ning o'rnatilgan VPN mijozi kabi, standart IKE portlariga bog'langan. Hech biri port maydonini ko'rsatmaydi va profilni tahrirlash uni qo'shmaydi. Agar operatorning tinglovchisi haqiqatan 4443 da bo'lsa, o'rnatilgan mijoz noto'g'ri sozlangan emas, balki noto'g'ri asbobdir.

Portni ko'rsatadigan mijozdan foydalaning

strongSwan'ning Android mijozi kengaytirilgan profil sozlamalarida sozlanadigan server portini hujjatlashtiradi, shuning uchun bu dizayn uchun ishlaydigan deyarli har bir retseptda uchraydi. Bu qo'llab-quvvatlash o'sha mijozga tegishli: boshqa IKEv2 ilovasi yoki o'sha ilovaning yetkazib beruvchi forki asosiy strongSwan demoni qo'llab-quvvatlasa ham xuddi shu maydonni ko'rsatmasligi mumkin.

Operatordan butun to'plamni birato'la so'rang: shlyuz nomi, UDP porti, autentifikatsiya usuli va mijoz kutishi kerak bo'lgan server identifikatori. Moslashtirilgan port sertifikat tekshiruvini o'chirish yoki protokollarni almashtirish uchun sabab emas. Portni o'rnatilgan mijoz kutadigan joyga kiriting, va agar o'sha mijozda bunday maydon bo'lmasa, javob taxminiy chora emas, balki boshqa tasdiqlangan mijozdir.

Serverda ikki port bor va ikkalasi ham mos kelishi kerak

IKE UDP 500 da boshlanadi, NAT o'tishi esa odatda IKE va inkapsulyatsiyalangan ESP ni UDP 4500 ga ko'chiradi. Bular strongSwan'da alohida sozlamalar, shuning uchun bitta moslashtirilgan portga ko'chirilgan server ikkalasini ham bir xil qiymatga o'zgartirishi kerak:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Bitta port ikkala rolni bajarganda, demon o'sha soketda IKE ni ESP-in-UDP dan ajratishi kerak, buni IKE xabaridan oldin keladigan to'rt baytli ESP bo'lmagan belgi bilan qiladi. Shuning uchun mijoz moslashtirilgan portda kelishib, keyin 4500 da jimgina davom eta olmaydi, va shuning uchun “shunchaki portni almashtiring” iborasi ramkalash talabini yashiradi.

Yo'naltirish tinglovchi emas

4443 ni oddiy IKE tinglovchisiga yo'naltirish deyarli muvaffaqiyatli ko'rinadigan nosozlik usulidir. Birinchi almashinuv keladi, server javob beradi, so'ng aloqa to'xtaydi yoki kalitlarni hech narsaga yangilaydi, chunki javob boshqa portdan chiqadi va keyingi inkapsulyatsiyalangan trafik ikki tomon yaratgan holatga hech qachon mos kelmaydi. Tinglovchini ko'chirmasdan manzil portini qayta yozadigan qoida aynan shu yarim ochiq natijani beradi.

Yo'l UDP ni ham uchidan uchiga ruxsat berishi kerak. TCP 443 ning mehmonxona yoki operator tarmog'idan o'tishi UDP portidagi IKEv2 haqida hech narsa demaydi, raqam bir xil bo'lsa ham. Faqat TCP 443 ruxsat etilgan joyda moslashtirilgan UDP port IKEv2 ni HTTPS ga aylantirmaydi va to'g'ri javob yana bir port tajribasi emas, balki boshqa kirish yo'li bo'lishi mumkin.

Sinov paytida uch bosqichni ajrating

Mijoz bir marta urinayotganda serverda yozib oling. Hech qachon kelmaydigan so'rov oxirgi nuqta yoki tarmoq devori masalasi; javobsiz keladigan so'rov tinglovchi yoki siyosat masalasi; javobdan keyin sukunat kelishi ramkalash yoki identifikatsiya masalasi.

tcpdump -ni eth0 -vv udp port 4443

So'ng mijozning aylanuvchi ko'rsatkichi emas, uning xabarini o'qing. Taklif xatosi algoritmlar mos kelmasligini bildiradi, autentifikatsiya muvaffaqiyatsizligi identifikatorlar yoki sertifikatlar mos kelmasligini bildiradi, va javobsiz takroriy qayta yuborishlar o'sha portda hech narsa javob bermayotganini bildiradi. Bir vaqtda bitta bosqichni sinab ko'ring va urinishlar orasida bitta maydonni o'zgartiring; NAT o'tishi haqidagi strongSwan hujjatlari yozib olish sizga ko'rsatayotgan belgi va port xatti-harakatini tavsiflaydi.

O'xshash maqolalar