तपाईंले टनेलको 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 सिद्धान्त अप्रमाणित छ। टनेलमा ट्राफिक समात्नुहोस् र संख्या फेरि बदल्नुअघि कुन पक्षले पठाउन छोड्छ हेर्नुहोस्, र अघिल्लो मान लेखिएको राख्नुहोस् ताकि रोलब्याक एउटै आदेश रहोस्।