तपाईंको Docker VPN पोर्ट म्यापिङ OpenVPN सम्म किन कहिल्यै पुग्दैन
होस्ट पोर्ट, कन्टेनर पोर्ट र ट्रान्सपोर्ट तीनवटा छुट्टाछुट्टै निर्णय हुन्। प्रमाणपत्र छुनु अघि एउटा UDP प्रयास हरेक सीमाबाट पछ्याउनुहोस्।
तपाईंको कन्टेनरले UDP 1195 मा सुन्न सक्छ जबकि होस्टले 1194 प्रकाशित गर्छ, र म्यापिङले त्यसो भनेसम्म यो सही हो। सङ्ख्याहरूले एउटा अनुवाद तालिका बनाउँछन्: क्लाइन्टले होस्ट पोर्ट डायल गर्छ, Docker ले गन्तव्यलाई कन्टेनर पोर्टमा पुनर्लेखन गर्छ, र OpenVPN ले आफ्नै कन्फिगरेसनले नाम दिएको पोर्टमा जवाफ दिन्छ। यी कडीमध्ये कुनै एकमा बेमेल भएमा फायरवालजस्तो देखिने मौन असफलता उत्पन्न हुन्छ। प्रमाणपत्र र साइफर यसको तलपट्टि हुन्छन् र यसलाई सुधार्न सक्दैनन्।
प्रमाणीकरणबारे केही परिवर्तन गर्नु अघि एउटा प्याकेट क्लाइन्टबाट प्रक्रियासम्म पछ्याउनुहोस्।
तीन सङ्ख्या, एउटा जडान
ती तीन सङ्ख्या क्लाइन्टले प्रयोग गर्ने टाढाको गन्तव्य, होस्टमा प्रकाशित म्यापिङ र कन्टेनरभित्रको श्रोता हुन्। ती बराबर हुनु जरुरी छैन, तर शृङ्खला बनाउनुपर्छ। बराबर सङ्ख्या संयोगवश सबैभन्दा सामान्य हुने विशेष अवस्था हो, त्यसैले बेमेल एकचोटि लेख्न सजिलो र पछि देख्न गाह्रो हुन्छ।
डिबग गर्नु अघि शृङ्खला एउटा लाइनमा लेख्नुहोस्: क्लाइन्ट ठेगाना र पोर्ट, होस्ट म्यापिङ, कन्टेनर श्रोता, ट्रान्सपोर्ट। शृङ्खलाको दोष फरक मानसहित दुईचोटि आउने सङ्ख्याको रूपमा देखिन्छ।
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN 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 र प्रमाणीकरणबारे पढ्ने ठाउँ हो। कहिल्यै नआएको प्याकेट सुधार्न प्रमाणपत्र पुनः उत्पादन गर्नु दोस्रो चल थप्ने व्यर्थ काम हो। म्यापिङको टिप्पणी क्लाइन्ट प्रोफाइलको छेउमा राख्नुहोस् ताकि अर्को व्यक्तिले तीनै सङ्ख्या फेरि पत्ता लगाउनुको सट्टा एउटा लाइन पढोस्। होस्टतर्फ एकचोटि प्याकेट क्याप्चर गर्दा तीन कडीमध्ये कुन गलत हो निर्धारण हुन्छ, र यसको लागत प्रमाणपत्र पुनः उत्पादन गर्नुभन्दा कम हुन्छ।
यहाँ वर्णन गरिएको अवस्था ब्रिज प्रकाशन हो। होस्ट नेटवर्किङ र रुट गरिएका कन्टेनर ठेगानाले अनुवाद छोड्छन्, त्यसैले ती डिजाइनमा उही सङ्ख्याले अर्कै अर्थ राख्छन्।