कॉर्पोरेट 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 प्रयोगाचा उरलेला भाग हे कळणार नाही.