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 घटाने से भी रोकते हैं जो कभी आकार के बारे में नहीं थी।

यदि चित्र अभी भी स्पष्ट नहीं है, तो उसी टनल पर दूसरे क्लाइंट से परीक्षण करें। जो क्लाइंट जुड़ता है वह खराबी को मार्ग से पहली मशीन की कॉन्फ़िगरेशन में ले जाता है।