SSTP avval serverni, keyin foydalanuvchini autentifikatsiya qiladi

SSTP mijozi TLSni tugatib, bir soniyadan keyin foydalanuvchini baribir rad etishi mumkin. Bu ketma-ketlik xato emas, bu protokol steki: avval transport xavfsizligi, keyin foydalanuvchi autentifikatsiyasi. Ikki bosqich turli xabarlar bilan muvaffaqiyatsiz bo'lgani uchun ularga turli tuzatishlar ham kerak. Xatoni qaysi bosqich keltirib chiqarganini o'qish diagnostikaning katta qismidir.

Ishonchli sertifikat oxirgi nuqtani isbotlaydi; hisob haqida u hech narsa demaydi.

TLS qo'l siqishi nimani belgilaydi

Mijoz server taqdim etgan sertifikatni o'z ishonch omboriga, so'ralgan xost nomiga, amal qilish oynasiga va platforma qo'llaydigan har qanday qo'shimcha siyosatga nisbatan tekshiradi. Bu mo'ljallangan oxirgi nuqtaga ulanishni himoya qiladi. Lekin ma'lum hisob yoqilgan, muddati o'tmagan yoki masofaviy kirishga ruxsat berilganligini isbotlamaydi. Bu boshqa komponent keyinroq so'raydigan alohida savollardir.

Shuning uchun kirish so'roviga yetish uchun sertifikat tekshiruvlarini olib tashlash noto'g'ri tuzatishdir. Siz tekshira olmaydigan ulanishda kirish so'rovini olasiz. Sertifikat xatosi xost nomiga, soatga, zanjirga yoki ishonch konfiguratsiyasiga tegishli.

SSTP va PPP ustiga nima qo'shadi

SSTP HTTPS ustida ishlaydi va ichida PPP tashiydi, ulanish atrofida o'z boshqaruv almashinuvi bilan. Keyin PPP o'zining ulanish va autentifikatsiya bosqichlarini bajaradi, autentifikatsiya usuli esa server siyosati va mijoz imkoniyatlariga bog'liq. PAP, CHAP, MS-CHAPv2 va EAP — barchasi juda har xil xususiyatlarga ega PPP autentifikatsiya variantlari. VPNning foydalanuvchini tekshirishi — aynan shu PPP bosqichi, uning ostidagi TLS qatlami emas.

Shuning uchun foydalanuvchini rad etish hisob ma'lumotlari, hisob cheklovi yoki usul nomuvofiqligini bildirishi mumkin.

Server tomonidagi sabab profildagi har bir sirni qayta o'rnatishdan ancha foydaliroq. Hisob o'chirilgan hodisasi va usul muzokaralarining muvaffaqiyatsizligi mijozda o'xshash ko'rinadi va serverda ularning umumiy joyi yo'q.

Xatoni bosqichga bog'lang

Ulanish TLSga, keyin SSTP HTTP almashinuviga, keyin PPP bosqichiga yetishini tekshiring. Qayta urinishlar orasida jurnallarning vaqt belgilarini tekislab turing, shunda oldingi muvaffaqiyatsizlik keyingi muvaffaqiyat bilan aralashmasin. Bitta oynada ikki urinishni qayd etadigan mijoz aks holda yetgan oxirgi bosqichda muvaffaqiyatsiz bo'lgandek ko'rinadi. Oxirgi satrni emas, birinchi muhim xatoni o'qing.

Xuddi shu tekislash server tomonida ham muhim, u yerda autentifikatsiya yozuvi va transport jurnali ko'pincha alohida soatlarga ega alohida fayllardir. Ikki daqiqalik farq aniq sababni imkonsiz ko'rsatish uchun yetarli.

Kirgandan keyin ham avtorizatsiya alohida

Muvaffaqiyatli kirish har bir shaxsiy resursga ruxsat bermaydi. Marshrutlar nima yetib borish mumkinligini, DNS nima hal qilinishini belgilaydi va har bir xizmat hali ham o'z ruxsatlarini qo'llaydi. Ulangan deb ko'rsatilgan sessiya tunnel haqidagi bayonot, fayl almashish haqida emas. Foydalanuvchi ulana olsa-yu, bitta xostga yeta olmasa, tunnel bosqichi allaqachon tugagan.

Bu qo'l siqishi ko'rsatgan o'sha qatlamlanish, bir daraja yuqori.

Hisobni tiklashni operator qo'llab-quvvatlaydigan jarayon ichida saqlang, foydalanuvchining aniq rad etishiga javoban transport sozlamalarini o'zgartirish o'rniga. O'chirilgan hisobni tuzatish uchun transportni o'zgartirish — hisob aloqasiz sabab bilan qayta yoqilganda ishlagandek ko'rinadigan tuzatish turi.