आपका Docker VPN पोर्ट मैपिंग OpenVPN तक कभी क्यों नहीं पहुँचता

आपका कंटेनर UDP 1195 पर सुन सकता है जबकि होस्ट 1194 प्रकाशित करता है, और यह सही है जब तक मैपिंग ऐसा कहती है। संख्याएँ एक अनुवाद तालिका बनाती हैं: क्लाइंट होस्ट पोर्ट पर डायल करता है, Docker गंतव्य को कंटेनर पोर्ट पर फिर से लिखता है, और OpenVPN उस पोर्ट पर उत्तर देता है जो उसका अपना कॉन्फ़िगरेशन बताता है। इनमें से किसी भी कड़ी में बेमेल एक मौन विफलता पैदा करता है जो फ़ायरवॉल जैसी दिखती है। प्रमाणपत्र और सिफ़र इसके बाद आते हैं और इसे ठीक नहीं कर सकते।

प्रमाणीकरण के बारे में कुछ भी बदलने से पहले एक पैकेट को क्लाइंट से प्रक्रिया तक ट्रैक करें।

तीन संख्याएँ, एक कनेक्शन

तीन संख्याएँ हैं वह दूरस्थ गंतव्य जो क्लाइंट उपयोग करता है, होस्ट पर प्रकाशित मैपिंग, और कंटेनर के भीतर का श्रोता। उनका बराबर होना ज़रूरी नहीं, पर उन्हें श्रृंखला बनानी चाहिए। बराबर संख्याएँ एक विशेष स्थिति है जो संयोग से सबसे आम है, इसीलिए बेमेल एक बार लिखना आसान और बाद में देखना कठिन होता है।

डिबग करने से पहले श्रृंखला को एक पंक्ति में लिखें: क्लाइंट पता और पोर्ट, होस्ट मैपिंग, कंटेनर श्रोता, ट्रांसपोर्ट। श्रृंखला में दोष उस संख्या के रूप में दिखता है जो अलग-अलग मानों के साथ दो बार आती है।

संक्षिप्त सिंटैक्स वास्तव में क्या कहता है

संक्षिप्त रूप में बाईं ओर होस्ट पोर्ट है और दाईं ओर कंटेनर पोर्ट, और स्लैश प्रत्यय ट्रांसपोर्ट चुनता है। प्रत्यय छोड़ दें तो Docker मैपिंग को TCP मानता है, इसलिए प्रोटोकॉल के बिना मैपिंग के पीछे का UDP श्रोता ऐसा श्रोता है जहाँ कोई नहीं पहुँच सकता। यह डिफ़ॉल्ट प्रलेखित है और फिर भी उन लोगों को चौंकाता है जिन्होंने संख्याएँ मिला लीं और काम ख़त्म मान लिया।

लंबा रूप बाइंड पता और प्रोटोकॉल स्पष्ट रूप से तय करता है, जो नेटवर्क की ओर खुले किसी भी चीज़ के लिए अतिरिक्त पंक्तियों के योग्य है। जिस फ़ाइल ने मैपिंग बनाई उस पर भरोसा करने के बजाय प्रकाशित मैपिंग को फिर से पढ़ें।

ports:
  - 1194:1195/udp

पैकेट कहाँ रुक सकता है

कोई अनुरोध Docker से पहले, Docker में, या श्रोता पर गिराया जा सकता है। Docker से आगे क्लाउड फ़ायरवॉल या अपना फ़ॉरवर्डिंग करने वाला राउटर हो सकता है, और उस डिवाइस को होस्ट की ओर वाला पोर्ट और सही ट्रांसपोर्ट चाहिए। Docker के भीतर, ग़लत कंटेनर पोर्ट की मैपिंग बंद सॉकेट पर फ़ॉरवर्ड करती है।

फिर श्रोता: OpenVPN का कॉन्फ़िगरेशन एक पोर्ट और प्रोटोकॉल बताता है, और कंटेनर के भीतर किसी दूसरे पर आने वाला क्लाइंट कहीं नहीं पहुँचता। UDP सेवा का TCP से परीक्षण इनमें से किसी भी चरण में कुछ साबित नहीं करता, इसलिए वही ट्रांसपोर्ट इस्तेमाल करें जो क्लाइंट इस्तेमाल करेगा।

बाइंड पते पहुँच तय करते हैं

loopback से बंधी प्रकाशित मैपिंग केवल होस्ट से पहुँची जा सकती है, जबकि सभी इंटरफ़ेस से बंधी मैपिंग वहाँ तक पहुँची जा सकती है जहाँ फ़ायरवॉल अनुमति देता है। पता छोड़ने वाली Compose फ़ाइल में दोनों एक जैसी दिखती हैं, और Docker का डिफ़ॉल्ट चौड़ा है।

तय करें कि परिनियोजन कौन-सा प्रदर्शन चाहता है, फिर उसे स्पष्ट लिखें। loopback से जुड़ने वाला आंतरिक परीक्षण और जुड़ न पाने वाला दूरस्थ क्लाइंट दोनों एक ही कंटेनर के सटीक विवरण हो सकते हैं।

चालू स्थिति पढ़ें

चालू कंटेनर की प्रभावी मैपिंग और उसके नेटवर्क नामस्थान में श्रोता की जाँच करें। कंटेनर शुरू होने के बाद Compose फ़ाइल संपादित हो सकती है, इमेज मेटाडेटा किसी पोर्ट को प्रकाशित किए बिना घोषित कर सकता है, और दूसरा कंटेनर पहले से होस्ट पोर्ट रख सकता है। इमेज में पोर्ट घोषित करना उसे प्रकाशित करना नहीं है, और इनमें से कोई भी सुनने के बराबर नहीं है।

तीन अलग स्थितियाँ, तीन अलग कमांड, और केवल अंतिम OpenVPN से जुड़ा है।

मैपिंग सही होने के बाद

पैकेट OpenVPN तक पहुँचने के बाद उसका लॉग TLS और प्रमाणीकरण के बारे में पढ़ने की जगह है। कभी न आए पैकेट को ठीक करने के लिए प्रमाणपत्र फिर से बनाना व्यर्थ काम है जो दूसरा चर जोड़ता है। मैपिंग का नोट क्लाइंट प्रोफ़ाइल के पास रखें ताकि अगला व्यक्ति तीनों संख्याएँ फिर से खोजने के बजाय एक पंक्ति पढ़े। होस्ट की ओर एक पैकेट कैप्चर तय करता है कि तीन कड़ियों में से कौन-सी ग़लत है, और इसकी लागत प्रमाणपत्र दोबारा बनाने से कम है।

यहाँ वर्णित मामला ब्रिज प्रकाशन है। होस्ट नेटवर्किंग और रूटेड कंटेनर पते अनुवाद छोड़ देते हैं, इसलिए उन डिज़ाइनों में वही संख्याएँ कुछ और अर्थ रखती हैं।