OpenVPN mssfix: ठूला स्थानान्तरणमा एक ग्राहक किन रोकिन्छ
mssfix सुरुङभित्र घोषणा गरिएको TCP खण्डको आकार फेरि लेख्छ। यसले UDP को आकार बदल्दैन, र मानले तपाईंको संस्करणले भनेको कुरा मात्र जनाउँछ।
एउटा ल्यापटप सुरुङबाट अपलोडमा रोकिन्छ जबकि एउटै सर्भरका अरू सबै उपकरण काम गरिरहन्छन्। त्यो ढाँचाले सर्भर कन्फिगरेसनतिर होइन, एउटा बाटोतिर संकेत गर्छ, र यही mssfix प्रश्नको सामान्य प्रवेशद्वार हो। यो विकल्पले मद्दत गर्न सक्छ, तर यसले साँच्चै फेरि लेख्ने TCP जडानहरूका लागि मात्र। यसको दायरा जान्नाले एक ग्राहक बचाउन चलिरहेको सर्भर बदल्नबाट रोक्छ।
विकल्पले के फेरि लेख्छ
mssfix सुरुङबाट जाने TCP ह्यान्डसेकहरूमा घोषणा गरिएको अधिकतम खण्ड आकार सम्पादन गर्छ, ताकि पठाउने पक्षले एन्क्याप्सुलेटेड बजेटमा अटाउने खण्डहरू छान्छ। यसले ह्यान्डसेकमा काम गर्छ, अर्थात् परिवर्तनअघि खोलिएको जडानले वार्ता गरिएको मान राख्छ।
यसले UDP डेटाग्राम सानो बनाउँदैन, र सुरुङको MTU सेट गर्दैन। दुई फरक समस्याले एउटै लक्षण दिन्छन्: बाटोको सीमा बेवास्ता गर्ने TCP प्रेषक, र कुनै पनि आकारका ठूला प्याकेट चुपचाप फ्याँक्ने बाटो। mssfix पहिलो सम्बोधन गर्छ र दोस्रोका लागि केही गर्दैन।
यही भिन्नताले निराशाजनक प्रयोगहरू व्याख्या गर्छ। ब्ल्याकहोल बाटोमा सानो मान सेट गर्दा खण्डको आकार बदलिन्छ, तर त्यसपछिको खसालो होइन, त्यसैले स्थानान्तरण अर्को बिन्दुमा असफल हुन्छ।
दायरा सुरुङभित्रको TCP हो
TCP ट्राफिक मात्र फेरि लेखिन्छ। QUIC सत्र, खेल वा ठूला UDP डेटाग्राम पठाउने अनुप्रयोगले आफ्नै प्याकेट आकार राख्छ, र यदि ती स्थानान्तरणहरू नै रोकिन्छन् भने, समाधान बरु सुरुङ वा बाटोको MTU मा पर्छ। TCP विकल्पतिर जानुअघि असफल स्थानान्तरणले कुन प्रोटोकल प्रयोग गर्छ पढ्नुहोस्, किनकि गलत तहको आफ्नै समाधान हुन्छ।
दिशा पनि महत्त्वपूर्ण छ। ग्राहक सेटिङले त्यो ग्राहकले सुरुङमा पठाउने ट्राफिकमा असर गर्छ, जबकि सर्भरले ग्राहकतिर पठाउने प्रवाहहरू समेट्छ। यदि आउने डाउनलोड मात्र रोकिन्छन् भने, ग्राहक-पक्षको मान पूरै कथा होइन।
संख्या र किवर्ड पोर्टेबल छैनन्
OpenVPN 2.6 को समुदाय संस्करणले मानपछि वैकल्पिक किवर्ड स्वीकार्छ। mtu सहित, संख्याले IP र UDP हेडर सहित बाहिरी प्याकेट आकार वर्णन गर्छ; त्यसबिना, तर्क अर्को लेखा परम्परा पछ्याउँछ। त्यसैले संस्करणहरूबीच प्रतिलिपि गरिएको पङ्क्तिले एउटै प्याकेट बजेट वर्णन गर्दैन। अर्को रिलिजका लागि ट्युटोरियलको सट्टा तपाईंले साँच्चै चलाउनुभएको बिल्डसँग आउने म्यानुअल पृष्ठ हेर्नुहोस्।
वाक्यरचना यस्तो देखिन्छ:
mssfix 1400 mtu1400 लाई तपाईंको बाटोका लागि सिफारिस होइन, प्लेसहोल्डर मान्नुहोस्। मान नापिएको बाटो र साँच्चै प्रयोग हुने एन्क्याप्सुलेसनबाट निकाल्नुहोस्, र पुराना संस्करण वा अन्य कार्यान्वयनका ग्राहकहरूले किवर्ड अस्वीकार वा फरक ढङ्गले व्याख्या गर्न सक्छन् भन्ने सम्झनुहोस्।
पहिले एउटै ग्राहकमा पुष्टि गर्नुहोस्
केही बदल्नुअघि असफल मेसिनबाट बाटो नाप्नुहोस्। बाटोले खण्डनबिना बोक्न सक्ने पेलोड नै तपाईंले खोजिरहेको संख्या हो:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1पहिलो प्रोब 28 बाइट हेडर थपिएपछि 1500 बाइटको प्याकेटमा अटाउँछ। यदि यो खण्डन त्रुटिले असफल हुन्छ र सानो सफल हुन्छ भने, प्रयोगयोग्य आकार तिनीहरूबीच कतै छ, र सुरुङको ओभरहेड माथिबाट घटाइन्छ।
त्यसपछि रोकिएको स्थानान्तरण नयाँ जडानमा दोहोर्याएर तुलना गर्नुहोस्। यदि एक ग्राहक सुधारिन्छ र अरू अछुत रहन्छन् भने, तपाईंले समस्याको दायरा भेट्टाउनुभयो। यदि सबै ग्राहक रोकिन्छन् भने, सर्भर-पक्षको मान समीक्षा गर्नुपर्ने हुन्छ। दुवैमध्ये कुनै पनि नतिजाले कहिल्यै असफल बाटोमा नभएको हार्डवेयरमा परिवर्तनलाई न्यायोचित ठहराउँदैन।