SSH SSH2_MSG_KEX_ECDH_REPLY bosqichida qotib qoladi: sabab har doim MTU emas

Tunnel ishlayapti, banner keladi va mijoz kalit almashinuvi javobini kutayotgani haqida xabar chiqaradi. Qidiruv natijalari to'g'ridan-to'g'ri MTU ga ishora qiladi va ba'zan bu to'g'ri. Ko'pincha unday emas: javob umuman yuborilmagan bo'lishi mumkin, chunki mijoz kalit faylini o'qiy olmadi yoki tomonlar algoritm bo'yicha kelisha olmadi. Qator mijoz nima kutayotganini tasvirlaydi, kutish nima uchun boshlanganini emas. Buni alomat deb qabul qiling va har qanday o'lchamni o'zgartirishdan oldin uchta sababni ajrating.

Javob umuman kutilganligini ko'rish uchun izni o'qing

Batafsil chiqish sukunatdan oldingi oxirgi muvaffaqiyatli qadamni ko'rsatadi. Server protokoli banneri kelgan bo'lsa, TCP ishlayapti va uzoq tomon tirik; ochiq savol — bitta aniq paketga nima bo'ldi. Bannerdan keyin bir daqiqa sukunat yo'l muammosiga o'xshaydi. Mos keladigan kalit almashinuvi usuli yo'qligi haqidagi xabar siyosat muammosi. Server sessiyani yopishi bilan tugaydigan uzoq kutish server taslim bo'lganini bildiradi va uning jurnali sababini tushuntiradi.

Oxirgi holatda, mijozga tegishdan oldin serverning autentifikatsiya jurnalini o'qing. Mijoz server hech qachon yubormagan qarorni ko'ra olmaydi.

Kichik javob nima uchun baribir juda katta bo'lishi mumkin

Kalit almashinuvi javoblari odatda juda kichik, shuning uchun o'lchamni ayblash noto'g'ri eshitiladi. Xost sertifikatlari bilan javob kichik emas, chunki u serverning sertifikatlar zanjirini olib yuradi. Bu uni sessiyada tunnelning foydalanish mumkin bo'lgan yukidan oshib ketishi mumkin bo'lgan birinchi paketga aylantiradi. Yo'l MTU ni aniqlash qayta aloqasi yo'lda qayerdadir yo'qolsa, jo'natuvchi sig'maydigan paketni qayta-qayta yuboradi va mijoz o'sha qatorda abadiy kutadi.

O'lchamni taxmin qilish o'rniga aniqlang. Tunnel MTU sini ip link show tun0 bilan o'qing, so'ngra bo'linmasligi kerak bo'lgan zondlar yuboring: ping -4 -M do -s 1352 host, kichikroq yuklar bilan takrorlang. Muayyan o'lchamda muvaffaqiyatsizlikdan muvaffaqiyatga o'tish dalil; bir xil muvaffaqiyatsizlik ICMP filtrlanayotganini ko'rsatadi va sizga hech narsa aytmaydi.

Vaqtinchalik pasaytirish nazariyani tez tasdiqlaydi, doimiy versiya esa profilga yoki tunnelni uzatuvchi routerdagi MSS chekloviga tegishli:

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

O'lcham muammosini taqlid qiladigan ikki sabab

Mijoz o'qiy olmaydigan kalit fayli xuddi shu kutishni keltirib chiqaradi, batafsil chiqishda ham ogohlantirishsiz. known_hosts dagi bitta naqsh buni osonlashtiradi: faqat bitta hisob o'qiy oladigan CA ochiq kalitiga ishora qiluvchi @cert-authority yozuvi. Faylga ega hisob ulanadi, qolgan har bir hisob qotib qoladi. Agar nosozlik xostni emas, foydalanuvchini kuzatsa, paket o'lchamlaridan oldin fayl rejimlarini tekshiring.

Yangilanish ikkala tomon ilgari baham ko'rgan algoritmni ham olib tashlashi mumkin. Server hali taklif qiladigan bitta usulni diagnostika sifatida mahkamlang: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Darhol muvaffaqiyatli bo'lgan ulanish yo'l yaxshi ekanini va tuzatish ikki tomonning muzokara siyosatiga tegishli ekanini isbotlaydi.

Yozib qo'yishga arziydigan uchta fakt

Har qanday o'zgarishdan oldin va keyin tunnel MTU sini, katta fayl nusxasi takrorlanadigan o'lchamda muvaffaqiyatsiz bo'ladimi va o'sha tunneldagi sertifikatsiz xost ham xuddi shunday qotib qoladimi, yozib qo'ying. Bu uchta kuzatuv o'lchamni ruxsatlardan va muzokaralardan buyruqlar to'plamidan tezroq ajratadi.

Ular keyingi odamning hech qachon o'lchamga aloqasi bo'lmagan nuqson tufayli MTU ni pasaytirishiga ham to'sqinlik qiladi.

Agar manzara hali ham aniq bo'lmasa, o'sha tunneldagi ikkinchi mijozdan sinab ko'ring. Ulanadigan mijoz nosozlikni yo'ldan birinchi mashinaning konfiguratsiyasiga ko'chiradi.