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 घटाउनबाट पनि रोक्छ।

चित्र अझै स्पष्ट छैन भने, त्यही टनेलको दोस्रो क्लाइन्टबाट परीक्षण गर्नुहोस्। जोडिने क्लाइन्टले दोषलाई मार्गबाट पहिलो मेसिनको कन्फिगरेसनतर्फ सार्छ।