VPN कंटेनर में DNAT: फ़ॉरवर्डिंग, INPUT नहीं

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

अनुवाद के बाद पैकेट का पीछा करें

10.90.0.0/24 का क्लाइंट पूल और 10.90.0.1 का टनल पता लें। एक ब्रिज पर दो कंटेनर हैं: 192.0.2.2 VPN चलाता है और 192.0.2.3 एप्लिकेशन चलाता है। कोई क्लाइंट 10.90.0.1:8080 से जुड़ता है, और VPN कंटेनर के नेमस्पेस में DNAT नियम उसे एप्लिकेशन के असली पते और पोर्ट में बदल देता है। फिर कोई रूट पैकेट को ब्रिज से भेजता है। ये पते उदाहरण भर हैं, कोई परिनियोजन विधि नहीं।

जिस पोर्ट पर एप्लिकेशन वास्तव में सुनता है वह होस्ट पर प्रकाशित किसी भी पोर्ट से अलग हो सकता है। दोनों संख्याएँ मेल खाती होंगी यह मानने के बजाय कंटेनर के भीतर का श्रोता पढ़ें।

अनुमति फ़ॉरवर्ड मार्ग पर है

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

दायरा संकीर्ण रखें: एक स्रोत श्रेणी, एक गंतव्य, एक सेवा। ढीला फ़ॉरवर्डिंग नियम लिखना आसान है और बाद में उसका बचाव करना कहीं कठिन।

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker की चेन आपके कंटेनर की चेन नहीं हैं

कंटेनर के नेमस्पेस के भीतर के नियम Docker होस्ट के नियम नहीं हैं। जब ट्रैफ़िक टनल इंटरफ़ेस से ब्रिज तक जाता है, तब होस्ट का ब्रिज फ़ायरवॉल दूसरा निर्णय ले सकता है। Docker के iptables बैकएंड के साथ, प्रलेखित फ़ॉरवर्डिंग चेन और DNAT के बाद के मिलान बिंदु वहीं हैं जहाँ यह निर्णय दिखता है।

Docker फ़ायरवॉल संदर्भ उन चेन और DNAT के बाद के मिलान का वर्णन करता है। Docker के फ़ायरवॉल प्रबंधन को बंद करके या हर चेन को ढीला बनाकर गायब स्वीकृति ठीक न करें, क्योंकि इससे वह सीमा हट जाती है जिसका आप उपयोग करना चाहते हैं।

वापसी मार्ग को सचेत चुनाव बनाएँ

यदि स्रोत पता सुरक्षित रहता है, तो एप्लिकेशन 10.90.0.x देखता है और उत्तरों को VPN कंटेनर से होकर वापस भेजना होता है। अन्यथा उसका सामान्य Docker गेटवे उन्हें होस्ट पर भेज देगा, जिसके पास टनल नहीं है। विकल्प है VPN कंटेनर पर संकीर्ण स्रोत अनुवाद, जो उत्तर को सरल बनाता है पर एप्लिकेशन से क्लाइंट छिपा देता है। सोच-समझकर चुनें और लिख लें कि आपने कौन-सा चुना।

किसी सामान्य क्लाइंट से नया अनुमत कनेक्शन जाँचें, फिर पुष्टि करें कि असंबंधित पोर्ट बंद रहते हैं। जब पैकेट गायब हो, तो VPN नेमस्पेस, एप्लिकेशन नेमस्पेस और एप्लिकेशन का अपना लॉग देखें। ब्रिज गेटवे पर ping सेवा के लिए स्वीकृति परीक्षण नहीं है।

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