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 कमी करण्यापासूनही रोखतात.

चित्र अजूनही अस्पष्ट असल्यास, त्याच टनेलवरील दुसऱ्या क्लायंटवरून चाचणी करा. जोडणारा क्लायंट दोष मार्गावरून पहिल्या मशीनच्या कॉन्फिगरेशनकडे हलवतो.