Altmış saniyəlik TLS fasiləsi: hansı tərəf əslində dayandı?

Müştəri altmış saniyədən sonra açar razılaşması barədə mesajla imtina edir və noutbuk bunun səbəbi barədə heç bir fikir bildirmir. Bu cümlə müştərinin səbrini təsvir edir, serverin davranışını yox. Bunu üç tamamilə fərqli vəziyyət yaradır: paket heç vaxt düzgün xidmətə çatmayıb, xidmət heç nə qeyd etməzdən əvvəl onu atıb, ya da xidmət onu rədd edib və bunu müştərinin görə bilmədiyi yerdə bildirib. Bir cəhdi hər iki tərəfdə əlaqələndirmək onları ayıran şeydir.

Bir cəhdə axtara biləcəyiniz kimlik verin

Başlama vaxtını saat qurşağı ilə, profil adını, müştərinin faktiki həll etdiyi hədəfi, portu və bağlantının UDP yoxsa TCP olduğunu yazın. Profildə bir neçə uzaq qeyd varsa, o cəhdin hansını seçdiyini qeyd edin, çünki yenidən cəhd oxuduğunuz faylı dəyişmədən növbəti qeydə keçmiş ola bilər.

Son nöqtəni xatırladığınız yükləmədən deyil, aktiv jurnaldan götürün. Şəxsi ünvana yönələn profil tamamilə qanunidir və ona marşrutlaşdıra bilməyən şəbəkədən tamamilə istifadəsizdir, və bu hal söndürülmüş serverlə eyni görünür.

Sonra operatora nəzərdə tutulan instansiyada həmin pəncərəni soruşun. Saat fərqi o qədər yayğındır ki, bir neçə dəqiqəlik fərq uyğun hadisəni yox kimi göstərə bilər, ona görə heç bir hadisə olmadığı qənaətinə gəlmək əvəzinə fərqi qeyd edin.

Dörd müşahidə, dörd fərqli növbəti addım

Serverin nə qeyd etməsi budağı müəyyən edir. Hər hansı cəhdin olmaması ünvanlamaya, nəqliyyata və ya xidmətə gedən yola işarə edir. Adi mübadilədən əvvəl yox olan gələn paketlər faktiki xidmətin idarəetmə kanalı tələblərinə işarə edir. Adlandırılmış rədd onun adını çəkdiyi obyektə işarə edir. Serverdən çıxan, lakin müştəriyə heç vaxt çatmayan cavablar geri dönüş yoluna işarə edir.

Boş tətbiq jurnalı göründüyündən zəif sübutdur. Jurnallaşdırma mübadilənin müəyyən məqamında başlayır və həmin məqamdan əvvəl atılan paketlər oxuduğunuz faylda heç bir iz qoymur. Buna icazə verildiyi yerlərdə operator xidmət və şəbəkə müşahidələrindən istifadə edərək ümumiyyətlə nəyinsə gəlib-gəlmədiyini görə bilər.

Qeydlərinizdə dörd nəticəni ayrı saxlayın. Cazibə onları "server cavab vermir" ifadəsində birləşdirməkdir ki, bu da əsl problem firewall qaydası olduqda insanları şifrələmə üsullarını dəyişməyə göndərən ifadədir. Yalnız fasilə sözünü qeyd edən qeyd indicə ödədiyiniz fərqi atmış olur.

Sübutun adlandırdığı mərhələni düzəldin

Tamamlanan TCP bağlantısı yalnız nəyinsə soket qəbul etdiyini sübut edir. Dinləyicinin konfiqurasiya etdiyiniz OpenVPN xidməti olduğunu sübut etmir və eyni host adındakı veb server brauzerə mükəmməl cavab verir, halbuki tunelə heç bir aidiyyəti yoxdur.

Server vaxtı keçmiş ləğvetmə siyahısı bildirirsə, bu müştərinin son fasiləsindən qat-qat dəqiq faktdır və düzəliş şəbəkəyə deyil, sertifikat orqanına aiddir. Əgər iki tərəf idarəetmə kanalının qorunması və ya ortaq material barədə razılaşmırsa, parolu sıfırlamaq heç nəyi dəyişmir, çünki atma hər hansı etimadnamə yoxlanmadan əvvəl baş verir.

Sübutun həqiqətən dəstəklədiyi bir şeyi dəyişin, sonra eyni profili eyni son nöqtəyə qarşı təkrarlayın. Bağlantı daha irəli gedirsə, ilk yeni hadisəni saxlayın, çünki o hadisə yeni problem deyil, araşdırmanın növbəti mərhələsidir.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Pəncərənin uzadılması əslində nəyi dəyişir

Altmış saniyə müştərinin əl sıxma pəncərəsidir və icma müştəri sənədi onu tənzimləyən seçimi sənədləşdirir. Onu artırmaq müştərinin imtina etməzdən əvvəl daha uzun gözləməsinə səbəb olur. Bu, olmayan xidməti yaratmır və rədd edilmiş paketi məqbul etmir.

Yavaş keçiddə və ya ağır yüklənmiş serverdə daha uzun pəncərənin qanuni istifadəsi var və mübadilənin heç baş vermədiyini deyil, yavaş irəlilədiyini göstərən sübutunuz olduqda onu sınamağa dəyər. Əvvəlcə sınamaq sadəcə eyni diaqnozu bir dəqiqə gecikdirir və vaxt xəttini oxumağı çətinləşdirir. Vaxt xətti irəliləyib sonra dayanan mübadilə göstərirsə, pəncərə əlçatanlığın deyil, yükün simptomudur.