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 बाइट पॅकेटमध्ये बसते। जर ती विभाजन त्रुटीने अयशस्वी होते आणि लहान यशस्वी होते, तर वापरण्यायोग्य आकार त्यांच्यामध्ये कुठेतरी आहे, आणि टनेलचा ओव्हरहेड वरून वजा केला जातो।
नंतर थांबलेले हस्तांतरण नवीन जोडणीवर पुन्हा करा आणि तुलना करा। एक क्लायंट सुधारतो आणि बाकीचे अस्पर्शित राहतात, तर तुम्ही समस्येची व्याप्ती शोधली आहे। प्रत्येक क्लायंट थांबत असेल, तर सर्व्हर-बाजूचे मूल्य पुनरावलोकनासाठी आहे। दोन्हीपैकी कोणताही निकाल अशा हार्डवेअरवर बदलाचे समर्थन करत नाही जे कधीही अयशस्वी मार्गात नव्हते।