SSTP gecikməsi və ya sertifikat xətası: onları necə ayırd etməli

SSTP bağlantısı istifadəçi yerindən eyni görünən iki şəkildə uğursuz olur və hər birinin bərpası fərqli qatda yerləşir. Gecikmə tələb olunan mübadilənin heç vaxt tamamlanmadığını bildirir; sertifikat xətası isə kimlik materialının gəldiyini və rədd edildiyini bildirir. İkincisini birincisi kimi qəbul etmək sizi heç vaxt problem olmayan firewall-lara və parollara yönəldir. Fərqləndirici sübut müştərinin öz jurnalındadır, əgər hər hansı dəyişiklik etməzdən əvvəl onu oxusaq.

İki uğursuzluq, iki fərqli mübadilə

SSTP tuneli HTTPS formasında sessiyanın içində daşıyır, buna görə də yalnız 443-ə icazə verən şəbəkələrdə davam edir. Müştəri TLS əl sıxmasını tamamlayır, protokola xas metodla HTTP sorğusu göndərir və sonra tunel həmin axının içində işləyir. Bu addımlardan hər hansı birində uğursuzluq bağlantını dayandırır və yalnız sonrakılar etimad məlumatlarına aiddir.

Bu sıra diaqnostikdir. Əgər TLS əl sıxması heç vaxt tamamlanmırsa, heç bir etimad məlumatı göndərilməyib, yəni parolun sıfırlanması kömək edə bilməz. Əl sıxması tamamlanıb sonra dayanırsa, kimlik qəbul edilib və sorğu yolunda nəsə onu rədd edib. Əl sıxması doğrulama mesajı ilə uğursuz olursa, server cavab verib və müştəri eşitdiyini bəyənməyib. Üç nəticə, üç qat.

Jurnal sətri adətən üçündən hansında olduğunuzu göstərir, buna görə də ilk dəyişiklikdən əvvəl onu qeydə almağa dəyər.

Gecikmə mərhələnin heç vaxt bitmədiyini bildirir

Ad həlli və TCP əlçatanlığı ilə başlayın, çünki oradakı gecikmə sonrakı gecikmə ilə eyni görünür. 443-ün açıq olduğunu bildirən port yoxlayıcısı yalnız dinləyicinin bağlantını qəbul etdiyini sübut edir, başqa heç nəyi yox.

Növbəti şübhəli host deyil, yoldur. Proksilər və tətbiqdən xəbərdar firewall-lar bəzən SSTP-nin istifadə etdiyi sorğu metodunu rədd edir və ya saatlarla açıq qalan axını atır, və hər iki davranış müştəri tərəfindən gecikmə kimi görünür. Eyni hostun təqdim etdiyi ümumi HTTPS səhifəsi mükəmməl yüklənir, halbuki tunel metodu rədd edilir, buna görə də son nöqtəyə baxmaq çox az şey sübut edir. Bu iki halı ayırmaq üçün proksisiz şəbəkədən sınaq keçirin.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Hər hansı həmsöhbət cavabından əvvəlki gecikmə hesab haqqında heç nə demir və o anda parolu dəyişmək yalnız bir dəyişən əlavə edir.

Sertifikat xətası kimliyin rədd edildiyini bildirir

Burada server cavab verdi, yəni şəbəkə işləyir və sual kimliyə keçir. Müştərinin yığdığı adı sertifikatın həqiqətən təsdiqlədiyi adlarla müqayisə edin, sonra etibarlılıq tarixlərini və verən zənciri yoxlayın.

Müştərinin etimad etmədiyi özəl CA, vaxtı keçmiş sertifikatla eyni sinif xəta yaradır və saatlar boyu səhv olan saat da belədir. Xam ünvana yığmaq yeni uyğunsuzluq yaradır, çünki sertifikat ünvanları deyil, adları təsdiqləyir. İdarə olunan yerləşdirmədə, səhv səhifəsinin təklif etdiyi əvəzedici kökü qəbul etmək əvəzinə nəzərdə tutulan etimad konfiqurasiyasını administratorundan alın. Siz səbəbi düzəldərkən doğrulama açıq qalır.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Uğurlu TLS mərhələsini keçdikdən sonra toxunulmaz saxlayın, çünki sonradan onu geri qaytarmaq tuneli hansı dəyişikliyin həqiqətən düzəltdiyini gizlədir.

İkisinin qarışdığı yer

Hər iki uğursuzluq qalxmayan bağlantı kimi görünür və hər ikisi istifadəçi əlaqəsiz bir şeyi dəyişdikdən sonra gəlir. Bu təsadüf səhv bərpanı bir müddət inandırıcı göstərən şeydir.

İki vərdiş onları ayırır. Konfiqurasiyaya toxunmazdan əvvəl müştəri jurnalını qeydə alın ki, ilk vəziyyət qorunsun. Hər cəhddə bir qatı dəyişin ki, növbəti nəticə məlum dəyişənə aid olsun. Port yoxlayıcısı və brauzer tam ardıcıllıq deyil, qismən müşahidələrdir və heç biri müştərinin öz hesabatını əvəz etmir. Heç bir vərdiş heç nəyə başa gəlmir və hər ikisi araşdırmanı qısaldır.

Sertifikat sualı və əlçatanlıq sualı bir səbəbə görə ayrıca sənədləşdirilir.

Həqiqi müştəri ilə yenidən sınayın, sonra içəriyə doğru hərəkət edin

Konkret düzəliş yerində olduqdan sonra brauzer vərəqi ilə deyil, həqiqi SSTP müştərisi və real profillə yenidən cəhd edin.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Sessiya qoşulursa və resurslar hələ də uğursuz olursa, tunel artıq şübhəli deyil: marşrutlaşdırma, DNS və xidmət girişinə keçin. Bu, fərqli sübutlarla fərqli bir araşdırmadır. İşləyən TLS və autentifikasiya mərhələlərini saxlamaq onun birincinin təkrarına çevrilməsinin qarşısını alır. Uğursuz olan mərhələni bilettə yazın, əks halda növbəti şəxs yenidən yuxarıdan başlayacaq.