Windows कंटेनर आणि VPN: स्थानिक नेटवर्किंग का तुटते
Windows कंटेनर होस्टच्या राउटिंग टेबलचा वापर करतो, म्हणून स्थानिक सबनेटला अडवणारे VPN कंटेनरचे प्रिफिक्सही सोबत घेऊन जाते. Linux मोड वेगळा मार्ग घेतो.
एका लॅपटॉपवर, एक VPN क्लायंट जोडलेला असताना, Linux कंटेनर एकमेकांशी बोलत राहतात आणि Windows कंटेनर थांबतात। बदलणारा घटक इमेज नाही; पॅकेट होस्टमध्ये ज्या मार्गाने जातात तो मार्ग आहे। डीफॉल्ट नेटवर्कवरील Windows कंटेनर होस्टचे राउटिंग टेबल आणि भाषांतर उधार घेतात, म्हणून होस्टचे राउटिंग बदलणारे धोरण त्यांनाही बदलते। काहीही पुन्हा इन्स्टॉल करण्यापूर्वी राउट लुकअपने ते सत्यापित करा।
Windows कंटेनरचे पॅकेट होस्टमध्ये कुठे प्रवेश करतात
डीफॉल्ट nat नेटवर्कवरील कंटेनरला Host Networking Service च्या प्रिफिक्समधून पत्ता मिळतो, सामान्यतः 172.16.0.0/12 च्या आत कुठेतरी, आणि तो व्हर्च्युअल अडॅप्टरमार्फत होस्टपर्यंत पोहोचतो। होस्ट त्या प्रिफिक्सचा राउट ठेवतो आणि सध्या सक्रिय असलेल्या अडॅप्टरकडे रहदारीचे भाषांतर करतो। त्या मार्गाच्या मध्यभागी वेगळी व्हर्च्युअल मशीन नाही।
हेच डिझाइन बिघाडाला यांत्रिक बनवते। कंटेनर पॅकेट पाठवतो तेव्हा होस्ट कंटेनर प्रिफिक्ससाठी राउट लुकअप करतो। कोणता राउट जिंकतो तिथे पॅकेट जाते, आणि कंटेनरला त्याबद्दल मत नाही।
VPN क्लायंट त्या मार्गावर काय बदलतो
कॉर्पोरेट क्लायंट बऱ्याचदा अनेक राउटचा संच आणि टनेल सुरू असताना स्थानिक सबनेटमधील प्रवेश नाकारणारा फिल्टर इन्स्टॉल करतो। हेतू संरक्षणात्मक आहे: तडजोड झालेल्या स्थानिक नेटवर्कने संरक्षित मशीनपर्यंत पोहोचू नये। दुष्परिणाम असा की होस्टचा राउट कंटेनर प्रिफिक्सपर्यंत आता स्थानिक NAT नेटवर्क नाही।
त्याऐवजी लुकअप टनेलशी जुळतो आणि पॅकेट त्या कंटेनर पत्त्याबद्दल कधीही न ऐकलेल्या गेटवेकडे दिले जाते। Ping अयशस्वी होते, अॅप्लिकेशनची वेळ संपते, आणि VPN चिन्ह चमकत असताना कंटेनर तुटलेला दिसतो। जोडलेले असताना होस्टचे टेबल पाहा आणि स्पर्धक राउट दिसते।
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often 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 प्रॉक्सीमागे चालतो, आणि स्वतःचा क्लायंट असलेली वेगळी व्हर्च्युअल मशीन स्वतःचे धोरण राखते। एक जाणीवपूर्वक निवडा आणि कंटेनरच्या आतून त्याची चाचणी करा, कारण वापरकर्त्याची विनंती तिथूनच उद्भवते।