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-এর একটি প্যাটার্ন এটা সহজ করে: এমন একটি @cert-authority এন্ট্রি যা CA পাবলিক কী-র দিকে ইশারা করে, যা কেবল একটি অ্যাকাউন্ট পড়তে পারে। যে অ্যাকাউন্ট ফাইলটির মালিক সে সংযুক্ত হয়, বাকি সব অ্যাকাউন্ট আটকে থাকে। ব্যর্থতা হোস্টের বদলে ব্যবহারকারীকে অনুসরণ করলে, প্যাকেটের আকারের আগে ফাইলের মোড দেখুন।

আপগ্রেড দুই প্রান্তের আগে শেয়ার করা অ্যালগরিদমও সরিয়ে দিতে পারে। সার্ভার এখনো যে একটি পদ্ধতি দেয় তা ডায়াগনস্টিক হিসেবে পিন করুন: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host। যে সংযোগ সাথে সাথে সফল হয় তা প্রমাণ করে পথ ঠিক আছে এবং সমাধান দুই পক্ষের দরকষাকষি নীতিতে।

লিখে রাখার মতো তিনটি তথ্য

যেকোনো পরিবর্তনের আগে ও পরে টানেলের MTU, বড় ফাইল কপি কি পুনরাবৃত্তিযোগ্য আকারে ব্যর্থ হয়, এবং একই টানেলে সার্টিফিকেটহীন হোস্টও কি একইভাবে আটকে থাকে—এগুলো লিখুন। ওই তিনটি পর্যবেক্ষণ আকারকে অনুমতি ও দরকষাকষি থেকে আলাদা করে, এক গাদা কমান্ডের চেয়ে দ্রুত।

এগুলো পরের মানুষকে এমন ত্রুটির জন্য MTU কমাতে বাধা দেয় যা কখনো আকারের ছিল না।

চিত্রটি এখনো অস্পষ্ট হলে একই টানেলে দ্বিতীয় ক্লায়েন্ট থেকে পরীক্ষা করুন। যে ক্লায়েন্ট সংযুক্ত হয় সে ত্রুটিটি পথ থেকে প্রথম মেশিনের কনফিগারেশনে সরিয়ে নেয়।