Docker पोर्ट प्रकाशन विरुद्ध VPN: जवाफ कहाँ जान्छ

पूर्ण टनेल VPN माथि आएपछि पनि होस्टले SSH मा जवाफ दिइरहन्छ, तर त्यही मेसिनमा Docker मार्फत प्रकाशित सेवा चुप हुन्छ। सुन्नेमा कुनै गडबड छैन: कन्टेनर चलिरहेको छ, पोर्ट म्यापिङ छ, र प्याकेट आइपुग्छ। कन्टेनर स्वस्थ छ र अनुरोध साँच्चै त्यसमा पुग्छ। फरक यो हो कि Linux ले आफ्नो मार्ग छान्दा जवाफ कहाँबाट सुरु हुन्छ, र त्यही फरकले तलका दुई डिजाइनमध्ये तपाईंलाई कुन चाहिन्छ भन्ने निर्धारण गर्छ।

गन्तव्य NAT हुँदै टपल पछ्याउनुहोस्

एउटा होस्ट लिनुहोस् 192.0.2.10 मा, जसले TCP 2222 172.30.240.5:22 को कन्टेनरमा प्रकाशित गर्छ। 198.51.100.25 बाट आएको अनुरोध कन्टेनरमा पुग्नुअघि अनुवाद हुन्छ, र कन्टेनर आफैंका रूपमा जवाफ दिन्छ।

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

होस्टको मार्ग निर्णयमा जवाफले अझै कन्टेनरको स्रोत ठेगाना बोक्छ। रिभर्स अनुवादले पछि प्रकाशित टपल पुनर्स्थापित गर्छ, र त्यसैले मार्ग छानिएको ठीक त्यही क्षणमा प्याकेट गलत देखिन्छ।

किन होस्टका लागि मात्रको नियमले यसलाई छुटाउँछ

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

अति-सुधार भनेको कन्टेनरबाट सबै कुरा WAN मार्फत मार्गनिर्देशन गर्नु हो, जसले कन्टेनरका असम्बन्धित बाहिर जाने जडानहरूलाई पनि VPN बाट मुक्त गर्छ। त्यो मागिएको नीतिभन्दा फरक हो, र सामान्यतया पछि कसैलाई छक्क पार्छ।

DNAT पछिको मिलान अर्को हुक हो

Docker को फायरवाल कागजात ले औंल्याउँछ कि सामान्य प्रयोगकर्ता फिल्टरिङले DNAT पछिको गन्तव्य देख्छ, त्यसैले सामान्य नियममा प्रकाशित पोर्ट 2222 मिलाउनु कन्टेनर पोर्ट 22 मिलाउनु जस्तै होइन। यदि मूल टपल महत्त्वपूर्ण छ भने, कुन पोर्ट देखिन्छ भनेर अनुमान गर्नुको सट्टा समर्थित मूल-गन्तव्य संयन्त्र प्रयोग गर्नुहोस्।

यो हुक भ्रमले सही देखिने तर कहिल्यै नमिल्ने नियमहरू बनाउँछ। नीति पुनःलेख्नुअघि नियममै काउन्टरहरू जाँच्नुहोस्। शून्य हिट भएको नियमले तपाईंलाई भन्छ कि यो प्याकेट कहिल्यै नपुग्ने ठाउँमा मूल्याङ्कन भइरहेको छ।

डिजाइन A: निर्णयलाई जडान अवस्थाको रूपमा बोक्नुहोस्

जडान मार्कले प्रवेश निर्णयलाई अनुवादभरि बोक्न सक्छ, तर महत्त्वपूर्ण मार्ग खोजीअघि यसलाई प्याकेटमा पुनर्स्थापित गर्नुपर्छ। चरणहरू यी हुन्:

1. Docker, VPN वा अन्य नीति-मालिकसँग नटक्किने मार्क फाँट र नियम प्राथमिकता आरक्षित गर्नुहोस्।
2. जडान ट्र्याकिङ उपलब्ध हुने DNAT-पूर्व बिन्दुमा मात्र इच्छित नयाँ WAN जडान पहिचान गर्नुहोस्।
3. मूल अनुरोधलाई नै WAN तालिकामा धकेल्नुबिना निर्णयलाई जडान मार्कमा लेख्नुहोस्।
4. जवाफ दिशामा, मार्गनिर्देशनअघि प्याकेटमा आफ्नै मार्क बिटहरू मात्र पुनर्स्थापित गर्नुहोस्।
5. VPN नियमले पहिले जित्न नसक्ने गरी पूर्ण WAN तालिका पर्याप्त चाँडो छान्नुहोस्।

त्यो तालिकालाई वास्तविक जोडिएका मार्गहरू र गेटवे चाहिन्छ। मार्ग नभएको बेलाको परिभाषित व्यवहार पनि चाहिन्छ। सुरुङमा चुपचाप खस्नु सबैभन्दा नराम्रो परिणाम हो, किनकि कन्फिगरेसन अझै काम गरिरहेको जस्तो देखिन्छ। बरु बन्द रूपमा असफल हुनुहोस् र त्यो लग गर्नुहोस्।

डिजाइन B: होस्टमा अन्त्य गर्नुहोस्

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

लागत भनेको आफ्नै कन्फिगरेसन, स्रोत-ठेगाना व्यवस्थापन र पहुँच नियन्त्रण भएको अर्को चल्ने भाग हो। यो सामान्यतया सरल समर्थित सीमा हो, र मार्गनिर्देशन नीति छोडेर जान सक्ने एक व्यक्तिले मर्मत गर्ने भए यो प्रायः सही उत्तर हुन्छ।

परिवर्तन प्रमाणित गर्नुहोस्, मनसाय होइन

सार्वजनिक पक्षबाट नयाँ अधिकृत जडान खोल्नुहोस् र जवाफ इच्छित इन्टरफेसबाट बाहिर जान्छ भनी पुष्टि गर्नुहोस्। त्यसपछि कन्टेनरले सुरु गरेको असम्बन्धित अनुरोध अझै VPN पछ्याइरहेको छ कि जाँच्नुहोस्।

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