एक ही लैपटॉप पर, एक VPN क्लाइंट जुड़ा होने पर, Linux कंटेनर आपस में बात करते रहते हैं और Windows कंटेनर रुक जाते हैं। बदलने वाली चीज़ इमेज नहीं है; पैकेट होस्ट तक जो रास्ता लेते हैं वह है। डिफ़ॉल्ट नेटवर्क पर Windows कंटेनर होस्ट की रूट तालिका और अनुवाद उधार लेते हैं, इसलिए होस्ट की रूटिंग बदलने वाली नीति उन्हें भी बदल देती है। कुछ भी फिर से इंस्टॉल करने से पहले रूट लुकअप से इसे सत्यापित करें।

Windows कंटेनर के पैकेट होस्ट में कहाँ प्रवेश करते हैं

डिफ़ॉल्ट nat नेटवर्क पर एक कंटेनर Host Networking Service के प्रीफ़िक्स से एक पता पाता है, आमतौर पर 172.16.0.0/12 के भीतर कहीं, और वर्चुअल एडाप्टर के ज़रिए होस्ट तक पहुँचता है। होस्ट उस प्रीफ़िक्स का रूट रखता है और ट्रैफ़िक को उस एडाप्टर की ओर अनुवादित करता है जो इस समय सक्रिय है। उस रास्ते के बीच में कोई अलग वर्चुअल मशीन नहीं है।

यही डिज़ाइन विफलता को यांत्रिक बनाता है। जब कंटेनर पैकेट भेजता है, तो होस्ट कंटेनर प्रीफ़िक्स के लिए रूट लुकअप करता है। जो भी रूट जीतता है, पैकेट वहीं जाता है, और कंटेनर की इसमें कोई राय नहीं होती।

VPN क्लाइंट उस रास्ते पर क्या बदलता है

कॉर्पोरेट क्लाइंट अक्सर ढेर सारे रूट और एक फ़िल्टर इंस्टॉल करता है जो टनल चालू रहने पर स्थानीय सबनेट तक पहुँच अस्वीकार करता है। मंशा रक्षात्मक है: किसी समझौते से ग्रस्त स्थानीय नेटवर्क को संरक्षित मशीन तक नहीं पहुँचना चाहिए। दुष्प्रभाव यह है कि होस्ट का रूट कंटेनर प्रीफ़िक्स तक अब स्थानीय NAT नेटवर्क नहीं है।

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

Container modeOutbound pathTypical result behind the VPN
Windows, default natHost routes and translates container trafficContainer prefix follows the tunnel and fails
Windows, transparentContainer sits on the physical linkDepends on the local subnet being allowed
Linux engine on Docker DesktopVM egress proxied by a host processOften keeps working

Linux कंटेनर अलग व्यवहार क्यों करते हैं

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

यही अंतर यह भी बताता है कि Linux की रेसिपियाँ क्यों नहीं चलतीं। जिस Linux कंटेनर को अपनी टनल चाहिए, उसे TUN डिवाइस और NET_ADMIN क्षमता दी जाती है। Windows कंटेनर कोई इंटरफ़ेस डिवाइस के रूप में उजागर नहीं करते, इसलिए उस पैटर्न का उस तरफ़ कोई समकक्ष नहीं है।

रूट सिद्ध करें, फिर डिज़ाइन चुनें

साक्ष्य होस्ट से इकट्ठा करें, कंटेनर से नहीं, क्योंकि लुकअप होस्ट ही करता है:

docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"

VPN जुड़ने से पहले एक बार और जुड़ने के बाद एक बार रूट आउटपुट चलाएँ। अगर दूसरे आउटपुट में कंटेनर प्रीफ़िक्स टनल एडाप्टर की ओर इशारा करता है, तो निदान पूरा है और कंटेनर फिर से शुरू करने से मदद नहीं मिलेगी।

पहला विकल्प नीति का निर्णय है: नेटवर्क के मालिक से पूछें कि इस डिवाइस के लिए स्थानीय LAN पहुँच की अनुमति दी जा सकती है या नहीं। कई कॉर्पोरेट क्लाइंट इसे एक सेटिंग के रूप में देते हैं, लेकिन यह जानबूझकर बनाई गई सीमा को कमज़ोर करता है। इसके लिए मालिक और समीक्षा तिथि के साथ एक दस्तावेज़ीकृत अपवाद माँगें। हर डिवाइस के लिए ऐसा टॉगल जिस पर कोई वापस नहीं आता, रक्षात्मक नीति के चुपचाप गायब होने का तरीका है।

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

संबंधित लेख