SSTP əvvəlcə serveri, sonra istifadəçini autentifikasiya edir

SSTP müştərisi TLS-i tamamlaya və bir saniyə sonra istifadəçini rədd edə bilər. Bu ardıcıllıq xəta deyil, protokol yığınıdır: əvvəlcə nəqliyyat təhlükəsizliyi, sonra istifadəçi autentifikasiyası. İki mərhələ fərqli mesajlarla uğursuz olduğu üçün fərqli düzəlişlərə də ehtiyac duyur. Xətanı hansı mərhələnin yaratdığını oxumaq diaqnozun çox hissəsidir.

Etibarlı sertifikat son nöqtəni sübut edir; hesab haqqında heç nə demir.

TLS əl sıxması nəyi müəyyən edir

Müştəri serverin təqdim etdiyi sertifikatı öz etibarlılıq anbarına, tələb olunan host adına, etibarlılıq pəncərəsinə və platformanın tətbiq etdiyi əlavə siyasətə uyğun yoxlayır. Bu, nəzərdə tutulan son nöqtəyə bağlantını qoruyur. Amma konkret hesabın aktiv, müddəti bitməmiş və ya uzaqdan giriş üçün icazəli olduğunu sübut etmir. Bu, sonradan başqa komponent tərəfindən verilən ayrı suallardır.

Buna görə giriş sorğusuna çatmaq üçün sertifikat yoxlamalarını silmək yanlış düzəlişdir. Yoxlaya bilmədiyiniz bağlantıda giriş sorğusu alırsınız. Sertifikat xətası host adına, saata, zəncirə və ya etibarlılıq konfiqurasiyasına aiddir.

SSTP və PPP bunun üzərinə nə əlavə edir

SSTP HTTPS üzərində işləyir və içində PPP daşıyır, bağlantı ətrafında öz nəzarət mübadiləsi var. Sonra PPP öz əlaqə və autentifikasiya mərhələlərini işlədir və autentifikasiya üsulu server siyasətindən və müştəri imkanlarından asılıdır. PAP, CHAP, MS-CHAPv2 və EAP hamısı çox fərqli xüsusiyyətlərə malik PPP autentifikasiya seçimləridir. VPN-in istifadəçi yoxlaması həmin PPP mərhələsidir, altındakı TLS qatı deyil.

Buna görə istifadəçinin rədd edilməsi etimadnamələr, hesab məhdudiyyəti və ya üsul uyğunsuzluğu demək ola bilər.

Server tərəfindəki səbəb profildəki hər sirri sıfırlamaqdan qat-qat faydalıdır. Hesabın deaktiv edilməsi hadisəsi və üsul danışığının uğursuzluğu müştəri tərəfində oxşar görünür və serverdə heç bir ortaqlığı yoxdur.

Xətanı mərhələyə uyğunlaşdırın

Bağlantının TLS-ə, sonra SSTP HTTP mübadiləsinə, sonra PPP mərhələsinə çatıb-çatmadığını yoxlayın. Təkrarlar arasında jurnal vaxt damğalarını uyğun saxlayın ki, əvvəlki uğursuzluq sonrakı uğurla qarışmasın. Bir pəncərədə iki cəhdi qeyd edən müştəri əks halda çatdığı son mərhələdə uğursuz olmuş kimi görünəcək. Sonuncu sətri deyil, ilk əlaqəli xətanı oxuyun.

Eyni uyğunlaşdırma server tərəfində də vacibdir, çünki autentifikasiya qeydi və nəqliyyat jurnalı çox vaxt ayrı saatları olan ayrı fayllardır. İki dəqiqəlik kənarlaşma aşkar səbəbi qeyri-mümkün kimi göstərməyə kifayətdir.

Girişdən sonra avtorizasiya hələ də ayrıdır

Uğurlu giriş hər xüsusi resursa icazə vermir. Marşrutlar nəyə çatmağın mümkün olduğunu, DNS nəyin həll olunduğunu müəyyən edir və hər xidmət hələ də öz icazələrini tətbiq edir. Bağlı görünən sessiya tunel haqqında bəyanatdır, fayl paylaşımı haqqında deyil. İstifadəçi qoşula bildiyi halda bir hosta çata bilmirsə, tunel mərhələsi artıq bitib.

Bu, əl sıxmasının göstərdiyi eyni qatlaşmadır, bir səviyyə yuxarıda.

Hesab bərpasını operatorun dəstəklədiyi proseslə saxlayın, açıq istifadəçi rəddinə cavab olaraq nəqliyyat parametrlərini dəyişməyin. Deaktiv hesabı düzəltmək üçün nəqliyyatı dəyişmək, hesab əlaqəsiz səbəbdən yenidən aktivləşdirildikdə işləyirmiş kimi görünən bir düzəliş növüdür.