OpenVPN ले असंगत MTU प्रयोगको चेतावनी दिन्छ: सन्देशले के तुलना गर्छ

त्यो चेतावनीले पियर विकल्पहरूबीचको तुलनाको जानकारी दिन्छ, तिनीहरूबीचको बाटोको मापन होइन। मानिसहरू यसलाई ‘MTU गलत छ’ भनेर पढ्छन् र रेखा हराउनेसम्म संख्या बदल्छन्। यसले कन्फिगरेसनको तुलनालाई नेटवर्क मापन मान्छ, र लग शान्त हुँदा टनेल प्रायः अझ खराब बनाउँछ। उपयोगी पहिलो कदम यी दुई समस्यामध्ये साँच्चै कुन तपाईंसँग छ भनेर निर्णय गर्नु हो।

तीन सर्तले उत्तर निर्धारण गर्छन्: पियरहरूले के तुलना गर्छन्, मान पुरानो हो कि होइन, र चेतावनीबाहेक के लक्षण छ।

चेतावनीले प्याकेट होइन, विकल्प तुलना गर्छ

OpenVPN पियरहरूले ह्यान्डशेकका क्रममा आफ्ना विकल्प-स्ट्रिङ आदानप्रदान गर्छन् र विकल्प सुसंगति जाँचको भागका रूपमा तिनको तुलना गर्छन्। जब एक पक्षले अर्कोभन्दा फरक तरिकाले link-mtu वा tun-mtu रिपोर्ट गर्छ, असंगति दुवै मानसहित रेकर्ड हुन्छ। त्यो आदानप्रदानले के हुन्छ भनेर हेर्न कहिल्यै ठूलो प्याकेट पठाउँदैन, त्यसैले चेतावनीले क्षमता होइन, कन्फिगरेसन वर्णन गर्छ। टनेलले पूर्ण आकारको ट्राफिक बोक्दै त्यसलाई छाप्न सक्छ, वा ठूला प्याकेटमा असफल भई केही पनि नछाप्न सक्छ।

पूरा चेतावनी यसको स्थानीय र दूरको मानसहित राख्नुहोस्। प्रमाण त्यो जोडी हो; तपाईंले सम्झने एकल संख्या होइन।

link-mtu किन पुरानो भयो

OpenVPN 2.6 ले link-mtu लाई पुरानो घोषणा गर्छ, किनकि बदलिने हेडर र वार्ता गरिएका साइफरले स्थिर लिंक मान अविश्वसनीय बनाउँछन्। यो विकल्पले प्रोटोकलले अब ग्यारेन्टी नगर्ने प्याकेट लेआउट मानेको थियो, त्यसैले शाब्दिक link-mtu भएको पुरानो प्रोफाइलले वर्तमान कोडले पूरा गर्न नसक्ने नियत वर्णन गर्छ। त्यो संख्या नयाँ प्रोफाइलमा प्रतिलिपि गर्दा पुरानो अनुमान फैलिन्छ। यसलाई सिफारिस होइन, पुरानो प्रोफाइलको इतिहासको भागका रूपमा पढ्नुहोस्।

सुसंगति जाँचमा tun-mtu सँग जोडिएको वैकल्पिक OCC मान पनि छ, जसले नेटवर्कले के बोक्छ भन्ने नबदली के तुलना हुन्छ भन्ने बदल्छ। यसलाई सेट गर्दा ठूला प्याकेट भित्र अटाउँदैनन्।

बाटो जाँच्नुअघि प्रोफाइल सुधार्नुहोस्

अनिच्छित असंगतिलाई प्रोफाइलको मालिकमार्फत सुधार्नुहोस्, र सर्भर पक्षको परिवर्तनले प्रत्येक क्लाइन्टलाई असर गर्छ भन्ने सम्झनुहोस्। इन्स्टेन्सले साँच्चै लोड गर्ने प्रोफाइल सम्पादन गर्नुहोस्, डाउनलोड फोल्डरमा रहेको निर्यात होइन। त्यसपछि एउटा परीक्षण क्लाइन्ट पुनः जोड्नुहोस् र कुन चेतावनी बाँकी रहन्छ नोट गर्नुहोस्। सन्देश हराउनुको सट्टा आकार बदल्छ भने, तपाईं सोचेभन्दा फरक विकल्पहरू तुलना गर्दै हुनुहुन्छ।

साझा सर्भरले ग्लोबल मान सार्नुअघि आफ्नो क्लाइन्ट सूची जाँच्नु आवश्यक छ, किनकि एउटा साइटका लागि उपयुक्त मानले अर्कोलाई तोड्न सक्छ।

त्यसपछि साँच्चै भएको लक्षण परीक्षण गर्नुहोस्

ठूला स्थानान्तरण अड्किँदा साना अनुरोध सफल हुन्छन् भने, नियन्त्रित गन्तव्यसँग प्याकेटको आकार नाप्नुहोस्। ‘खण्डन नगर्नु’ बिट सेट गरी पेलोडको आकार बढाउने प्रोबले केवल सफल हुने ping भन्दा धेरै भरपर्दो रूपमा बाटोको प्रयोगयोग्य MTU भेट्छ। परीक्षणमा असफल हुने एप्लिकेसन पनि समावेश गर्नुहोस्: ICMP समय-समाप्तिले फिल्टरिङ झल्काउन सक्छ, र सानो सफल ping ले पूर्ण आकारको एप्लिकेसन प्याकेटबारे केही भन्दैन।

mssfix ले टनेलभित्रका TCP सत्रहरूका लागि घोषित MSS सीमित गर्छ, जसले TCP लाई मद्दत गर्छ र आन्तरिक UDP भारका लागि केही गर्दैन। खण्डन र अफलोड सेटिङका आफ्नै अनुकूलता सर्तहरू छन्। लगको एउटा लाइन शान्त पार्न एकैपटक धेरै बदल्नुको सट्टा प्रमाणित समस्याका लागि एउटा संयन्त्र छान्नुहोस्।

प्रभावकारी मानहरू नतिजासँगै राख्नुहोस्

वास्तविक स्थानान्तरणको नतिजासँगै मूल र सुधारिएका प्रभावकारी मानहरू लेख्नुहोस्। त्यही जोडीले पुरानो प्रोफाइल विकल्पलाई स्वतन्त्र रूपमा रहेको बाटो-MTU समस्याबाट छुट्याउँछ। त्यो बिना अर्को पाठकले हराएको चेतावनी देख्छ र नेटवर्क बदलिएको अनुमान गर्छ।

सुसंगति जाँच दबाउँदा केही मिल्दैन। यसले अवलोकन हटाउँछ र दुवै कन्फिगरेसनलाई जस्ताको तस्तै छोड्छ।