SSH2_MSG_KEX_ECDH_REPLY پر SSH رک جاتا ہے: ہمیشہ MTU نہیں ہوتا

ٹنل چل رہا ہے، بینر آتا ہے، اور کلائنٹ کلیدوں کے تبادلے کے جواب کا انتظار کرنے کا پیغام چھاپتا ہے۔ تلاش کے نتائج سیدھا MTU کی طرف اشارہ کرتے ہیں، اور بعض اوقات یہ درست ہوتا ہے۔ اکثر نہیں: جواب شاید کبھی بھیجا ہی نہ گیا ہو، کیونکہ کلائنٹ کلید فائل نہیں پڑھ سکا یا دونوں سرے کسی الگورتھم پر متفق نہیں ہوئے۔ سطر بتاتی ہے کہ کلائنٹ کس چیز کا انتظار کر رہا ہے، یہ نہیں کہ انتظار کیوں شروع ہوا۔ اسے علامت سمجھیں اور کوئی بھی حجم بدلنے سے پہلے تین وجوہات الگ کریں۔

جواب واقعی متوقع تھا یا نہیں، یہ دیکھنے کے لیے ٹریس پڑھیں

تفصیلی آؤٹ پٹ خاموشی سے پہلے آخری کامیاب مرحلہ دکھاتا ہے۔ اگر سرور کا پروٹوکول بینر آ گیا ہے تو TCP کام کر رہا ہے اور دور کا سرا زندہ ہے؛ کھلا سوال یہ ہے کہ ایک مخصوص پیکٹ کے ساتھ کیا ہوا۔ بینر کے بعد ایک منٹ کی خاموشی راستے کا مسئلہ لگتی ہے۔ مماثل کلید تبادلے کا طریقہ نہ ہونے کا پیغام پالیسی کا مسئلہ ہے۔ طویل انتظار جو سرور کی طرف سے سیشن بند ہونے پر ختم ہوتا ہے، کا مطلب ہے کہ سرور نے ہار مان لی، اور اس کا لاگ وجہ بتاتا ہے۔

آخری صورت میں، کلائنٹ کو چھونے سے پہلے سرور کا تصدیقی لاگ پڑھیں۔ سرور نے کبھی نہ بھیجا گیا فیصلہ کلائنٹ نہیں دیکھ سکتا۔

چھوٹا جواب پھر بھی بہت بڑا کیوں ہو سکتا ہے

کلیدوں کے تبادلے کے جواب عام طور پر بہت چھوٹے ہوتے ہیں، اس لیے حجم کو قصوروار ٹھہرانا غلط لگتا ہے۔ ہوسٹ سرٹیفکیٹس کے ساتھ جواب چھوٹا نہیں ہوتا، کیونکہ وہ سرور کی سرٹیفکیٹ زنجیر لے کر چلتا ہے۔ یہ اسے سیشن کا پہلا پیکٹ بناتا ہے جو ٹنل کے قابل استعمال پے لوڈ سے بڑھ سکتا ہے۔ جب راستے کے MTU کی دریافت کی رائے راستے میں کہیں گم ہو جائے تو بھیجنے والا نہ سمونے والا پیکٹ بار بار بھیجتا رہتا ہے، اور کلائنٹ اسی سطر پر ہمیشہ انتظار کرتا ہے۔

حجم فرض کرنے کے بجائے اسے معلوم کریں۔ ip link show tun0 سے ٹنل کا MTU پڑھیں، پھر ایسی تحقیقات بھیجیں جن کے ٹکڑے نہیں ہونے چاہئیں: 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 کا ایک نمونہ اسے آسان بناتا ہے: CA کی عوامی کلید کی طرف اشارہ کرنے والی @cert-authority اندراج، جسے صرف ایک اکاؤنٹ پڑھ سکتا ہے۔ فائل کا مالک اکاؤنٹ جڑتا ہے، اور ہر دوسرا اکاؤنٹ رک جاتا ہے۔ اگر ناکامی میزبان کے بجائے صارف کے پیچھے چلے تو پیکٹ کے حجم سے پہلے فائل موڈز دیکھیں۔

اپ گریڈ وہ الگورتھم بھی ہٹا سکتا ہے جو دونوں سروں نے پہلے شیئر کیا تھا۔ سرور کی طرف سے اب بھی پیش کردہ ایک طریقہ کو تشخیص کے طور پر پن کریں: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host۔ فوراً کامیاب ہونے والا کنکشن ثابت کرتا ہے کہ راستہ ٹھیک ہے اور درستی دونوں فریقوں کی گفت و شنید کی پالیسی میں ہے۔

لکھنے کے قابل تین حقائق

کسی بھی تبدیلی سے پہلے اور بعد ٹنل کا MTU، بڑی فائل کی نقل قابل تکرار حجم پر ناکام ہوتی ہے یا نہیں، اور اسی ٹنل پر بغیر سرٹیفکیٹ میزبان بھی اسی طرح رکتا ہے یا نہیں، یہ درج کریں۔ وہ تین مشاہدات حجم کو اجازتوں اور گفت و شنید سے حکموں کے ڈھیر سے زیادہ تیزی سے الگ کرتے ہیں۔

وہ اگلے شخص کو ایسی خرابی کے لیے MTU کم کرنے سے بھی روکتے ہیں جو کبھی حجم کے بارے میں نہیں تھی۔

اگر تصویر اب بھی واضح نہیں ہے تو اسی ٹنل پر دوسرے کلائنٹ سے جانچیں۔ جڑنے والا کلائنٹ خرابی کو راستے سے پہلی مشین کی ترتیب کی طرف منتقل کرتا ہے۔