SSH SSH2_MSG_KEX_ECDH_REPLY mərhələsində donur: səbəb həmişə MTU deyil

Tunel işləyir, banner gəlir və müştəri açar mübadiləsinin cavabını gözlədiyini bildirən mesaj çap edir. Axtarış nəticələri dərhal MTU-nu göstərir və bəzən bu doğrudur. Çox vaxt belə deyil: cavab heç vaxt göndərilməmiş ola bilər, çünki müştəri açar faylını oxuya bilməyib və ya tərəflər alqoritm barədə razılığa gəlməyib. Sətir müştərinin nəyi gözlədiyini təsvir edir, gözləmənin niyə başladığını yox. Onu simptom kimi qəbul edin və hər hansı ölçünü dəyişməzdən əvvəl üç səbəbi ayırın.

Cavabın ümumiyyətlə gözlənildiyini görmək üçün izi oxuyun

Ətraflı çıxış sükutdan əvvəlki son uğurlu addımı göstərir. Serverin protokol banneri gəlibsə, TCP işləyir və uzaq tərəf sağdır; açıq sual konkret bir paketin necə olduğudur. Bannerdən sonra bir dəqiqəlik sükut yol problemi kimi görünür. Uyğun açar mübadiləsi metodu olmadığına dair mesaj siyasət problemidir. Serverin sessiyanı bağlaması ilə bitən uzun gözləmə serverin təslim olduğunu bildirir və onun jurnalı səbəbi izah edir.

Son halda müştəriyə toxunmazdan əvvəl serverin autentifikasiya jurnalını oxuyun. Müştəri serverin heç vaxt göndərmədiyi qərarı görə bilməz.

Kiçik cavab niyə hələ də çox böyük ola bilər

Açar mübadiləsi cavabları adətən çox kiçikdir, ona görə ölçünü günahlandırmaq yanlış səslənir. Host sertifikatları ilə cavab kiçik deyil, çünki serverin sertifikat zəncirini daşıyır. Bu, onu sessiyada tunelin istifadə edilə bilən yükünü aşa bilən ilk paket edir. Marşrut MTU kəşfinin əks əlaqəsi yolun hansısa yerində atıldıqda, göndərən sığmayan paketi təkrar-təkrar göndərir və müştəri həmin sətirdə sonsuza qədər gözləyir.

Ölçünü fərz etmək əvəzinə müəyyənləşdirin. Tunelin MTU-sunu ip link show tun0 ilə oxuyun, sonra parçalanmamalı olan zondlar göndərin: ping -4 -M do -s 1352 host, daha kiçik yüklərlə təkrarlayın. Müəyyən ölçüdə uğursuzluqdan uğura keçid sübutdur; bərabər uğursuzluq ICMP-nin filtrləndiyini göstərir və sizə heç nə demir.

Müvəqqəti azaltma nəzəriyyəni tez təsdiqləyir, davamlı versiya isə profildə və ya tuneli ötürən marşrutlaşdırıcıda MSS məhdudiyyəti kimi yer alır:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ölçü problemini təqlid edən iki səbəb

Müştərinin oxuya bilmədiyi açar faylı eyni gözləməni yaradır və hətta ətraflı çıxışda heç bir xəbərdarlıq vermir. Bir known_hosts nümunəsi bunu asanlaşdırır: yalnız bir hesabın oxuya biləcəyi CA açıq açarına işarə edən @cert-authority girişi. Fayla sahib olan hesab qoşulur, bütün digər hesablar isə donur. Uğursuzluq hostu deyil, istifadəçini izləyirsə, paket ölçülərindən əvvəl fayl rejimlərini yoxlayın.

Yenilənmə hər iki tərəfin əvvəllər paylaşdığı alqoritmi də silə bilər. Serverin hələ təklif etdiyi bir metodu diaqnostika üçün bərkidin: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Dərhal uğurlu olan bağlantı yolun qaydasında olduğunu sübut edir və düzəliş hər iki tərəfin danışıq siyasətinə aiddir.

Yazmağa dəyər üç fakt

Hər hansı dəyişiklikdən əvvəl və sonra tunelin MTU-sunu, böyük fayl köçürməsinin təkrarlanan ölçüdə uğursuz olub-olmadığını və eyni tuneldə sertifikatsız hostun eyni şəkildə dayanıb-dayanmadığını qeyd edin. Bu üç müşahidə ölçünü icazələrdən və danışıqdan bir yığın əmrdən daha sürətli ayırır.

Onlar həm də növbəti şəxsin heç vaxt ölçü ilə bağlı olmayan nasazlıq üçün MTU-nu azaltmasının qarşısını alır.

Mənzərə hələ də aydın deyilsə, eyni tuneldə ikinci müştəridən sınaqdan keçirin. Qoşulan müştəri nasazlığı yoldan birinci maşının konfiqurasiyasına keçirir.