कर्पोरेट VPN मा कन्टेनरको HTTPS अड्किन्छ? DTLS पाइला जाँच्नुहोस्

कर्पोरेट VPN पछाडिको कन्टेनरभित्र DNS समाधान हुन्छ, लगइन पृष्ठ लोड हुन्छ, स्वास्थ्य अन्तबिन्दुले जवाफ दिन्छ, र त्यसपछि HTTPS अनुरोध समयसीमा सकिएसम्म अड्किन्छ। इमेज पुनः निर्माण गर्नु र प्रोक्सी चलहरू बदल्नु केही बदल्दैन, किनकि असफल हुने भाग इमेजमा छैन। क्लाइन्टले एउटा ट्रान्सपोर्टमा प्रमाणीकरण गर्छ र ठूलो डाटा अर्कोमा सार्छ, र दोस्रो मात्र बिग्रेको छ।

दुई ट्रान्सपोर्ट, एउटा भ्रमित लक्षण

TLS आधारित कर्पोरेट क्लाइन्ट सामान्यतया साधारण TLS जडानमा प्रमाणीकरण गर्छ, त्यसपछि सत्रका लागि UDP आधारित दोस्रो डाटा च्यानल वार्ता गर्छ। त्यो दोस्रो पाइला चल्दा थ्रूपुट र विलम्ब सुधार हुन्छ। त्यो फिल्टर भयो वा बाटोमा अटेन भने, ठूलो स्थानान्तरण अघिको सबै सफल हुन्छ र स्थानान्तरण आफै रोकिन्छ, जुन ठ्याक्कै माथिको ढाँचा हो।

कन्टेनरले त्यो वार्ता बदल्दैन; बाहिरी प्याकेट जाने बाटो बदल्छ। होस्टले कन्टेनरको प्रवाह अनुवाद गर्छ, त्यसैले UDP डाटाग्राम क्लाइन्टको स्थानीय सकेटभन्दा फरक स्रोत पोर्टबाट निस्कन्छन् र स्थापित TCP प्रवाहभन्दा धेरै छोटो टाइमरमा सकिने अनुवाद प्रविष्टिबाट फर्किन्छन्। टनेल होस्टमा चल्यो तर कन्टेनरमा असफल भयो भने, अनुप्रयोगलाई दोष दिनु अघि ती दुई प्रवाह तुलना गर्नुहोस्। त्यो तुलनाले कुनै पनि इमेज पुनर्निर्माणभन्दा बढी निर्णय गर्छ।

अनुभूतिले होइन, प्रयोगले निर्णय गर्नुहोस्

सबैभन्दा सस्तो प्रयोगले UDP डाटा च्यानल बन्द गरेर अनुरोध दोहोर्‍याउँछ। डेस्कटप र्‍यापरको सट्टा कमाण्ड-लाइन क्लाइन्ट प्रयोग गर्नुहोस्, ताकि फ्ल्याग साँच्चै लागू होस्: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls। अड्किएको अनुरोध अब पूरा भयो भने DTLS पाइला नै समस्या थियो र बाँकी हल्ला थियो।

एउटै कन्टेनरबाट दुवै दिशामा नतिजा पुष्टि गर्नुहोस्: फ्ल्यागसहित एउटा ठूलो अनुरोध र बिना एउटा। फ्ल्यागको पछि लाग्ने व्यवहार परिवर्तन प्रमाण हो; अन्ततः लोड हुने पृष्ठ प्रमाण होइन।

फ्ल्यागले सुधार्छ भने किन हो निर्णय गर्नुहोस्

तीन अवस्थाले एउटै लक्षण उत्पन्न गर्छन् र फरक प्रतिक्रिया माग्छन्। बाटोले UDP पूर्ण रूपमा फिल्टर गर्न सक्छ, जसले त्यो सञ्जालका लागि फ्ल्यागलाई सही स्थायी उत्तर बनाउँछ। बाटोले UDP अनुमति दिन सक्छ तर ठूला डाटाग्राम फ्याँक्न सक्छ, जुन फिल्टरिंग होइन MTU तिर संकेत गर्छ। वा बाटो यति हानिप्रवण हुन सक्छ कि UDP पाइला TCP भन्दा खराब चल्छ, जुन क्षमताको निर्णय हो, पहुँचको होइन।

वैकल्पिक उपाय अभिलेख गर्नु अघि तिनीहरूलाई छुट्याउनुहोस्। फिल्टरिंग हरेक प्याकेट आकारमा टिक्छ, MTU समस्या सीमाभन्दा माथि मात्र देखिन्छ, र हानि सफा अड्किने रूपमा होइन पुनःप्रेषण र बदलिने ढिलाइका रूपमा देखिन्छ। हरेक परीक्षणले क्लाइन्ट कन्फिगरेसन नबदली कारण साँघुरो बनाउँछ।

वैकल्पिक उपाय राख्नु अघि प्याकेट आकार जाँच्नुहोस्

कारण आकार हो भने, टनेल इन्टरफेसले बाटोले बोक्न नसक्ने प्याकेट स्वीकार्छ, र पेलोड बढ्ने बित्तिकै कुनै पनि ट्रान्सपोर्टमा समस्या फर्किन्छ। इन्टरफेसहरू तुलना गर्नुहोस्: होस्टमा ip link show tun0, त्यसपछि सञ्जाल विकल्पमा अभिलेख भएको MTU पढ्न docker network inspect bridge। कम बोक्ने टनेलमुनि अझै 1500 बाइटमा रहेको कन्टेनर ब्रिज सामान्य भेटाइ हो।

टनेलभित्र विभाजन निषेध परीक्षणसँग ज्ञात राम्रो आकारबाट माथि खोज्नुहोस्, त्यसपछि कन्टेनर सञ्जालको MTU घटाउनुहोस् वा टनेलमा TCP MSS क्ल्याम्प गर्नुहोस्। यी दुईमध्ये कुनै पनि सुधारले प्रायः UDP बाटो फेरि उपयोगी बनाउँछ र फ्ल्यागको आवश्यकता हटाउँछ, फिल्टरिंग कारण नभए यो राम्रो नतिजा हो।

के साट्न तयार हुनुहुन्छ निर्णय गर्नुहोस्

डाटा च्यानल बन्द हुँदा टनेलले आफ्नो भार TCP जडानभित्र बोक्छ। सफा बाटोमा त्यो केवल ढिलो हो; हानिप्रवण बाटोमा एउटा हराएको खण्डले पछाडिको सबै ढिलो बनाउँछ र बाहिरी पुनःप्रेषण भित्रीसँग प्रतिस्पर्धा गर्छ। त्यो साटासाट अन्तरक्रियात्मक विकास र साना API कलका लागि उपयुक्त छ, र ठूलो स्थानान्तरण वा मोबाइल लिंकमा लामो सत्रका लागि खराब बस्छ।

जुनसुकै विकल्प रोज्नुभए पनि, टनेलले अन्ततः कुन ट्रान्सपोर्ट प्रयोग गर्‍यो र किन अभिलेख गर्नुहोस्। कसैले महिनौं अघि थपेको फ्ल्यागमा चुपचाप भर पर्ने कन्टेनर नै अर्को खराबी हो, र त्यसलाई डिबग गर्नेलाई फ्ल्याग फिल्टरिंगको वैकल्पिक उपाय थियो कि MTU प्रयोगको अवशेष भन्ने थाहा हुनेछैन।