TLS-i yoxlayan proksi arxasında SSTP: sessiya harada qırılır

Brauzeriniz korporativ intraneti açır, proksi sertifikatı etibarlı sayılır, amma SSTP müştərisi yenə də bağlantının sonunda düşür. Bu mənzərə yanlış parolu deyil, veb sorğusu ilə tunel sessiyası arasındakı fərqi göstərir. Bağlantını TCP-dən yuxarıya doğru gəzin və uğursuz olan ilk mərhələni qeyd edin. Proksinin səbəb olub-olmadığını sizə səhv kodu deyil, mərhələ deyir.

Müştərinin dayandığı yerdən başlayın

Müştəri sabit ardıcıllıqdan keçir: 443 portuna TCP qoşulması, TLS əl sıxması, sertifikat yoxlaması, SSTP-nin HTTP mübadiləsi, PPP danışıqları və autentifikasiya, sonra IP konfiqurasiyası. Hər mərhələdəki uğursuzluq fərqli iz buraxır və onları qarışdırmaq sizi yanlış konfiqurasiya səhifəsinə aparır.

TCP uğursuzluğu hər hansı TLS baytı görünməzdən əvvəl baş verən gözləmə və ya sıfırlamadır. TLS uğursuzluğu xəbərdarlıq və ya əl sıxma gözləməsidir. Sertifikat uğursuzluğu zəncir və ya ad barədə xəbərdarlıq yaradır. HTTP uğursuzluğu uğurlu əl sıxmadan sonra, çox vaxt status kodu və ya dərhal bağlanma kimi gəlir. PPP uğursuzluğu tunel texniki olaraq qurulduqdan sonra gəlir, buna görə autentifikasiya problemi kimi görünür.

İlk səhv sətri yerinə, müştəri jurnalında son uğurlu mərhələni oxuyun. Səhv sətri adətən müştərinin nəticəni bildirməsidir, mərhələ sərhədi isə imtina edən komponentin adını çəkir.

SSTP şəbəkədən nə daşımasını istəyir

SSTP TCP 443 üzərində TLS ilə işləyir və sonra SSTP spesifikasiyasında təyin olunan SSTP_DUPLEX_POST adlı HTTP sorğusunu /sra_{GUID}/ formasındakı yola göndərir. Sorğu faktiki olaraq limitsiz məzmun uzunluğu elan edir və axını sessiyanın ömrü boyu hər iki istiqamətdə açıq saxlayır. PPP kadrları həmin axının içində hərəkət edir.

Buna görə adi gəzintini idarə edən proksi yenə də uğursuz ola bilər. Sonlu gövdəli GET və ya POST buferlənə, yoxlanıla və ötürülə bilər; heç vaxt bitməyən gövdəli dupleks axın isə bilməz. Gövdənin tamamlanmasını gözləyən proksi sonsuza qədər gözləyir və müştəri sonda vaxt aşımına düşür.

Metod filtrləməsi və autentifikasiya öz uğursuzluq rejimlərini əlavə edir. Proksi sorğudan etimadnamə tələb edərsə, brauzer cavab verəcəyi halda VPN müştərisi cavab verməyə bilər. Metodu silir və ya yenidən yazırsa, şlüz PPP başlamazdan əvvəl sorğunu rədd edir.

Yoxlama niyə kimliyi dəyişir

TLS-i yoxlayan proksi müştərinin TLS bağlantısını bitirir və şlüzə ayrı bir bağlantı açır. Buna görə müştəri şlüzün deyil, proksinin sertifikatını yoxlayır və şlüz proksini öz həmkarı kimi görür. Təşkilat öz kök sertifikatını paylaşdıqda həm brauzer, həm də VPN müştərisi həmin zənciri qəbul edə bilər, ona görə əl sıxma uğurla keçir və problem növbəti mərhələyə keçir.

Uğurlu yoxlama proksinin sessiyanı daşıya bilməsi demək deyil. O, hələ də buferləmədən limitsiz ikitərəfli POST-u ötürməli və hər iki bağlantını saatlarla canlı saxlamalıdır. Bir çox yoxlama məhsulu sorğu-cavab trafiki üçün qurulub və bu halı zəif və ya heç idarə etmir.

Buna görə naməlum kök əlavə etmək və ya yoxlamanı söndürmək yanlış təmirdir. Bu, müştərinin hansı sertifikatı qəbul etdiyini dəyişir; sessiyanı faktiki olaraq pozan axın emalına heç bir təsir etmir.

Parametrləri dəyişməzdən əvvəl verəni müəyyənləşdirin

Son nöqtədən hansı sertifikatı təqdim etdiyini və onu kimin imzaladığını soruşun. Aşağıdakı əmrlər VPN sessiyası başlatmadan zənciri və verəni göstərir:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Verən ictimai CA-dırsa, bağlantı çox güman ki, bu host üçün kəsişdirilmir və uğursuzluq başqa yerdədir. Verən təşkilatın öz CA-sıdırsa, yoxlama aktivdir və şlüzə proksi vasitəsilə çatılır. Yalnız ada əsaslanaraq nəticə çıxarmazdan əvvəl barmaq izini şəbəkə komandasının gözlədiyi ilə müqayisə edin.

Eyni hosta brauzer testi yalnız proksinin GET qəbul etdiyini sübut edir. O, SSTP metodunu, sorğu URI-ni və ya gövdənin ömrünü demir, ona görə işləyən intranet səhifəsini tunel yolunun dəstəkləndiyinə dəlil saymayın.

Dəstəklənən yolu seçin

Şəbəkə sahibinə bir konkret sual verin: proksi bu şlüzə 443 portunda buferlənməmiş dupleks POST-a icazə verirmi? “Bəli” proksi istisnasına və ya VPN hostu üçün sənədləşdirilmiş yan keçməyə gətirib çıxarır. “Xeyr” yoxlanılan yolun SSTP daşıya bilmədiyini bildirir və dəstəklənən düzəliş müştəri düzəlişi deyil, başqa yol və ya protokoldur.

Variantlara adətən VPN şlüzü üçün yoxlanılmayan çıxış, yalnız korporativ trafiki proksidən keçirən bölünmüş tunel dizaynı və ya təşkilatın başqa portda dəstəklədiyi alternativ protokol daxildir. Hər biri şəbəkə dizaynına aiddir və hər biri eyni cihaz və profillə sınaqdan keçirilməlidir ki, müqayisə yolu təcrid etsin.

Nəticəni sənədləşdirin: verən, uğursuz mərhələ, proksi qaydası və seçilmiş yol. Növbəti şəxs eyni 98 faiz dayanmanı gördükdə bütün gəzintini təkrarlamaq əvəzinə bir faktı yoxlaya bilər.