Brauzer VPN host adını HTTPS ilə heç bir şikayət etmədən açır, lakin SSTP klienti yenə də qoşulmaqdan imtina edir. Bu cütlükdə ziddiyyət yoxdur. SSTP TLS-i xarici nəqliyyat kimi istifadə edir və sonra öz sorğusunu və PPP yükünü həmin bağlantının içində işlədir, ona görə də uğurlu səhifə yüklənməsi yalnız bir dar şeyi sübut edir: host 443 portunda GET sorğusuna cavab verir. Klient başqa sual verir və server ona pis cavab verə bilər.

Səhifə açılır, tunel isə yox

İnsanlar brauzer testinə tez olduğu üçün müraciət edir, sonra nəticəni serverin əlçatan və konfiqurasiya olunduğuna sübut kimi qəbul edirlər. Bu, yalnız ünvan sətrinin açdığı yola edilən GET sorğusuna dair sübutdur, başqa heç nə deyil. VPN söhbəti eyni TLS əl sıxışmasından sonra başlayır, lakin göndərir veb səhifəsinin heç vaxt istifadə etmədiyi bir metod və yol. Buna görə brauzer üçün 200 cavabı SSTP son nöqtəsinin olub-olmadığı barədə heç nə demir.

İki müşahidəni ayırın və axtarış qısalır. Nəqliyyat və sertifikat zənciri işləyir, onların üstündəki protokol mübadiləsində isə nəsə işləmir. Bu, xarab portdan və ya müddəti bitmiş sertifikatdan fərqli araşdırmadır və fərqli sübutlar tələb edir.

SSTP klienti əslində nə göndərir

Klient /sra_{GUID}/ yoluna SSTP_DUPLEX_POST metodu ilə HTTP sorğusu göndərir, sonra bağlantı gövdəsini PPP çərçivələrini daşıyan ikitərəfli axın kimi açıq saxlayır. Uyğun server HTTP/1.1 200 cavabı verir və veb server kimi davranmağı dayandırır. Başqa hər şey bir imzadır: 405 və ya 404 son nöqtənin olmadığını, 301 və ya 302 sorğunun yönləndirildiyini, dərhal FIN isə proksi və ya serverin axını bağladığını bildirir.

Buna görə hədəf TLS sertifikatı əlavə edilmiş veb server deyil, SSTP serveri olmalıdır. Metod, yol və uzunmüddətli gövdə protokol tələbləridir, ona görə tərs proksi onları yalnız konfiqurasiya ilə əlavə edə bilməz. Adi HTTPS-i mükəmməl ötürən proksi yenə də tanımadığı metodu rədd edə bilər.

Proksi və ya veb server axını harada qırır

Ara qat hər hansı şeyi ötürməzdən əvvəl HTTP sorğu sətrini yoxlayır və qeyri-adi yolu olan fərdi metod onun qaydalarında uğursuz ola bilər. Bəzi cihazlar tuneli rədd edərkən və ya kəsərkən normal səhifə təqdim edir, buna görə klient təmiz imtinadan çox başlayıb sonra ölən bağlantı bildirir. Digərləri sorğunu qəbul edir, sonra PPP canlılıq siqnallarının keçə bilmədiyi gövdə və ya boşdayanma taym-autu tətbiq edir. İkisi klient tərəfdən eyni görünür, buna görə uğursuz olan mərhələ xəta mətnindən daha vacibdir.

443 portunu veb saytla SSTP arasında paylaşmaq marşrutlaşdırma seçimidir, hər keçidin hər iki söhbəti eyni cür idarə etdiyinə dair vəd deyil. Əgər yolda yük balanslaşdırıcı, firewall və ya TLS terminətoru varsa, VPN konfiqurasiyasına toxunmazdan əvvəl onu şübhəlilər siyahısına əlavə edin.

Mərhələləri ayrıca yoxlayın

Yoxlamaları ardıcıllıqla aparın və ilk uğursuzluqda dayanın, çünki hər mərhələ fərqli qatı istisna edir. Aşağıdakı TLS zondusu sertifikat kimliyini SSTP-nin etdiyi hər şeydən ayırır. Host adını öz son nöqtənizlə əvəz edin və çap etdiyi subyekti və zənciri oxuyun.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Sonra qalan sübutları klient xətasından təxmin etmək əvəzinə mərhələlərə uyğunlaşdırın. Aşağıdakı cədvəl biletdə sitat gətiriləcək yoxlama siyahısıdır və bir uğursuzluğu digərindən ayıran imzanı göstərir.

StageWhat it provesFailure signature
TCP to 443A listener exists and the path is openTimeout or connection refused
TLS with SNIThe certificate matches the name you useName mismatch or untrusted chain
SSTP_DUPLEX_POST exchangeThe endpoint is an SSTP server405, 404, 301 or an early FIN
PPP authenticationThe user credential was acceptedAuth failure after a 200 response
Inner routingA permitted destination is reachableTunnel up, no reply from the target

Biletdə "qoşulmaq mümkün deyil" yazmaq əvəzinə uğurlu olan son mərhələni qeyd edin. MS-SSTP spesifikasiyası TLS əl sıxışmasından sonra gələn sorğunu və PPP mübadiləsini sənədləşdirir və brauzer testinin nə üçün onların heç birini əvəz edə bilmədiyinin istinadıdır.

Əvvəlcə kimlik, sonra PPP

TLS kimliyi və PPP autentifikasiyası ardıcıldır, alternativ deyil və onları qarışdırmaq insanları səhv server parametrinə yönəldir. Klient əvvəlcə server sertifikatını və onun nəzərdə tutulan məqsədini yoxlayır, sonra PPP öz vəziyyətini razılaşdırır və istifadəçini çağırış-cavab metodu və ya EAP ilə autentifikasiya edir. Sertifikat problemi rədd edilmiş paroldan fərqli xəta yaradır və heç bir xəta digərinin əhatə etdiyi mərhələni təsvir etmir.

Host adını ünvanla əvəz etmək və ya sertifikat xəbərdarlığını keçmək, uğursuz mərhələni müəyyən edəcək yoxlamanı düzəltmək əvəzinə silir. Xəbərdarlığı saxlayın və oxuyun. HTTP mübadiləsi heç vaxt SSTP davranışına çatmadıqda PPP parolunu sıfırlamayın, çünki etimad məlumatları heç vaxt soruşulmayıb.

Əlaqəli məqalələr