OpenConnect पेज तब तक क्यों अटकते हैं जब तक आप टनल का MTU नहीं घटाते

लॉगिन सफल होता है, पोर्टल का मुख्य पेज बनता है, और फिर कोई डैशबोर्ड विजेट या रिपोर्ट waiting for host पर पड़ी रहती है जब तक ब्राउज़र हार नहीं मानता। सार्वजनिक साइटें पूरे समय सामान्य रूप से लोड होती रहती हैं, और कोई क्रेडेंशियल नहीं बदला। बड़े उत्तर अटकते रहें जबकि छोटे उत्तर आएँ, यह पैकेट-आकार की सीमा का लक्षण है, पहुँच नियम का नहीं। प्रोफ़ाइल में कुछ और बदलने से पहले इस पाठ की पुष्टि करें।

आकार की समस्या को नीति की समस्या से अलग करें

अस्वीकृति को बाहर करके शुरू करें। अगर गेटवे ने आपको अस्वीकार किया होता, तो कनेक्शन आधा पेज लोड होने के बजाय तुरंत विफल हो जाता। जो टनल ऊपर आती है और फिर केवल बड़े स्थानांतरणों में अटकती है, वह आपको बताती है कि बाहरी पथ भीतरी पैकेट नहीं ढो सकता।

तंत्र एनकैप्सुलेशन है। हर भीतरी पैकेट को टनल हेडर मिलते हैं, इसलिए जो पेलोड भौतिक लिंक में फ़िट था वह ऐसा बाहरी पैकेट बन जाता है जो अब फ़िट नहीं होता, और do-not-fragment बिट रखने वाली हर चीज़ ब्राउज़र के समझ सकने योग्य उत्तर के बिना गिरा दी जाती है।

do-not-fragment जाँच से सीमा नापें

अनुमान लगाने के बजाय सीमा नापें। ऐसी जाँच भेजें जो विखंडन से इनकार करें और उत्तर आने तक पेलोड को क़दम-दर-क़दम घटाएँ, जैसे किसी आदेश से शुरू करें ping -M do -s 1472 host। DF सेट होने पर विखंडन की ज़रूरत बताने वाला उत्तर इसका मतलब है कि मान अभी भी बहुत ऊँचा है। 1462 पर, फिर 1452 पर दोहराएँ, और जिस पहले आकार का उत्तर आए वहीं रुकें। संख्या को उस होस्ट के साथ लिख लें जिसे आपने जाँचा, क्योंकि उत्तर उसी पथ का है, सामान्य रूप से प्रोटोकॉल का नहीं।

उस पते को जाँचें जिस पर टनल वास्तव में ट्रैफ़िक भेजती है। गेटवे के सार्वजनिक नाम के विरुद्ध बाहरी जाँच और भीतरी सर्वर के विरुद्ध भीतरी जाँच अलग-अलग हॉप नापती हैं, और किसी एक पर ICMP फ़िल्टरिंग स्वस्थ पथ को टूटा दिखा सकती है।

मान को टनल डिवाइस पर लागू करें

परिणाम को उस इंटरफ़ेस पर लागू करें जो क्लाइंट ने बनाया, Wi-Fi अडैप्टर पर नहीं। लिनक्स क्लाइंट पर यह ip link set dev tun0 mtu 1300 और उसके बाद ip link show tun0 है, ताकि पुष्टि हो सके कि मान लागू हुआ। क्लाइंट जो भी डिवाइस नाम बताए वही इस्तेमाल करें, क्योंकि यह लागूआत और टनल कैसे बनी इसके अनुसार बदलता है।

टनल का MTU घटाने से हर पैकेट का पेलोड छोटा होता है, इसलिए थोक थ्रूपुट थोड़ा गिरता है, और बड़े उत्तरों को काले छेद में न फेंकने की यही क़ीमत है। छोटी संख्या अपने आप अधिक सुरक्षित नहीं होती। इसके बजाय भौतिक अडैप्टर बदलने से नुक़सान उस लिंक के हर कनेक्शन पर फैल जाता है, जबकि बहुत बड़े भीतरी पैकेट उतने ही बड़े रहते हैं।

पहले क्लाइंट के अपने MTU अनुरोध इस्तेमाल करें

जब शुरुआत आप नियंत्रित करते हैं, क्लाइंट बाद में पैच होने के बजाय आकार माँग सकता है। --mtu सर्वर से टनल MTU माँगता है, और --base-mtu अंतर्निहित पथ का MTU घोषित करता है ताकि गेटवे टनल का आँकड़ा निकाल सके। दोनों अनुरोध हैं, और क्लाइंट का मैनुअल यह वादा नहीं करता कि गेटवे इनमें से किसी एक को मानेगा।

यही अंतर आपके काम का क्रम तय करता है। पहले अनुरोध आज़माएँ और जो इंटरफ़ेस वह बनाता है उसे देखें, फिर अगर गेटवे का चुना मान अब भी अटके तो डिवाइस को स्थानीय रूप से सेट करने पर लौटें।

जो स्थानांतरण विफल हुआ उसी से सत्यापित करें, फिर उसे स्थायी बनाएँ

स्थानीय ip link बदलाव तब तक टिकता है जब तक क्लाइंट टनल फिर से नहीं बनाता, जो अगले पुनःकनेक्शन या फिर शुरू होने पर होता है। मान वहाँ रखें जहाँ कनेक्शन शुरू होता है: एक रैपर जो क्लाइंट चलाकर फिर डिवाइस समायोजित करे, ExecStartPost चरण वाली systemd यूनिट, या गेटवे के स्वीकार करने पर क्लाइंट विकल्प। इसे प्रोफ़ाइल के पास वर्ज़न नियंत्रण में रखें ताकि अगला व्यक्ति देख सके कि संख्या वहाँ क्यों है।

जो अनुरोध विफल हुआ उससे परीक्षण करें, मुख्य पेज से नहीं। रिपोर्ट खोलें, अटैचमेंट खींचें, या जो रिपॉज़िटरी फ़ेच अटका था उसे चलाएँ, और अगर वह अब भी रुकता है तो ठीक कहाँ रुकता है यह लिख लें। बदलाव के बाद बनने वाला पेज बहुत कम साबित करता है, क्योंकि वह पहले भी बनता था।

अगर वही स्थानांतरण उसी बिंदु पर अटके, तो MTU सिद्धांत अप्रमाणित है। टनल पर ट्रैफ़िक पकड़ें और संख्या फिर बदलने से पहले देखें कि कौन-सा पक्ष भेजना बंद करता है, और पिछला मान लिखा रखें ताकि रोलबैक एक ही आदेश रहे।