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 कौन-सा backend उपयोग करता है, क्योंकि nftables backend नीति को अलग ढंग से एकीकृत करता है।