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 सेवाका लागि स्वीकृति परीक्षण होइन।

नियमहरू कन्टेनरको समर्थित स्टार्टअप कन्फिगरेसनमा राख्नुहोस्, किनकि पुनः सिर्जना गर्दा अन्तरक्रियात्मक सम्पादन हराउँछ। होस्ट पोर्ट प्रकाशन फरक जोखिम मार्ग हो र सेवा टनेलबाट पुग्ने भएकै कारण मात्र आवश्यक हुँदैन।