तुम्ही टनलचा MTU कमी करेपर्यंत OpenConnect पृष्ठे का अडकतात

लॉगिन यशस्वी होते, पोर्टलचे मुख्य पृष्ठ रेखाटले जाते, आणि नंतर एखादे डॅशबोर्ड विजेट किंवा अहवाल ब्राउझर हार मानेपर्यंत waiting for host स्थितीत राहते. सार्वजनिक साइट्स संपूर्ण वेळ सामान्यपणे लोड होतात, आणि कोणतेही क्रेडेन्शियल बदललेले नाही. मोठी उत्तरे अडकत असताना छोटी उत्तरे येणे हे प्रवेश नियमाचे नाही तर पॅकेट आकाराच्या मर्यादेचे लक्षण आहे. प्रोफाइलमध्ये दुसरे काहीही बदलण्यापूर्वी हे वाचन पुष्टी करा.

आकाराची समस्या धोरणाच्या समस्येपासून वेगळी करा

नकार बाद करून सुरुवात करा. गेटवेने तुम्हाला नाकारले असते तर पृष्ठ अर्धे लोड होण्याऐवजी कनेक्शन लगेच अयशस्वी झाले असते. टनल वर येते आणि नंतर फक्त मोठ्या हस्तांतरणांमध्ये अडकते याचा अर्थ बाहेरील मार्ग आतील पॅकेट वाहू शकत नाही.

यंत्रणा एन्कॅप्सुलेशन आहे. प्रत्येक आतील पॅकेटला टनल हेडर मिळतात, त्यामुळे भौतिक दुव्यात बसणारा पेलोड आता न बसणारा बाहेरील पॅकेट बनतो, आणि do-not-fragment बिट असलेले काहीही ब्राउझरला समजण्याजोग्या उत्तराशिवाय टाकून दिले जाते.

do-not-fragment तपासण्यांनी मर्यादा मोजा

अंदाज लावण्याऐवजी मर्यादा मोजा. विभाजन नाकारणाऱ्या तपासण्या पाठवा आणि उत्तर येईपर्यंत पेलोड टप्प्याटप्प्याने कमी करा, अशा आदेशाने सुरुवात करा: ping -M do -s 1472 host. DF सेट असताना विभाजन आवश्यक असल्याची तक्रार करणारे उत्तर म्हणजे मूल्य अजूनही खूप जास्त आहे. 1462 वर, नंतर 1452 वर पुनरावृत्ती करा, आणि उत्तर देणाऱ्या पहिल्या आकारावर थांबा. संख्या तुम्ही तपासलेल्या होस्टसह लिहून ठेवा, कारण उत्तर त्या मार्गाचे आहे, सामान्यपणे प्रोटोकॉलचे नाही।

टनल प्रत्यक्षात ज्या पत्त्यावर रहदारी पाठवते तो तपासा. गेटवेच्या सार्वजनिक नावाविरुद्ध बाहेरील तपासणी आणि अंतर्गत सर्व्हरविरुद्ध आतील तपासणी वेगवेगळे हॉप मोजतात, आणि दोन्हीपैकी कोणत्याही एकावर ICMP गाळणी निरोगी मार्ग तुटलेला दाखवू शकते.

मूल्य टनल उपकरणावर लागू करा

निकाल Wi-Fi अडॅप्टरवर नाही तर क्लायंटने तयार केलेल्या इंटरफेसवर लागू करा. Linux क्लायंटवर ते ip link set dev tun0 mtu 1300 आणि नंतर मूल्य स्वीकारले गेल्याची खात्री करण्यासाठी ip link show tun0 आहे. क्लायंट जे उपकरण नाव सांगेल तेच वापरा, कारण ते अंमलबजावणी आणि टनल कशी बांधली गेली यानुसार बदलते.

टनलचा MTU कमी केल्याने प्रत्येक पॅकेट वाहणारा पेलोड लहान होतो, त्यामुळे एकूण थ्रूपुट थोडेसे घटते, आणि मोठी उत्तरे काळ्या छिद्रात न टाकण्याची हीच किंमत आहे. लहान संख्या आपोआप अधिक सुरक्षित नसते. त्याऐवजी भौतिक अडॅप्टर बदलल्यास नुकसान त्या दुव्यावरील प्रत्येक कनेक्शनवर पसरते, तर अतिप्रमाणात मोठे आतील पॅकेट तितकेच मोठे राहतात.

प्रथम क्लायंटच्या स्वतःच्या MTU विनंत्या वापरा

जेव्हा तुम्ही कॉल नियंत्रित करता, तेव्हा क्लायंट नंतर पॅच होण्याऐवजी आकार मागू शकतो. --mtu सर्व्हरकडून टनल MTU मागते, आणि --base-mtu अंतर्निहित मार्गाचा MTU घोषित करते जेणेकरून गेटवे टनलचा आकडा काढू शकेल. दोन्ही विनंत्या आहेत, आणि क्लायंटचे मॅन्युअल गेटवे यापैकी कोणतीही मान्य करेल असे वचन देत नाही.

हा फरक तुमचा कामाचा क्रम ठरवतो. प्रथम विनंती करून पहा आणि ती जे इंटरफेस तयार करते ते पाहा, नंतर गेटवेने निवडलेले मूल्य अजूनही अडकत असल्यास उपकरण स्थानिकरित्या सेट करण्याकडे परत जा.

जे हस्तांतरण अयशस्वी झाले त्याने पडताळणी करा, नंतर ते कायमस्वरूपी करा

स्थानिक ip link बदल क्लायंटने टनल पुन्हा बांधेपर्यंत टिकतो, जे पुढील पुन्हा कनेक्शन किंवा पुन्हा सुरू करण्यावेळी होते. मूल्य तिथे ठेवा जिथे कनेक्शन सुरू होते: क्लायंट चालवून नंतर उपकरण समायोजित करणारा रॅपर, ExecStartPost पायरी असलेले systemd युनिट, किंवा गेटवे स्वीकारल्यास क्लायंट पर्याय. प्रोफाइलच्या शेजारी आवृत्ती नियंत्रणात ठेवा जेणेकरून पुढच्या व्यक्तीला संख्या तिथे का आहे ते दिसेल.

ज्या विनंती अयशस्वी झाली त्याने चाचणी करा, मुख्य पृष्ठाने नाही. अहवाल उघडा, जोडपत्र खेचा, किंवा जे रेपॉजिटरी फेच अडकले ते चालवा, आणि अजूनही अडकत असल्यास नक्की कुठे थांबते ते नोंदवा. बदलानंतर रेखाटले जाणारे पृष्ठ फारसे सिद्ध करत नाही, कारण ते आधीही रेखाटले जात होते.

जर तेच हस्तांतरण त्याच ठिकाणी अडकत असेल, तर MTU सिद्धांत अप्रमाणित आहे. टनलवर रहदारी पकडा आणि संख्या पुन्हा बदलण्यापूर्वी कोणती बाजू पाठवणे थांबवते ते तपासा, आणि मागील मूल्य नोंदवलेले ठेवा जेणेकरून रोलबॅक एकच आदेश राहील.