Docker पोर्ट प्रकाशन र VPN स्रोत: तपाईंले छुटाउनुहुने दुई मेल

नियम भन्छ VPN सर्भरको ठेगानालाई प्रकाशित सेवामा अनुमति दिनुहोस्, रै जडान चुँडिन्छ। यो नतिजा सामान्य हो, र यो Docker को त्रुटि होइन। दुई अलग मेल गलत छन्: तपाईंले लेखेको स्रोत होस्टले प्राप्त गर्ने स्रोत नहुन सक्छ, र तपाईंले लेखेको पोर्ट फिल्टरले देख्ने पोर्ट नहुन सक्छ। दुवै सुधार्न सेवाको रेखाचित्रको सट्टा प्याकेटको मार्ग हेर्नुपर्छ।

भ्रम: VPN सर्भरलाई अनुमति दिनुहोस्, काम सकियो

रुट गरिएको VPN ले क्लाइन्टको टनेल ठेगाना Docker होस्टसम्म कायम राख्न सक्छ। स्रोत अनुवाद गर्ने गेटवेले त्यो ठेगाना आफ्नै ठेगानाले बदल्न सक्छ। दुवै डिजाइन वैध छन्, र तिनीहरूले एउटै प्रयोगकर्ता कार्यका लागि फरक स्रोत दिन्छन्।

त्यसैले VPN सर्भर IP भन्ने वाक्यांशले अनुमानको वर्णन गर्छ, अवलोकनको होइन। तपाईंको अगाडि दुईमध्ये कुन डिजाइन छ भन्ने थाहा नभएसम्म नियम एउटा अनुमान हो।

स्रोत: क्लाइन्ट पूल वा अनुवादित गेटवे

चार कुरा क्रममा जाँच्नुहोस्। पहिलो, क्लाइन्ट ठेगाना पूल, उदाहरणका लागि 10.90.0.0/24. दोस्रो, गेटवेले त्यो पूल होस्टसम्म पुग्नुअघि अनुवाद गर्छ कि गर्दैन। तेस्रो, एउटा नयाँ जडानका लागि होस्टले वास्तवमा कुन स्रोत अवलोकन गर्छ। चौथो, अनुप्रयोग प्रमाणीकरणले व्यक्तिगत प्रयोगकर्ताहरूलाई छुट्याउँछ कि छुट्याउँदैन, किनकि साझा अनुवादित ठेगानाले त्यो गर्न सक्दैन।

पूल कायम रहेमा गेटवेको सार्वजनिक ठेगानासँग मात्र मिल्ने नियमले प्रत्येक क्लाइन्ट छुटाउँछ। गेटवेले जानाजानी अनुवाद गरेमा अनुवादित ठेगानालाई अनुमति दिनुले त्यसको पछाडिका प्रत्येक प्रयोगकर्तालाई भित्र पसाउँछ, जुन आफ्नै लगइन भएको सेवाका लागि स्वीकार्य र बाँकी सबैका लागि अस्वीकार्य हुन सक्छ।

पोर्ट: DNAT ले तपाईंले मिलाउने संख्या बदल्छ

Docker iptables सहितको सामान्य Linux ब्रिज प्रकाशनमा, 8443 बाट कन्टेनर पोर्ट 443 मा हुने होस्ट म्यापिङ फर्वार्डिङ फिल्टर चल्नुअघि अनुवाद हुन्छ। प्याकेट फिल्टरकहाँ गन्तव्य पोर्ट 443 सहित पुग्छ। त्यो बिन्दुमा 8443 सँग मिल्ने नियम कहिल्यै सक्रिय हुँदैन, क्लाइन्टले टाइप गरेको 8443 भए पनि।

प्रकाशित पोर्ट अझै जडान ट्र्याकिङमा छ, त्यसैले साँच्चै आवश्यक हुँदा मूल गन्तव्य त्यहाँ मिलाउन सकिन्छ।

कुन संख्याले उद्देश्य व्यक्त गर्छ त्यो निर्णय गर्नुहोस्। नियमले कन्टेनरभित्रको सेवा जोगाएको बेला DNAT पछिको कन्टेनर पोर्टसँग मिलाउनुहोस्। नियमले क्लाइन्टले के माग्यो भन्ने वर्णन गर्नुपर्ने बेला conntrack विकल्पसँग मूल गन्तव्यसँग मिलाउनुहोस्, र त्यससँगै आउने अतिरिक्त मिलान खर्च र नियम क्रमको सावधानी स्वीकार्नुहोस्।

चेन: DOCKER-USER, INPUT होइन

Docker को iptables मार्गदर्शिकाले प्रयोगकर्ता फर्वार्डिङ नीति DOCKER-USER चेनमा राख्छ, जुन Docker का आफ्नै फर्वार्डिङ नियमहरूभन्दा अघि मूल्याङ्कन हुन्छ। होस्ट सेवाबाट INPUT चेनमा प्रतिलिपि गरिएको नियमले होस्टतर्फ सम्बोधित ट्राफिक फिल्टर गर्छ, कन्टेनरतर्फ फर्वार्ड हुने ट्राफिक होइन। त्यो गल्तीले सही देखिने तर कन्टेनरको मार्गमा कुनै प्रभाव नपार्ने नियम बनाउँछ।

स्रोत दायरा, प्रभावकारी गन्तव्य पोर्ट, प्रोटोकल र आगमन इन्टरफेसलाई एउटै नियममा सँगै राख्नुहोस्। प्रत्येक फर्वार्ड हुने गन्तव्यका लागि स्रोत-मात्र अनुमति एउटा प्रकाशित सेवालाई अनुमति दिनुभन्दा फराकिलो हुन्छ।

नयाँ जडानहरूबाट प्रमाणित गर्नुहोस्

नयाँ जडानहरूबाट दुवै दिशा परीक्षण गर्नुहोस्: एउटा अनुमति दिइएको VPN क्लाइन्ट र अस्वीकृत रहनुपर्ने एउटा स्रोत। विद्यमान जडान अवस्थाले नीति परिवर्तन भएपछि पनि सत्र जीवित राख्न सक्छ, त्यसैले पुरानो जडानले नयाँ नियमबारे केही प्रमाणित गर्दैन। त्यसपछि प्रतिक्रियाको मार्ग जाँच्नुहोस्, किनकि कन्टेनरले अझै आफूले देख्ने स्रोततर्फ फर्केर मार्ग बनाउनुपर्छ।

यी जाँचका पछाडिको चेन क्रम र पोर्ट अनुवादको व्यवहार Docker को iptables मार्गदर्शिका ले अभिलेख गर्छ। कुनै रेसिपी प्रतिलिपि गर्नुअघि त्यो पढ्नुहोस्, र स्थापना गरिएको Docker ले कुन ब्याकएन्ड प्रयोग गर्छ भनी पुष्टि गर्नुहोस्, किनकि nftables ब्याकएन्डले नीति फरक ढंगले एकीकृत गर्छ।