तुमचा कंटेनर UDP 1195 वर ऐकू शकतो, तर होस्ट 1194 प्रकाशित करतो, आणि मॅपिंग तसे सांगत असेल तोपर्यंत ते बरोबर आहे. अंक एक भाषांतर तक्ता तयार करतात: क्लायंट होस्ट पोर्टवर डायल करतो, Docker गंतव्य कंटेनर पोर्टवर पुन्हा लिहितो, आणि OpenVPN त्याच्या स्वतःच्या कॉन्फिगरेशनने नामनिर्देशित केलेल्या पोर्टवर उत्तर देतो. यापैकी कोणत्याही दुव्यात तफावत असल्यास फायरवॉलसारखे दिसणारे मूक अपयश निर्माण होते. प्रमाणपत्रे आणि सिफर याच्या पुढे असतात आणि ते हे दुरुस्त करू शकत नाहीत.

प्रमाणीकरणाबद्दल काहीही बदलण्यापूर्वी एक पॅकेट क्लायंटपासून प्रक्रियेपर्यंत पुढे न्या.

तीन अंक, एक कनेक्शन

हे तीन अंक म्हणजे क्लायंट वापरत असलेले दूरचे गंतव्य, होस्टवर प्रकाशित मॅपिंग आणि कंटेनरच्या आतला श्रोता. ते समान असणे आवश्यक नाही, पण साखळी तयार करणे आवश्यक आहे. समान अंक ही योगायोगाने सर्वात सामान्य असलेली विशेष स्थिती आहे, म्हणून तफावत एकदा लिहिणे सोपे आणि नंतर पाहणे कठीण असते.

डीबग करण्यापूर्वी साखळी एका ओळीत लिहा: क्लायंटचा पत्ता आणि पोर्ट, होस्ट मॅपिंग, कंटेनर श्रोता, ट्रान्सपोर्ट. साखळीतील दोष वेगवेगळ्या मूल्यांसह दोन वेळा येणाऱ्या अंकाच्या रूपात दिसतो.

LocationExample
Remote client destinationHost address, UDP 1194
Published mappingHost UDP 1194 to container UDP 1195
Container listenerOpenVPN on UDP 1195

लहान सिंटॅक्स प्रत्यक्षात काय सांगतो

लहान स्वरूपात डावी बाजू होस्ट पोर्ट आणि उजवी बाजू कंटेनर पोर्ट असते, आणि स्लॅश प्रत्यय ट्रान्सपोर्ट निवडतो. प्रत्यय सोडला तर Docker मॅपिंगला TCP मानतो, त्यामुळे प्रोटोकॉलशिवाय मॅपिंगच्या मागील UDP श्रोता हा असा श्रोता आहे जिथे कोणीही पोहोचू शकत नाही. हा डीफॉल्ट दस्तऐवजीकृत आहे आणि अंक जुळवून काम संपले असे मानणाऱ्यांना तो अजूनही आश्चर्यचकित करतो.

मोठे स्वरूप बाइंड पत्ता आणि प्रोटोकॉल स्पष्टपणे निश्चित करते, जे नेटवर्ककडे असलेल्या कोणत्याही गोष्टीसाठी अतिरिक्त ओळींच्या योग्य आहे. मॅपिंग तयार करणाऱ्या फाइलवर विश्वास ठेवण्याऐवजी प्रकाशित मॅपिंग पुन्हा वाचा.

ports:
  - 1194:1195/udp

पॅकेट कुठे थांबू शकतो

विनंती Docker च्या आधी, Docker मध्ये किंवा श्रोत्याकडे टाकून दिली जाऊ शकते. Docker च्या पुढे क्लाउड फायरवॉल किंवा स्वतःचे फॉरवर्डिंग करणारा राउटर असू शकतो, आणि त्या उपकरणाला होस्टकडील पोर्ट आणि योग्य ट्रान्सपोर्ट लागतो. Docker च्या आत चुकीच्या कंटेनर पोर्टचे मॅपिंग बंद सॉकेटकडे पाठवते.

मग श्रोता: OpenVPN चे कॉन्फिगरेशन पोर्ट आणि प्रोटोकॉल नामनिर्देशित करते, आणि कंटेनरमध्ये दुसऱ्या पोर्टवर येणारा क्लायंट कुठेही पोहोचत नाही. UDP सेवेची TCP ने चाचणी या कोणत्याही टप्प्यावर काहीही सिद्ध करत नाही, म्हणून क्लायंट जो ट्रान्सपोर्ट वापरणार आहे तोच वापरा.

बाइंड पत्ते पोहोच निश्चित करतात

loopback ला बांधलेले प्रकाशित मॅपिंग फक्त होस्टवरून पोहोचण्यायोग्य असते, तर सर्व इंटरफेसना बांधलेले फायरवॉल परवानगी देतो तिथे पोहोचण्यायोग्य असते. पत्ता वगळणाऱ्या Compose फाइलमध्ये दोन्ही सारखीच दिसतात, आणि Docker चा डीफॉल्ट रुंद आहे.

तैनाती कोणते प्रदर्शन हेतूने करते हे ठरवा, मग ते स्पष्ट लिहा. loopback वरून जोडणारी अंतर्गत चाचणी आणि जोडू न शकणारा दूरचा क्लायंट दोन्ही एकाच कंटेनरचे अचूक वर्णन असू शकतात.

चालू स्थिती वाचा

चालू कंटेनरचे प्रभावी मॅपिंग आणि त्याच्या नेटवर्क नामस्थानातील श्रोता तपासा. कंटेनर सुरू झाल्यानंतर Compose फाइल संपादित झालेली असू शकते, इमेज मेटाडेटा पोर्ट प्रकाशित न करता घोषित करू शकते, आणि दुसरा कंटेनर आधीच होस्ट पोर्ट धरून असू शकतो. इमेजमध्ये पोर्ट घोषित करणे म्हणजे तो प्रकाशित करणे नाही, आणि दोन्हीपैकी कोणतेही ऐकण्यासारखे नाही.

तीन वेगळ्या स्थिती, तीन वेगळ्या आज्ञा, आणि फक्त शेवटची OpenVPN शी संबंधित आहे.

मॅपिंग बरोबर झाल्यानंतर

पॅकेट OpenVPN पर्यंत पोहोचल्यावर त्याचा लॉग TLS आणि प्रमाणीकरणाबद्दल वाचण्याची जागा आहे. कधीही न आलेले पॅकेट दुरुस्त करण्यासाठी प्रमाणपत्रे पुन्हा तयार करणे हे दुसरे चल जोडणारे वायफळ काम आहे. मॅपिंगची नोंद क्लायंट प्रोफाइलजवळ ठेवा जेणेकरून पुढील व्यक्ती तीनही अंक पुन्हा शोधण्याऐवजी एक ओळ वाचेल. होस्टच्या बाजूला एकदा पॅकेट कॅप्चर केल्यास तीनपैकी कोणता दुवा चुकीचा आहे हे ठरते, आणि त्याचा खर्च प्रमाणपत्र पुन्हा तयार करण्यापेक्षा कमी आहे.

येथे वर्णन केलेली परिस्थिती ब्रिज प्रकाशनाची आहे. होस्ट नेटवर्किंग आणि राउटेड कंटेनर पत्ते भाषांतर वगळतात, म्हणून त्या रचनांमध्ये तेच अंक वेगळा अर्थ देतात.

संबंधित लेख