SSH په SSH2_MSG_KEX_ECDH_REPLY کې ودریږي: تل MTU نه وي

ټونل فعال دی، بنر رارسېږي، او کلاینت د کیلي تبادلې ځواب ته د انتظار پیغام چاپوي. د لټون پایلې مستقیم MTU ته اشاره کوي، او کله ناکله دا سم وي. ډېری وخت نه وي: ځواب ممکن هېڅکله نه وي لېږل شوی، ځکه کلاینت د کیلي فایل لوستل نشو کړای یا دواړه خواوې د الګوریتم په اړه هېڅکله سره یو نشوې. کرښه بیانوي چې کلاینت څه ته انتظار کوي، نه دا چې انتظار ولې پیل شو. دا د نښې په توګه وګورئ او د هر ډول اندازې بدلولو دمخه درې لاملونه جلا کړئ.

د دې لپاره چې وګورئ ځواب اصلاً تمه کېده، ټریس ولولئ

تفصیلي تولید د چوپتیا دمخه وروستی بریالی ګام ښیي. که د سرور پروتوکول بنر راغلی وي، TCP کار کوي او لرې پای ژوندی دی؛ خلاصه پوښتنه دا ده چې یو ځانګړي پاکټ سره څه وشول. د بنر وروسته یوه دقیقه چوپتیا د لارې ستونزه ښکاري. د سمونې کیلي تبادلې طریقې نه شتون پیغام د پالیسۍ ستونزه ده. اوږد انتظار چې د سرور لخوا د غونډې بندولو سره پای ته ورسیږي، مانا دا ده چې سرور تسلیم شو، او د هغه لاګ لامل تشریح کوي.

په وروستي حالت کې، د کلاینت له لمس کولو مخکې د سرور تصدیق لاګ ولولئ. کلاینت هغه پرېکړه نه شي لیدلی چې سرور هېڅکله نه ده لېږلې.

ولې کوچنی ځواب بیا هم خورا لوی کېدای شي

د کیلي تبادلې ځوابونه معمولاً ډېر کوچني وي، نو د اندازې تورنول غلط ښکاري. د هوسټ سندونو سره ځواب کوچنی نه وي، ځکه د سرور د سندونو زنځیر وړي. دا هغه په غونډه کې لومړنی پاکټ جوړوي چې د ټونل د کارېدونکي بار څخه تېرېدای شي. کله چې د لارې MTU کشف بیرته خوړل په لاره کې چېرته ورک شي، لېږونکی هغه پاکټ چې نه ځای پرځای کېږي بیا بیا لېږي، او کلاینت په همغه کرښه کې تل انتظار کوي.

اندازه وټاکئ نه دا چې فرض یې کړئ. د ټونل MTU د ip link show tun0 سره ولولئ، بیا هغه پروبې ولېږئ چې باید ټوټې نه شي: ping -4 -M do -s 1352 host، د کوچنیو بارونو سره تکرار یې کړئ. په ټاکلې اندازه کې له ناکامۍ څخه بریا ته بدلون ثبوت دی؛ یو شان ناکامي ښیي چې ICMP فلټرېږي او تاسو ته هېڅ نه وایي.

لنډمهاله کمښت نظریه ژر تاییدوي، او تلپاتې نسخه په پروفایل کې یا د ټونل د لېږدونکي روټر په MSS محدودیت کې ځای لري:

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

هغه دوه لاملونه چې د اندازې ستونزه تقلیدوي

هغه کیلي فایل چې کلاینت یې نه شي لوستلی، هماغه انتظار رامنځته کوي، پرته له خبرداري حتی په تفصیلي تولید کې. د known_hosts یو نمونه دا اسانه کوي: یوه @cert-authority ننوتنه چې د CA عام کیلي ته اشاره کوي او یوازې یو حساب یې لوستلی شي. هغه حساب چې فایل لري نښلېږي، او نور هر حساب ودریږي. که ناکامي د کوربه پرځای کارن تعقیب کړي، د پاکټ اندازو دمخه د فایل حالتونه وګورئ.

تازه کول کېدای شي هغه الګوریتم هم لرې کړي چې دواړه خواوې مخکې شریک وو. یوه طریقه چې سرور لا هم وړاندې کوي د تشخیص په توګه پن کړئ: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. هغه اړیکه چې سمدلاسه بریالۍ شي ثابتوي چې لاره سمه ده او اصلاح د دواړو خواوو د خبرو اترو پالیسۍ پورې اړه لري.

درې حقیقتونه چې د لیکلو ارزښت لري

د هر بدلون دمخه او وروسته د ټونل MTU، دا چې د لوی فایل کاپي په تکرارېدونکې اندازه کې ناکامه کېږي که نه، او دا چې په همغه ټونل کې بې سند کوربه هم هماغسې ودریږي که نه، ولیکئ. هغه درې مشاهدې اندازه له اجازو او له خبرو اترو څخه د لارښوونو د غونډې په پرتله ژر جلا کوي.

دوی بل کس هم منع کوي چې د هغې خرابۍ له امله MTU کم کړي چې هېڅکله د اندازې په اړه نه وه.

که انځور لا هم روښانه نه وي، په همغه ټونل کې له دویم کلاینت څخه ازموینه وکړئ. هغه کلاینت چې نښلېږي خرابي له لارې څخه لومړي ماشین ته تنظیماتو ته لېږدوي.