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 प्रोक्सीपछाडि चल्छ, र आफ्नै क्लाइन्ट भएको छुट्टै भर्चुअल मेसिन ले आफ्नै नीति कायम राख्छ। एउटा जानाजान छान्नुहोस् र कन्टेनरभित्रबाट परीक्षण गर्नुहोस्, किनकि प्रयोगकर्ताको अनुरोध त्यहीँ उत्पन्न हुन्छ।