Android always-on VPN: endpoint nomi nega birinchi hal qilinadi
Android tunnel paydo bo'lishidan oldin trafikni bloklaydi, lekin klient baribir o'z endpointini hal qilishi kerak. Mana tartib va tiqilib qoladigan joy.
Telefon qayta ishga tushadi, always-on yoqilgan, «VPNsiz ulanishlarni bloklash» yoqilgan, ammo tunnel hech qachon ko'tarilmaydi. Hech narsa noto'g'ri sozlanmagan: bloklash o'z ishini qilmoqda, va klientning o'z endpointiga yetishga urinishi ham unga bo'ysunadi. Endpoint nomi tunnel paydo bo'lishidan oldin hal qilinishi kerak, boshqa barcha ilovalarga ruxsat berilmaganda tarmoq bilan gaplashishga ruxsat etilgan klient tomonidan. Qaysi komponent buni qilishini va qanday tartibda qilishini tushunish bu jumboqni konfiguratsiya savoliga aylantiradi.
VPN quruvchisi aslida nimani talab qiladi
Android VPN ilovasi platformaga server manzilini bermaydi. U mahalliy interfeys quradi: tunnel uchun manzillar va marshrutlar, ilovalar ichida ishlatishi kerak bo'lgan rezolverlar, so'ngra establish() ilova xom IP paketlar sifatida o'qiydigan va yozadigan fayl deskriptorini qaytaradi. Uzoq endpoint bu quruvchida umuman ko'rinmaydi.
Bu asosiy tuzilmaviy fakt. Platforma tun interfeysini yaratadi va unga siyosatni qo'llaydi; ilova transportni foydalanuvchi maydonida amalga oshiradi, ya'ni endpoint nomini o'zi hal qiladi va shifrlangan ulanishni o'zi ochadi. Shuning uchun xost nomi ko'rinishidagi endpoint mumkin — platforma nomlarni qo'llab-quvvatlagani uchun emas, platforma endpointni hech qachon ko'rmagani uchun.
Quruvchining bitta maydoni baribir manzillarni qabul qiladi: DNS serverlari. Ular raqamli rezolver manzillari bo'lishi kerak, odatda operator tunnel orqali so'ramoqchi bo'lganlari. Bu maydon tunnel ko'tarilgandan keyin ilovalar so'rovlarni qayerga yuborishini tasvirlaydi. U klient endpointni qanday topishi haqida hech narsa aytmaydi, va bu ikkalasini bir xil sozlama deb qarash chalkashlikning boshlanishi.
Bitta emas, ikkita DNS savoli
Birinchi savol: tunnel ko'tarilgandan keyin ilovalar so'rovlarni qayerga yuboradi? Javob tunnel ichidagi rezolver manzili, tun interfeysi orqali yetib boriladigan va tuzilishi bo'yicha raqamli.
Ikkinchi savol: klient o'z endpointini shu tunnel paydo bo'lishidan oldin qanday topadi? Bu qidiruv tunnel tashqarisida, asosiy tarmoqda, klient jarayonida sodir bo'ladi. U nomdan foydalanishi mumkin va qurilma VPNsiz yetib boradigan rezolverdan foydalanishi shart.
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
Uch bosqich, uch xil alomat. «Ulanish mumkin emas» degan bitta xato xabari ularni bir joyga qo'shib yuboradi, shuning uchun odamlar o'sha maydon o'qilishidan oldin sodir bo'ladigan muammoni tuzatish uchun DNS server maydonini tahrirlashni boshlaydi.
Nega bootstrap tiqilib qolishi mumkin
Always-on va bloklash yoqilgan bo'lsa, VPN ichida bo'lmagan trafik tashlab yuboriladi, jumladan VPNga ega ilovaning trafigi ham. Chiqish yo'li aniq: ilova soketda protect() chaqiradi, bu uni asosiy tarmoqqa bog'laydi, shuning uchun u tunnelni chetlab o'tib, tashqariga chiqishga ruxsat oladi. Har bir VPN klienti buni o'z transporti uchun qilishi kerak, aks holda serverga hech qachon yetib bormaydi.
Endi endpoint nomini biladigan yagona rezolverning o'zi tunnel ichida bo'lgan joylashtirishni ko'rib chiqaylik. Klientga nomni hal qilish uchun tunnel, tunnelni qurish uchun nom kerak. Bu haqiqiy aylanma bog'liqlik, va hech qanday klient konfiguratsiyasi uni hal qilmaydi. Bu dizayn xatosi, bag emas.
Vaqt o'sha bog'liqlikni yumshoqroq shakllarda ochib beradi. Yuklanish paytida, birinchi qulfdan chiqarishdan oldin, qurilmada hali ishlatib bo'ladigan tarmoq bo'lmasligi mumkin; captive portalda tarmoq bor, lekin portaldan boshqa hamma narsani bloklaydi; Wi-Fi'dan uyali tarmoqqa o'tishda himoyalangan soketning asosiy tarmog'i o'zgaradi va klient buni payqab, qaytadan hal qilishi kerak. Bulardan har biri bootstrap hodisasi, va har birini tungi 3 da topishdan ko'ra ataylab sinab ko'rish kerak.
Nega javobni qotirib qo'yish yechim emas
Vasvasali aylanma yo'l — nomni bir marta hal qilib, olingan manzilni raqamli maydonga yopishtirish yoki uni maxsus buildda qattiq kodlash. Bu ishlayotganga o'xshaydi va nomni suratga aylantiradi. Operator endpointni ko'chirganda — migratsiya, anycast o'zgarishi, yangi mintaqaviy manzil — klient eskisiga qo'ng'iroq qilishda davom etadi va UI'da hech narsa sababini tushuntirmaydi.
DNS yozuvlarida yashash muddati borligi javoblar o'zgarishi mumkinligi uchun; kesh shu muddatga asoslanadi, abadiy emas. Javobni qotirish nomni manzildan afzal qiladigan mexanizmni tashlab yuboradi, ayni paytda nom ishlatishning operatsion xarajatini saqlab qoladi.
Qotirish odatda ikkinchi yomon odat bilan birga keladi: ulanish endi boshqacha muvaffaqiyatsiz bo'lgani uchun identifikatsiya tekshiruvini yumshatish. Server identifikatsiyasini tekshirish bootstrap muammosining bir qismi emas, va uni zaiflashtirish DNS noqulayligini ushlab qolish xavfiga almashtiradi.
Qayta yuklashga chidaydigan dizaynlar
Barqaror yechim dabdabali emas. Himoyalangan soketlarni to'g'ri amalga oshiradigan va endpointini asosiy tarmoqda hal qiladigan klientdan foydalaning, va unga ochiq yoki tunnelgacha yetib boriladigan rezolver orqali hal qilinadigan endpoint nomini bering. Bloklashni yoqilgan holda qoldiring; DNS ishlashi uchun uni butunlay o'chirish joylashtirish mavjud bo'lgan xususiyatni olib tashlaydi.
Endpoint maxfiy qolishi kerak bo'lgan joyda platforma foydalana oladigan aniq bootstrap yo'lini taqdim eting — tunnelsiz yetib boriladigan rezolver yoki operator qo'llab-quvvatlaydigan boshqaruv ulanishi — va bu istisnoni tor va foydalanuvchi tugmasi emas, siyosatga tegishli qilib saqlang. Android VpnService hujjatlari himoya va hayot sikli bo'yicha platforma nima kafolatlashining manbasi, va VpnService.Builder havolasi DNS maydoni raqamli manzillarni qabul qilishini tasdiqlaydi.
So'ngra qayta yuklashdan keyingi yangi ulanishda uch bosqichni tartib bilan tekshiring: endpoint nomi hal qilinadi, tunnel o'rnatiladi va hamkor autentifikatsiya qilinadi, maxfiy nom tunnel rezolveri orqali hal qilinadi. Birinchi bosqich muvaffaqiyatsiz bo'lsa, keyingi hech narsa ishlamaydi va tuzatish bootstrap yo'liga tegishli — hech qachon rezolver maydoniga emas.
- Endpointni hal qilish ilova ichida, tunnel tashqarisida, himoyalangan soketda sodir bo'ladi.
- Quruvchidagi DNS maydoni tunnel ichidagi ilovalar uchun, klientning o'z endpointi uchun emas.
- Faqat tunnel orqali yetib boriladigan rezolver tiqilish, sekin start emas.
- Qayta yuklashdan keyin endpoint, autentifikatsiya va maxfiy qidiruvni alohida sinang.