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 ही सेवेसाठी स्वीकृती चाचणी नाही.

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