Serverga qulflangan profil TLS proksisi orqasida ishlamaydi: qaysi avlod?
Access Server 2.8 va 2.9 serverga qulflangan profillarni turlicha quradi. Old qismni o'zgartirishdan oldin proksingiz qaysi yo'lni buzishini aniqlang.
Bir foydalanuvchi ulanadi, boshqasi esa yo'q, bir xil portal orqali, bir xil kunda. Ikkalasida ham serverga qulflangan profil bor, ikkalasi ham bir xil Access Server buildida, va yagona farq — ularning profili qachon yaratilgan. Bu tanib olishga arziydigan naqsh, chunki "serverga qulflangan" ulanish tartibini emas, siyosatni nomlaydi. Access Server o'sha artefaktning ikki avlodini chiqargan, va TLS teskari proksisi ularning faqat bitta yo'li oldida turadi. Qaysi shoxda ekaningizni uch shart hal qiladi.
Ikki avlod, ikki ulanish tartibi
2.8 gacha amal qiladigan eski dizaynda import qilingan fayl psevdoprofil. OpenVPN Connect uni HTTPS orqali Access Server veb API oldida autentifikatsiya qilish uchun ishlatadi, vaqtinchalik foydalanuvchiga qulflangan profil va sessiya tokenini oladi, va shundan keyingina VPN o'rnatadi. Ikki transport ketma-ket ishlaydi, birinchisi oddiy veb so'rov.
2.9 bilan kiritilgan format har bir ulanish uchun bu boshlang'ich yuklashni bajarmaydi. Bu mos OpenVPN mijozlar foydalanishi mumkin bo'lgan mahalliy profil, faqat OpenVPN Connect emas. Uni yuklab olish yoki URL orqali import qilish hali ham HTTPSni o'z ichiga olishi mumkin — bu e'lon qilish bosqichi, har bir ulanish uchun vaqtinchalik profil olish emas.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
Yangilash allaqachon chiqarilgan profillarni albatta qayta yozmaydi, shuning uchun joriy server versiyasi hali ham eski artefaktni tarqatishi mumkin. Server buildi nima mumkinligini aytadi, bu foydalanuvchi nima import qilganini emas.
Shoxingizni tanlaydigan uch shart
Birinchi shart — artefaktning avlodi. Faylni so'rang, u qanday yaratilganini ko'ring va uni import qilgan mijoz versiyasini yozib oling. Agar avlodni fayldan aniqlay olmasangiz, sinov hisobi uchun chiqarilgan yangi profil server bugun nima ishlab chiqarishini aytadi, va bu muvaffaqiyatsiz foydalanuvchidagi ma'lumotdan farq qiladi.
Ikkinchisi — old qismingiz aslida nimani tugatadi. TLSni tushiradigan yettinchi qatlam HTTP teskari proksisi to'rtinchi qatlam TCP yo'naltirgichi bilan bir xil obyekt emas, UDP yo'naltirgichi ham emas. Access Serverning 443 portidagi odatiy joylashuvi OpenVPN TCP demonini brauzer trafigini taniy va veb xizmatlarga berishga majbur qiladi, shuning uchun oldiga aloqasiz HTTPS tugatgichini qo'yish o'sha demonning protokol ishlovini saqlab qolmaydi. 443 raqamini bo'lishish ikki dizaynni tenglashtirmaydi.
Uchinchisi — muvaffaqiyatsizlik qayerga tushadi. VPN oldidagi xato va boshqaruv kanali xatosi faqat "ulanmoqda" deydigan mijozda o'xshash ko'rinadi, lekin ular izlarni turli joylarda qoldiradi. Agar eski format ishda bo'lsa, boshlang'ich yuklash nomzod. Agar yangi format ishda bo'lsa, bo'sh veb kirish jurnali kutiladi va hech qaysi tomonga hech narsani isbotlamaydi.
Artefakt eski bo'lganda: boshlang'ich yuklash birinchi bo'lib muvaffaqiyatsiz bo'ladi
Mijozning yakuniy holatini emas, haqiqiy xatosini o'qing. Qiziqarli maydonlar — HTTPS xatosi, mijoz kutgan server identifikatori, so'rov borgan manzil, va sertifikat tekshiruvi tugaganmi. Keyin ularni server tomonidagi veb xizmat va proksi jurnallari bilan solishtiring.
Brauzerning kirish sahifasiga yetishi bu mijozning API autentifikatsiyasi muvaffaqiyatli o'tganiga dalil emas. Bu turli so'rovlar, turli sertifikat kutilmalari va ko'pincha turli xost nomlari bilan. Agar portal to'g'ri xizmat qilsa-yu, mijoz hali ham muvaffaqiyatsiz bo'lsa, kelishmovchilik boshlang'ich yuklash yo'lida, foydalanuvchi parolida emas.
TLS tekshiruvini o'chirish yoki autentifikatsiya siyosatini yumshatish bilan solishtirishni o'tkazmang. Bu tashxis qilish mumkin bo'lgan konfiguratsiya nomuvofiqligini ishlaydigan, ammo tekshirilmagan yo'lga aylantiradi, va aynan shu o'zgarish vaqtinchalik sinovni doimiy teshikka aylantiradi. Access Serverning ulanish profillari bo'yicha hujjati ikkala avlodni va vaqtinchalik profil oqimini tasvirlaydi, va proksini ayblashdan oldin tekshirilishi kerak bo'lgan manba shu.
Artefakt yangi bo'lganda: o'rniga boshqaruv kanalini o'qing
2.9 uslubidagi profil bilan mijoz to'g'ridan-to'g'ri mahalliy VPN yakuniy nuqtasiga boradi. Profildagi yakuniy nuqtalarni, ishlatilayotgan transportni va boshqaruv kanali xatosini o'rganing. Agar mijoz hech qachon HTTP so'rov yubormasa, bu dizaynga mos keladi va simptom emas.
Bu yerda proksi savoli ham shaklini o'zgartiradi. HTTPS tushirish hech qachon ko'rmaydigan faqat TCP oqimini buza olmaydi, lekin profilni e'lon qiladigan yuklab olishni hali ham buzishi mumkin, va faqat TCP yo'naltirgichi UDPni umuman tashimaydi. Old qism ahamiyatsiz deb xulosa qilishdan oldin profil qaysi transportni talab qilishini tekshiring.
Bitta oqim uchun TLS o'tkazish tor tartib. U UDP uzatishni ta'minlamaydi va demonning 443dagi o'z xizmat uzatish xatti-harakatini qayta ishlab chiqarmaydi. Agar old qismingiz shulardan birini qilsa, qaysi birini ayting, chunki chora boshqacha.
Tor bo'lib qoladigan choralar
Eng kam aralashadigan tekshiruv — sinov hisobi uchun yangi qo'llab-quvvatlanadigan profil yaratish va bir xil autentifikatsiya talablari bilan mo'ljallangan mahalliy yakuniy nuqta orqali ulanish. Agar u ishlasa, saqlangan eski profil esa ishlamasa, siz bir qadamda artefaktni serverdan va proksidan ajratdingiz.
Foydalanuvchiga qulflangan profilni tarqatish eski boshlang'ich yuklashga bog'liqlikni butunlay olib tashlaydi, chunki muvaffaqiyatsiz bo'lishi mumkin bo'lgan vaqtinchalik profil almashinuvi yo'q. U mo'ljallangan foydalanuvchiga berilishi kerak, hech qachon administratoridan ko'chirilmasligi kerak, va mijozning nimalarga vakolatli ekanini o'zgartiradi, shuning uchun uni vaqtinchalik chora emas, siyosat qarori sifatida ko'ring.
Keyin e'lon qilish tartibini har bir kerakli yo'l mavjud bo'ladigan qilib tuzating: yuklab olishlar va portaldan foydalanish uchun veb yo'l, va profillar kutgan transportdagi mahalliy VPN yo'l. Proksining ishini bir qatlamda saqlang. Ishlaydigan foydalanuvchiga qulflangan tunnel o'sha yo'l ishlashini isbotlaydi; u har bir proksi tartibi har bir avlodni qo'llab-quvvatlashini isbotlamaydi, va eski boshlang'ich yuklash xatosi yangi formatni qoralamaydi.
- Proksiga tegishdan oldin artefaktning avlodini aniqlang.
- Muvaffaqiyatsizlik tunnel oldida yoki uning ichida sodir bo'lishini aniqlang.
- Old qism nima tugatishini tasdiqlang: HTTP, TCP oqimi yoki UDP.
- Siyosat o'zgarmagan holda yangi chiqarilgan profilni mahalliy yakuniy nuqtaga qarshi sinab ko'ring.