कॉर्पोरेट 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 प्रयोग का अवशेष।