Docker कन्टेनरको ट्राफिक होस्ट VPN लाई बाइपास गर्छ: कसरी जाँच्ने
होस्ट VPN ले होस्टको नेटवर्क नेमस्पेस मात्र समेट्छ। ब्रिजमा रहेको कन्टेनरको ट्राफिक सुरुङमा जान्छ कि सिधै बाहिर निस्कन्छ भन्ने यी जाँचहरूबाट पत्ता लगाउनुहोस्।
होस्टमा तपाईंको ब्राउजरले VPN को निकास ठेगाना देखाउँछ, कन्टेनरले तपाईंको घरको जडान रिपोर्ट गर्छ, र कसैले यसलाई चुहावट भन्छ। केही पनि चुहिएको छैन। होस्ट सुरुङ भनेको होस्टको नेटवर्क नेमस्पेससँग सम्बन्धित इन्टरफेस, मार्ग र नियमहरूको समूह हो, र ब्रिजमा रहेको कन्टेनर आफ्नै पूर्वनिर्धारित मार्ग भएको अर्को नेमस्पेस हो। VPN क्लाइन्ट हप्तौंसम्म जोडिएको तर एउटै कन्टेनर प्याकेट कहिल्यै नगएको Compose स्ट्याकमा म बसेको छु।
ट्रे आइकनभन्दा पहिले नेमस्पेस जाँच्नुहोस्
नेमस्पेसहरू नै सम्पूर्ण तर्क हुन्। जब Docker ले ब्रिज नेटवर्कमा कन्टेनर सुरु गर्छ, यसले नेटवर्क नेमस्पेस बनाउँछ, veth जोडीको एक छेउ त्यसभित्र जोड्छ, र त्यो नेमस्पेसलाई ठेगाना र पूर्वनिर्धारित मार्ग दिन्छ। सुरुङको इन्टरफेस, जे नाम दिइए पनि, होस्टको नेमस्पेसमा बस्छ। कन्टेनरभित्रको ट्राफिकले त्यसलाई देख्न सक्दैन, र बाहिरबाट कुनै पनि क्लाइन्ट सेटिङले त्यो बदल्दैन।
अलगावबाट बाहिर निस्कने दुई समर्थित उपाय छन्। --network host ले कन्टेनरलाई होस्टको नेमस्पेसभित्र राख्छ, त्यसैले यसले होस्टका मार्ग र त्यसै गरी सुरुङ पाउँछ। --network container:vpn अर्को कन्टेनरको नेमस्पेस साझा गर्छ, र अधिकांश साइडकार डिजाइनले कामको भार VPN कन्टेनरबाट यसै गरी पठाउँछन्। दुवै स्पष्ट विकल्प हुन्; सामान्यतया तीमध्ये एउटा मात्र तैनाथ गर्ने व्यक्तिको मनसाय हुन्छ।
होस्ट मोड नि:शुल्क अपग्रेड होइन। कन्टेनरले आफ्नै ठेगाना राख्न छोड्छ, पोर्ट प्रकाशन लागू हुन छोड्छ, र त्यहाँ NET_ADMIN राख्ने प्रक्रियाले होस्टको राउटिङ पुनःलेख्न सक्छ। त्यो स्वीकार गर्नु सही निर्णय हुन सक्छ। यो पहिले नै सक्रिय छ भनी मान्नु भनेको मार्गमा कहिल्यै नभएको सुरुङलाई साँझभर डिबग गर्नुमा बिताउनु हो।
प्याकेटलाई ब्रिजबाट बाहिर पछ्याउनुहोस्
ब्रिज कन्टेनरले आफ्नो प्याकेट आफ्नो पूर्वनिर्धारित गेटवेमा पठाउँछ, जो होस्टमा रहेको ब्रिज इन्टरफेस हो। त्यसपछि होस्टले प्याकेट अगाडि पठाउँछ र पूर्वनिर्धारित कन्फिगरेसनमा प्याकेट बाहिर निस्कनुअघि स्रोत ठेगानालाई आफ्नै ठेगानामा अनुवाद गर्छ। त्यही अनुवाद चरणले नीतिलाई चुपचाप पराजित गर्छ।
प्याकेट सुरुङको अन्त्य बिन्दुमा पुग्दा यो होस्टको ठेगाना बोकिरहेको हुन्छ। कन्टेनरको मूल ठेगानामा आधारित कुनै पनि नियम, नीति-मार्ग वा विभाजित सुरुङको निर्णय मिल्न छोड्छ, र फरक फरक निकासबाट बाहिर जानुपर्ने दुई कन्टेनरलाई केवल स्रोतले छुट्याउन सकिँदैन। यदि तपाईंलाई प्रति-कन्टेनर राउटिङ चाहिन्छ भने, निर्णय अनुवादअघि वा तपाईंले नियन्त्रण गर्ने नेमस्पेसभित्र लिनुपर्छ।
Docker यी नियमहरू आफै राख्छ, डेमन कुन फायरवाल ब्याकएन्डसँग कन्फिगर गरिएको थियो त्यसैमार्फत। अगाडि पठाइने ट्राफिकका लागि समर्थित हुकबाहिर हातले लेखिएका नियमहरू, DOCKER-USER, डेमन पुनःसुरु हुँदा वा होस्ट अपग्रेड हुँदा पुनःक्रमबद्ध वा हटाइन सक्छन्। प्याकेट फिल्टरिङबारे Docker को कागजात ले चेनको क्रम देखाउँछ; व्यावहारिक कुरा के हो भने हरेक नियमलाई एक मालिक र तपाईंले साँच्चै परीक्षण गरेको पुनःलोड मार्ग चाहिन्छ।
दुई प्रणालीलाई छुट्टाछुट्टै परीक्षण गर्नुहोस्
एउटा नेमस्पेसको प्रमाणले अर्कोबारे केही भन्दैन। VPN कन्टेनरभित्र चलाइएको अनुरोधले त्यो कन्टेनरका लागि सुरुङ काम गर्छ भनी प्रमाणित गर्छ। त्यो होस्टबारे प्रमाण होइन, र --network host कन्टेनरबाट चलाइएको त्यही आदेश ब्रिजबारे प्रमाण होइन।
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'त्यसपछि परीक्षण मिल्दो इमेजमा नभई साँचो अनुप्रयोग कन्टेनरभित्र दोहोर्याउनुहोस्। अनुप्रयोगमा थप मार्ग, प्रोक्सी वातावरण चर वा फरक रिजोल्भर हुन सक्छ, र तीमध्ये हरेकले उत्तर बदल्छ। हरेक पटक नाम-समाधान र दोस्रो ठेगाना परिवार जाँच्नुहोस्: प्रयोगकर्ता-परिभाषित ब्रिजका कन्टेनरहरू Docker को अन्तर्निहित रिजोल्भरमार्फत 127.0.0.11 मा समाधान हुन्छन्, र ब्रिजमा रहेको IPv6 पूर्वनिर्धारित मार्गले तपाईं IPv4 मात्र सुरुङ परीक्षण गर्दै गर्दा ट्राफिक बाहिर लैजान सक्छ।
प्रमाणहरू छुनुअघि ढाँचा पढ्नुहोस्
होस्ट चल्छ र कन्टेनर चल्दैन भने, कारण लगभग सधैं संरचनात्मक हुन्छ, र कुञ्जी घुमाउनु वा क्लाइन्ट पुनःस्थापना गर्नु दिउँसो बर्बाद गर्नु हो। पहिले लक्षण क्रममा राख्नुहोस् र सुधारले सामान्यतया आफ्नै नाम भन्छ।
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
ओभरल्याप लाइनले आफ्नै वाक्य पाउनुपर्छ। 172.17.0.0/16 का लागि, वा तपाईंको ब्रिज प्रिफिक्स संयोगवश समेट्ने 10.0.0.0/8 का लागि मार्ग धकेल्ने VPN प्रोफाइलले सुरुङलाई कन्टेनर सबनेट दाबी गराउँछ, र अनुवादित ठेगानातिर जाने उत्तरहरू गलत दिशामा जान्छन् वा हराउँछन्। Docker नेटवर्क पुनःक्रमांकन गर्नु सामान्यतया अपवाद जम्मा गर्नुभन्दा सफा हुन्छ।
कभरेज स्पष्ट बनाउनुहोस्, त्यसपछि जानाजान तोड्नुहोस्
दुई डिजाइन समीक्षामा टिक्छन्। VPN कन्टेनरको नेमस्पेस साझा गर्नुहोस् र समेटिएको हरेक कामको भार एउटै पुनःसुरु सीमा भएको एउटै सुरुङ प्रयोग गर्छ, जो एक सेवालाई फरक निकास वा आफ्नै DNS मार्ग नचाहिएसम्म सरल छ। वा कन्टेनर नेटवर्कलाई होस्टमा रहेको VPN गेटवेतिर राउट गर्नुहोस्: फर्वार्डिङ सक्रिय, ब्रिज प्रिफिक्स सुरुङतिर, फर्किने ट्राफिक स्पष्ट रूपमा व्यवस्थापित। यसले प्रति-नेटवर्क नियन्त्रण किन्छ र डेमन तथा क्लाइन्ट अपग्रेडभरि कायम राख्नुपर्ने नियमसमूह तपाईंलाई खर्च गराउँछ।
जे भए पनि, महत्त्वपूर्ण परीक्षण असफलताको अवस्था हो। कन्टेनरको अनुरोध हावामा हुँदा सुरुङ रोक्नुहोस् र प्याकेट कहाँ जान्छ हेर्नुहोस्। यदि त्यो सिधा मार्गमा फर्कियो भने, कभरेज कहिल्यै लागू भएको थिएन, किनभने क्लाइन्टको kill switch ले क्लाइन्टको आफ्नै ट्राफिक नियन्त्रण गर्छ, ब्रिजबाट अगाडि पठाइएका प्याकेट होइनन्। त्यसपछि डेमन र होस्ट पुनःसुरु गर्नुहोस् र नतिजा दोस्रो पटक पुष्टि गर्नुहोस्; हातले लेखिएका नियम हराउने क्षण त्यही हो।
यसलाई सम्पन्न भन्नुअघि चार कुरा पुष्टि गर्नुहोस्: सुरुङको इन्टरफेस ट्राफिकजस्तै नेमस्पेसमा छ, कन्टेनर परीक्षण साँचो कन्टेनरभित्र भयो, नाम-समाधान र दुवै ठेगाना परिवार जाँचिए, र सुरुङ-असफलता परीक्षण अझै बन्द रूपमा असफल हुन्छ। त्यसपछि फायरवाल ब्याकएन्ड, क्लाइन्ट संस्करण र हरेक नियमको मालिक लेख्नुहोस्। त्यही अभिलेखले अर्को अपग्रेडलाई पुराना मान्यताको अभिलेख नभएको मिश्रण छोड्नबाट रोक्छ।