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. केवल इच्छित नया WAN कनेक्शन DNAT-पूर्व बिंदु पर पहचानें जहाँ कनेक्शन ट्रैकिंग उपलब्ध हो।
3. मूल अनुरोध को ही WAN तालिका में धकेले बिना फ़ैसले को कनेक्शन मार्क पर दर्ज करें।
4. जवाब की दिशा में, रूटिंग से पहले पैकेट पर केवल अपने ही मार्क बिट्स बहाल करें।
5. पूरी WAN तालिका इतनी जल्दी चुनें कि VPN नियम पहले न जीत सके।

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

डिज़ाइन B: होस्ट पर समाप्त करें

होस्ट की तरफ़ जानबूझकर कॉन्फ़िगर किया गया फ़्रंटएंड, जैसे TCP प्रॉक्सी या कंटेनर के सामने रिवर्स प्रॉक्सी, जवाब को होस्ट के पते से उत्पन्न रखता है। तब होस्ट के लिए लिखे नियम अपेक्षा के अनुसार व्यवहार करते हैं, और कंटेनर अपने निजी नेटवर्क पर रहता है।

लागत एक और चलता-फिरता हिस्सा है, जिसका अपना कॉन्फ़िगरेशन, स्रोत-पता प्रबंधन और एक्सेस नियंत्रण है। यह आम तौर पर ज़्यादा सरल समर्थित सीमा है, और अक्सर तब सही जवाब होता है जब रूटिंग नीति ऐसे एक व्यक्ति द्वारा बनाए रखी जानी हो जो कभी भी जा सकता है।

बदलाव सत्यापित करें, इरादा नहीं

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

एक नियम परखने के लिए मशीन की कनेक्शन तालिका फ़्लश न करें: मौजूदा प्रविष्टियाँ अपनी पुरानी मैपिंग रखती हैं, और फ़्लश होस्ट पर बाकी सब कुछ तोड़ देता है। पोर्ट प्रकाशित करना पहुँच-योग्यता तय करता है। यह जवाब का रास्ता तय नहीं करता। चुना गया डिज़ाइन उसकी तालिका-नामों के साथ लिख लें, ताकि किसी घटना के दौरान अगले व्यक्ति को उसे फिर से खोजना न पड़े।