Brauzer HTTPS muvaffaqiyatli bo'lgan joyda SSTP muvaffaqiyatsiz bo'ladi: nima uchun
SSTP 443-portda TLS ichida ishlaydi, ammo bu veb-so'rov emas. TCP, TLS identifikatsiyasi, SSTP almashinuvi va PPP autentifikatsiyasini alohida bosqichlar sifatida sinab ko'ring.
Brauzer VPN xost nomini HTTPS orqali hech qanday shikoyatsiz ochadi, ammo SSTP mijozi hali ham ulanishdan bosh tortadi. Bu juftlikda hech qanday ziddiyat yo'q. SSTP TLS-ni tashqi transport sifatida ishlatadi va keyin o'sha ulanish ichida o'z so'rovini va PPP yukini bajaradi, shuning uchun sahifaning muvaffaqiyatli yuklanishi faqat bitta tor narsani isbotlaydi: xost 443-portda GET so'roviga javob beradi. Mijoz boshqa savol berayapti, server unga yomon javob berishi mumkin.
Sahifa yuklanadi, tunnel esa yo'q
Odamlar brauzer sinoviga murojaat qiladi, chunki u tez, so'ngra natijani serverning yetib borilishi va sozlanganligi isboti deb qabul qiladi. Bu manzil qatori ochgan yo'lga GET haqidagi isbot, ortiq emas. VPN suhbati o'sha TLS qo'l berishidan keyin boshlanadi, ammo yuboradigan narsa veb-sahifa hech qachon ishlatmaydigan usul va yo'l. Shuning uchun brauzerga berilgan 200 javobi SSTP oxirgi nuqtasi bor-yo'qligi haqida hech narsa demaydi.
Ikki kuzatuvni ajrating va qidiruv qisqaradi. Transport va sertifikat zanjiri ishlaydi, ular ustidagi protokol almashinuvida nimadir ishlamaydi. Bu buzilgan port yoki muddati o'tgan sertifikatdan boshqa tekshiruv va boshqa dalillarni talab qiladi.
SSTP mijozi aslida nima yuboradi
Mijoz /sra_{GUID}/ yo'liga SSTP_DUPLEX_POST usuli bilan HTTP so'rov yuboradi, so'ngra ulanish tanasini PPP freymlarini tashuvchi ikki tomonlama oqim sifatida ochiq ushlab turadi. Tegishli server HTTP/1.1 200 deb javob beradi va veb-server kabi harakat qilishni to'xtatadi. Qolgan hamma narsa imzo: 405 yoki 404 oxirgi nuqta yo'qligini, 301 yoki 302 nimadir so'rovni qayta yo'naltirayotganini, darhol FIN esa proksi yoki server oqimni yopganini bildiradi.
Shuning uchun maqsad TLS sertifikati biriktirilgan veb-server emas, SSTP serveri bo'lishi kerak. Usul, yo'l va uzoq umrli tana protokol talablari, shuning uchun teskari proksi ularni faqat konfiguratsiya bilan qo'sha olmaydi. Oddiy HTTPS-ni mukammal uzatuvchi proksi ham o'zi tanimaydigan usulni rad etishi mumkin.
Proksi yoki veb-server oqimni qayerda buzadi
Vositachi biror narsani uzatishdan oldin HTTP so'rov satrini tekshiradi va g'ayrioddiy yo'li bo'lgan moslashtirilgan usul uning qoidalariga tushmay qolishi mumkin. Ba'zi qurilmalar oddiy sahifani taqdim etib, tunnelni rad etadi yoki to'xtatadi, shuning uchun mijoz toza rad etish o'rniga boshlanib keyin o'ladigan ulanish haqida xabar beradi. Boshqalari so'rovni qabul qiladi, so'ngra PPP keepalive-lari chiday olmaydigan tana yoki bo'sh turish muddatini qo'llaydi. Ikkalasi ham mijoz tomonidan bir xil ko'rinadi, shuning uchun qaysi bosqich muvaffaqiyatsiz bo'lgani xato matnidan muhimroq.
443-portni veb-sayt va SSTP o'rtasida bo'lishish marshrutlash tanlovi, har bir sakrash ikkala suhbatni bir xil boshqaradi degan va'da emas. Agar yo'lda yuk balanslagichi, xavfsizlik devori yoki TLS yakunlagichi bo'lsa, VPN konfiguratsiyasiga tegishdan oldin uni gumondorlar ro'yxatiga qo'shing.
Bosqichlarni alohida sinab ko'ring
Tekshiruvlarni tartib bilan bajaring va birinchi muvaffaqiyatsizlikda to'xtang, chunki har bir bosqich boshqa qatlamni istisno qiladi. Quyidagi TLS zondi sertifikat identifikatsiyasini SSTP qiladigan hamma narsadan ajratadi. Xost nomini o'z oxirgi nuqtangiz bilan almashtiring va u chop etadigan subject va zanjirni o'qing.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comSo'ngra qolgan dalillarni mijoz xatosidan taxmin qilish o'rniga bosqichlarga moslang. Quyidagi jadval chiptada iqtibos keltirish uchun tekshiruv ro'yxati, bir muvaffaqiyatsizlikni keyingisidan ajratuvchi imzo bilan.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Chiptada "ulanib bo'lmaydi" deb yozish o'rniga oxirgi muvaffaqiyatli bosqichni qayd eting. MS-SSTP spetsifikatsiyasi TLS qo'l berishidan keyin keladigan so'rov va PPP almashinuvini hujjatlashtiradi va brauzer sinovi nega ularning hech birini almashtira olmasligiga havola bo'ladi.
Avval identifikatsiya, keyin PPP
TLS identifikatsiyasi va PPP autentifikatsiyasi ketma-ket, muqobil emas, va ularni aralashtirish odamlarni noto'g'ri server sozlamasiga olib boradi. Mijoz avval server sertifikatini va uning maqsadini tekshiradi, so'ngra PPP o'z holatini kelishadi va foydalanuvchini chaqiruv-javob usuli yoki EAP bilan autentifikatsiya qiladi. Sertifikat muammosi rad etilgan paroldan boshqa xato beradi va hech bir xato ikkinchisi qamrab olgan bosqichni tasvirlamaydi.
Xost nomini manzil bilan almashtirish yoki sertifikat ogohlantirishidan o'tib ketish, muvaffaqiyatsiz bosqichni aniqlaydigan tekshiruvni tuzatish o'rniga olib tashlaydi. Ogohlantirishni saqlang va uni o'qing. HTTP almashinuvi hech qachon SSTP xatti-harakatiga yetmagan bo'lsa, PPP parolini qayta o'rnatmang, chunki hisob ma'lumotlari hech qachon so'ralmagan.