OpenVPN वर SSH अडकते? आधी पथ MTU मोजा

SSH जोडते, प्रॉम्प्ट दिसतो, आणि एखादा आदेश काही मोठे परत करताच सत्र मरते. इको थोडा वेळ चालते, नंतर क्लायंट टनेल अजूनही चालू दाखवत असतानाच जोडणीची मुदत संपते. डेटा येईपर्यंत निरोगी राहणारे सत्र सामान्यतः SSH च्या दोषावर नाही, तर आकाराच्या मर्यादेवर आदळते. खालील तपासण्या सर्वात स्वस्त स्पष्टीकरण आधी बाद करण्याच्या क्रमाने आहेत.

प्रोफाइलला हात लावण्यापूर्वी अपयशाचा आकार वाचा

छोटे पॅकेट जातात आणि भरलेले जात नाहीत. प्रॉम्प्ट, बॅनर किंवा एक की-दाब सहज बसतो; डिरेक्टरी यादी, डाउनलोड किंवा पेस्ट केलेला ब्लॉक बसत नाही. ज्या आकारावर वर्तन बदलते तोच सुगावा आहे, SSH हाच संबंधित प्रोग्राम आहे हे नाही.

यांत्रणा अशी आहे: पथ MTU शोध, जो प्रतिसादावर अवलंबून आहे. TCP सेगमेंट आकार निवडतो, आणि वाटेवरील एखादा राउटर तयार झालेले पॅकेट पुढे पाठवू शकत नाही तेव्हा त्याने ICMP संदेशाने ते कळवावे. एन्कॅप्स्युलेशन बाहेरचे पॅकेट आतल्यापेक्षा मोठे करते, म्हणून टनेलमधील वापरण्यायोग्य आकार नेहमी भौतिक दुव्याच्या खाली असतो. ते ICMP संदेश कुठेही गाळले तर पाठवणाऱ्याला दुरुस्ती कधीच मिळत नाही, तो भरलेले सेगमेंट पाठवत राहतो, आणि बाहेरचे पॅकेट कोणत्याही सूचनेशिवाय टाकून दिले जाते.

दोन्ही बाजूंनी मर्यादा मोजा

दोन्हींपैकी कोणतेही बदलण्यापूर्वी टनेलची MTU भौतिक दुव्याशी तुलना करा. भौतिक मूल्य कॉपी केलेली टनेल विसंगती कुठे आहे हे आधीच सांगून झाली आहे.

टनेलच्या आतून विभाजनास मनाई करणाऱ्या विनंतीने तपासा, उत्तरे येईपर्यंत पेलोड कमी करत जा. आकाराचा युक्तिवाद फक्त पेलोड मोजतो, म्हणून चालणारा आकडा नेहमी इंटरफेस MTU च्या खाली असतो. इंटरफेसचा आकडा हवा असल्यास शीर्षकांचे आकार पुन्हा जोडा.

ip link show tun0
ping -M do -s 1380 10.9.0.1

टनेलच्या बाहेरून सर्व्हरच्या सार्वजनिक पत्त्याविरुद्ध तपासणी पुन्हा करा. तिथेही मोठ्या तपासण्या अपयशी ठरल्या तर मर्यादा सर्व्हरकडे जाणाऱ्या वाटेवर आहे आणि टनेलचा कोणताही पर्याय ती हलवणार नाही. ही तुलना तुम्हाला कधीही समस्या नसलेला क्लायंट ट्यून करण्यापासून वाचवते. कॉन्फिगरेशन फाइल उघडण्यापूर्वी दोन्ही निकाल लिहून ठेवा.

mssfix आणि fragment वेगळे काम करतात

mssfix टनेलमधील TCP जोडण्या हातमिळवणीच्या वेळी जाहीर करतात तो सेगमेंट आकार मर्यादित करते. SSH, HTTPS आणि फाइल प्रतींसाठी हाच योग्य लीव्हर आहे, म्हणून तो सेट होताच अडकणे बऱ्याचदा नाहीसे होते. ते UDP पेलोडला अजिबात स्पर्श करत नाही.

UDP सेवाही वाहून नेणारी टनेल SSH दुरुस्त केल्यावरही अपयशी होऊ शकते, आणि हा निकाल एकच पर्याय सर्व झाकतो असे मानणाऱ्या प्रत्येकाला गोंधळवतो.

fragment दुसरी यांत्रणा आणि वेगळे साधन आहे. ते एन्कॅप्स्युलेशनपूर्वी जास्त मोठे पॅकेट विभाजित करते, फक्त UDP वाहतुकीला लागू होते, प्रति डेटाग्राम अधिभार जोडते आणि तुटलेल्या शोधासाठी शेवटचा उपाय म्हणून नोंदवले आहे. दोन्ही सेटिंग्ज टनेल संपवणाऱ्या सहकाऱ्यांमध्ये जुळल्या पाहिजेत. एक टोक मर्यादित करत असताना दुसरे विभाजित करत असेल तर लॉगमध्ये इशारे आणि फाइलांवरून कोणीही अंदाज करू न शकेल असे वर्तन उद्भवते.

इंटरफेस MTU कमी करणे हा जाडसर पर्याय आहे

दोन्ही टोकांना इंटरफेस MTU कमी करणे हे जाडसर साधन आहे. ते प्रत्येक आतल्या पाठवणाऱ्याला लहान आकडा सांगते, जे चालते, आणि तो खर्च गरज असलेल्या TCP प्रवाहांवर नाही तर सर्व रहदारीवर टाकते.

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

अडकलेल्या स्थानांतरानेच पुन्हा चाचणी करा

सेटिंग्ज लोड व्हाव्यात म्हणून पुन्हा जोडा, नवीन जोडणी उघडा आणि जमलेला आदेश पुन्हा द्या. सेगमेंट आकार हातमिळवणीच्या वेळी ठरतो, म्हणून पुनर्जोडणी सहन केलेल्या सत्रात अजूनही जुने मूल्य असते. इथे ping ही कमकुवत चाचणी आहे, कारण अख्खे अपयश म्हणजे छोटे पॅकेट जातात. जी यादी, डाउनलोड किंवा पेस्ट तुटली तीच वापरा.

लहान आकारावरही अडकणे टिकले तर दुसरीकडे पहा: प्रवाह संपवणारा स्थितीय फायरवॉल, दुहेरी पत्ता, किंवा पुनर्जोडणीला सरकणारा मार्ग. अपयशी तपासणीचा आकार आणि तुम्ही बदललेली सेटिंग नोंदवा, कारण तीच जोडी पुढील अहवाल उपयुक्त करते.