TLSni tekshiruvchi proksi ortidagi SSTP: sessiya qayerda uziladi

Brauzeringiz korporativ intranetni yuklaydi, proksi sertifikati ishonchli, ammo SSTP mijozi ulanish oxirida uzilib qoladi. Bu namuna noto‘g‘ri parolni emas, veb-so‘rov bilan tunnel sessiyasi orasidagi farqni ko‘rsatadi. Ulanishni TCPdan yuqoriga qarab kuzatib, birinchi muvaffaqiyatsiz bosqichni belgilang. Proksi sababmi yoki yo‘qmi, buni xato kodi emas, bosqich aytadi.

Mijoz to‘xtagan joydan boshlang

Mijoz qat’iy ketma-ketlikdan o‘tadi: 443 portiga TCP ulanishi, TLS qo‘l siqish, sertifikatni tekshirish, SSTP ning HTTP almashinuvi, PPP muzokarasi va autentifikatsiya, so‘ngra IP konfiguratsiyasi. Har bir bosqichdagi nosozlik boshqa iz qoldiradi va ularni aralashtirish sizni noto‘g‘ri sozlash sahifasiga olib boradi.

TCP nosozligi har qanday TLS bayti paydo bo‘lishidan oldingi kutish yoki qayta o‘rnatishdir. TLS nosozligi ogohlantirish yoki qo‘l siqish kutishidir. Sertifikat nosozligi zanjir yoki nom haqida ogohlantirish beradi. HTTP nosozligi muvaffaqiyatli qo‘l siqishdan keyin keladi, ko‘pincha holat kodi yoki darhol yopilish sifatida. PPP nosozligi tunnel texnik jihatdan o‘rnatilgandan keyin keladi, shuning uchun u autentifikatsiya muammosiga o‘xshaydi.

Birinchi xato satri emas, mijoz jurnalida oxirgi muvaffaqiyatli bosqichni o‘qing. Xato satri odatda oqibatni xabar qiladi, bosqich chegarasi esa rad etgan komponentni nomlaydi.

SSTP tarmoqdan nima tashishni talab qiladi

SSTP TCP 443 da TLS ustida ishlaydi va so‘ngra SSTP spetsifikatsiyasida belgilangan SSTP_DUPLEX_POST nomli HTTP so‘rovini /sra_{GUID}/ shaklidagi yo‘lga yuboradi. So‘rov amalda cheksiz kontent uzunligini e’lon qiladi va sessiyaning butun umri davomida oqimni ikki tomonga ochiq tutadi. PPP kadrlari shu oqim ichida harakatlanadi.

Shu sababli oddiy ko‘rishni boshqaradigan proksi ham muvaffaqiyatsiz bo‘lishi mumkin. Chekli tanali GET yoki POST buferga olinishi, tekshirilishi va uzatilishi mumkin; hech qachon tugamaydigan tanali ikki tomonlama oqim esa yo‘q. Tana tugashini kutayotgan proksi abadiy kutadi va mijoz oxir-oqibat vaqt tugashiga uchraydi.

Usullarni filtrlash va autentifikatsiya o‘z nosozlik usullarini qo‘shadi. Agar proksi so‘rov uchun hisob ma’lumotlarini so‘rasa, brauzer javob beradigan holatda VPN mijozi javob bermasligi mumkin. Agar u usulni olib tashlasa yoki qayta yozsa, shlyuz PPP boshlanishidan oldin so‘rovni rad etadi.

Nega tekshirish identifikatsiyani o‘zgartiradi

TLSni tekshiruvchi proksi mijozning TLS ulanishini tugatadi va shlyuzga alohida ulanish ochadi. Shuning uchun mijoz shlyuzning emas, proksining sertifikatini tekshiradi va shlyuz proksini o‘z sherigi deb biladi. Tashkilot o‘z ildizini tarqatganda, brauzer ham, VPN mijozi ham bu zanjirni qabul qilishi mumkin, shu bois qo‘l siqish muvaffaqiyatli bo‘ladi va muammo keyingi bosqichga o‘tadi.

Muvaffaqiyatli tekshirish proksi sessiyani tashiy oladi degani emas. U hali ham buferlashsiz cheksiz ikki tomonlama POSTni uzatishi va ikkala ulanishni soatlab tirik ushlab turishi kerak. Ko‘plab tekshirish mahsulotlari so‘rov-javob trafigi uchun qurilgan va bu holatni yomon yoki umuman hal qilmaydi.

Shu sababli noma’lum ildiz qo‘shish yoki tekshirishni o‘chirish noto‘g‘ri tuzatishdir. U mijoz qaysi sertifikatni qabul qilishini o‘zgartiradi; sessiyani haqiqatda buzgan oqim bilan ishlashga hech narsa qilmaydi.

Sozlamalarni o‘zgartirishdan oldin chiqaruvchini aniqlang

Yakuniy nuqtadan qaysi sertifikatni taqdim etishini va unga kim imzo chekkanini so‘rang. Quyidagi buyruqlar VPN sessiyasini boshlamasdan zanjir va chiqaruvchini ko‘rsatadi:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Agar chiqaruvchi ommaviy CA bo‘lsa, bu xost uchun ulanish ushlanmayotgan bo‘ladi va nosozlik boshqa joyda. Agar chiqaruvchi tashkilotning o‘z CA si bo‘lsa, tekshirish faol va shlyuzga proksi orqali yetib boriladi. Faqat nomga qarab xulosa qilishdan oldin barmoq izini tarmoq jamoasi kutgan iz bilan solishtiring.

Xuddi shu xostga brauzer sinovi faqat proksi GETni qabul qilishini isbotlaydi. U SSTP usuli, so‘rov URI si yoki tananing umri haqida hech narsa aytmaydi, shuning uchun ishlayotgan intranet sahifasini tunnel yo‘li qo‘llab-quvvatlanishing isboti deb hisoblamang.

Qo‘llab-quvvatlanadigan yo‘lni tanlang

Tarmoq egasiga bitta aniq savol bering: proksi bu shlyuzga 443 portida buferlanmagan ikki tomonlama POSTga ruxsat beradimi? Ha deyilsa, proksida istisno yoki VPN xosti uchun hujjatlashtirilgan chetlab o‘tish. Yo‘q deyilsa, tekshirilgan yo‘l SSTPni tashiy olmaydi va qo‘llab-quvvatlanadigan tuzatish mijozni burish emas, boshqa yo‘l yoki protokoldir.

Variantlar odatda VPN shlyuzi uchun tekshirilmagan chiqish, proksi orqali faqat korporativ trafikni yuboradigan bo‘lingan tunnel dizayni yoki tashkilot boshqa portda qo‘llab-quvvatlaydigan muqobil protokolni o‘z ichiga oladi. Har biri tarmoq dizayniga tegishli va taqqoslash yo‘lni ajratishi uchun har birini bir xil qurilma va profil bilan sinash kerak.

Natijani hujjatlashtiring: chiqaruvchi, muvaffaqiyatsiz bosqich, proksi qoidasi va tanlangan yo‘l. Keyingi odam xuddi shu 98 foizlik to‘xtashni ko‘rganda butun yo‘lni takrorlash o‘rniga bitta faktni tekshira oladi.