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 कमजोर परीक्षण हो, किनकि सारा असफलता साना प्याकेट जानु नै हो। जुन सूची, डाउनलोड वा टाँसाइ बिग्रियो त्यही प्रयोग गर्नुहोस्।

सानो आकारमा पनि अलपत्र रहे अर्को ठाउँमा हेर्नुहोस्: प्रवाह अन्त्य गर्ने अवस्थावाला फायरवाल, दोहोरिएको ठेगाना, वा पुनःजडानमा सर्ने मार्ग। असफल जाँचको आकार र तपाईंले बदलेको सेटिङ लेख्नुहोस्, किनकि त्यही जोडीले अर्को प्रतिवेदन उपयोगी बनाउँछ।