Docker कन्टेनर VPN पछाडिका होस्टसम्म किन पुग्दैन

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

टनेल कसको नेमस्पेसको हो पत्ता लगाउनुहोस्

macOS वा Windows का लागि Docker Desktop मा कन्टेनरहरू Linux भर्चुअल मेसिनभित्र चल्छन्। डेस्कटपमा स्थापना गरिएको VPN क्लाइन्टले डेस्कटप अपरेटिङ सिस्टममा टनेल बनाउँछ, र भर्चुअल मेसिनले त्यो कहिल्यै देख्दैन। कुनै पनि कन्टेनर कन्फिगरेसनले यसलाई सुधार्दैन, किनकि कन्टेनरलाई आवश्यक पर्ने इन्टरफेस उसको नेटवर्क नेमस्पेसमा नै छैन।

Linux होस्टमा टनेल होस्टको नेमस्पेसमा बस्छ, र ब्रिज कन्टेनरहरू सामान्यतया बाहिर जाँदा स्रोत NAT लागू गरिएको होस्टको राउटिङ तालिकाबाट त्यसमा पुग्छन्। त्यो बाटो असफल हुँदा कारण सामान्यतया हराएको रुट नभई फर्वार्डिङ नीति, रिभर्स-पाथ फिल्टरिङ वा ओभरल्यापिङ सबनेट हुन्छ। अगाडि पढ्नुअघि तपाईं दुई संसारमध्ये कुनमा हुनुहुन्छ पुष्टि गर्नुहोस्:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

होस्ट नेटवर्किङ परीक्षण हो, डिजाइन होइन

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

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

यसलाई निदानका रूपमा राख्नुहोस्। होस्ट नेटवर्किङले पोर्ट प्रकाशन र कन्टेनरबाट तपाईंले चाहेको अधिकांश अलगाव छोड्छ, र Docker Desktop मा «host» भन्नाले भर्चुअल मेसिन हो, डेस्कटप होइन, त्यसैले कुन होस्टलाई सम्बोधन गर्दै हुनुहुन्थ्यो भुल्नुभयो भने त्यहाँको सफलता वा असफलताले तपाईंलाई भ्रमित गर्न सक्छ।

tun यन्त्र र त्यससँग आउने विशेषाधिकार

कन्टेनरभित्रको VPN क्लाइन्टलाई टनेल यन्त्र र त्यसलाई कन्फिगर गर्ने अनुमति चाहिन्छ। सामान्य सर्टकट --privileged हो, जसले हरेक यन्त्र दिन्छ र सम्पूर्ण कन्टेनरमा सुरक्षा नीति खुकुलो बनाउँछ। यो यस कामको आवश्यकताभन्दा धेरै बढी हो, र समीक्षामा यसको औचित्य पुष्टि गर्न गाह्रो छ।

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

यो डिजाइनको अर्थ क्लाइन्ट हरेक कन्टेनरका लागि चल्छ भन्ने पनि हो। हरेक कार्यभारलाई आफ्नै टनेल चाहिएको अवस्थामा यो सही उत्तर हो, र तपाईंले केवल होस्टको टनेल देखिने चाहनुभएको अवस्थामा गलत उत्तर — प्लेटफर्म टिमले तपाईं त्यसै गर्दै हुनुहुन्छ भनी मानेको हुनुपर्छ।

ब्रिज NAT ले VPN ले देख्ने स्रोत बदल्छ

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

macvlan वा ipvlan ले यसको सट्टा कन्टेनरलाई LAN ठेगाना दिन्छ, जसले LAN खोजीमा मद्दत गर्छ र कन्टेनरलाई खण्डमा समकक्ष जस्तो देखाउँछ। यसले होस्टको टनेल पूर्ण रूपमा बाइपास गर्छ, त्यसैले त्यस्तो कन्टेनर केवल-VPN प्रिफिक्ससम्म पुग्दैन, जबसम्म VPN त्यो LAN बाट पनि पहुँचयोग्य छैन।

दुवै रूप वैध छन्; तिनीहरू फरक आवश्यकताको जवाफ दिन्छन्। आवश्यकता «यो कन्टेनर केवल-VPN सेवासम्म पुग्नुपर्छ» भएमा तपाईं होस्टमार्फत राउटिङ र कन्टेनरभित्र टनेल अन्त्य गर्नेबीच छनोट गर्नुहुन्छ। त्यो छनोट तैनाथीअघि लेख्नुहोस्, पहिलो असफल अनुरोधपछि होइन। जे छाने पनि, टाढाको छेउले देख्ने स्रोत ठेगाना अभिलेख गर्नुहोस्, किनकि त्यसका पहुँच नियम र लगहरूले त्यही देखाउनेछन्। त्यो ठेगाना भन्न नसक्ने डिजाइन अपूर्ण छ।

DNS डिमनलाई पछ्याउँछ, टनेललाई होइन

कन्टेनरले सुरु हुँदा आफ्नो रिजोल्भर कन्फिगरेसन पाउँछ, जो डिमन वा इमेजबाट प्रतिलिपि गरिएको हुन्छ। VPN जोडिएपछि धकेल्ने ठेगानाहरू त्यो प्रतिलिपिका लागि धेरै ढिलो आउँछन्, र ती कन्टेनरभित्र नभई होस्ट रिजोल्भरमा धकेलिन्छन्।

सेवाका लागि रिजोल्भर स्पष्ट रूपमा सेट गर्नुहोस्, वा टनेलमार्फत पहुँचयोग्य आन्तरिक रिजोल्भरतर्फ संकेत गर्नुहोस्। निजी नामलाई सार्वजनिक ठेगानामा समाधान गर्ने कन्टेनर सामान्यतया सार्वजनिक रिजोल्भर प्रयोग गर्छ, बिग्रिएको रुटबाट पीडित हुँदैन, र सुधार compose फाइल वा डिमन कन्फिगरेसनमा पर्छ।

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

टिकट बन्द गर्नुअघिको जाँचसूची: टनेलको स्वामित्व भएको नेमस्पेस पहिचान गर्नुहोस्, होस्ट नेटवर्किङले बाटो प्रमाणित गर्नुहोस्, आवश्यक tun यन्त्र मात्र नक्सांकन गर्नुहोस्, NAT पछिको स्रोत ठेगाना सम्झनुहोस्, रिजोल्भर स्पष्ट सेट गर्नुहोस् र प्रति-कन्टेनर बाहिर जाने ठेगानालाई झन्डा नभई वास्तुकला निर्णय मान्नुहोस्।