Docker कंटेनर का ट्रैफ़िक होस्ट VPN को बायपास करता है: जाँच कैसे करें
होस्ट VPN केवल होस्ट नेमस्पेस को कवर करता है। इन जाँचों से पता करें कि ब्रिज कंटेनर का ट्रैफ़िक सुरंग में जाता है या सीधे बाहर निकलता है।
होस्ट पर आपका ब्राउज़र VPN का एग्ज़िट पता दिखाता है, कंटेनर आपके घर के कनेक्शन की सूचना देता है, और कोई इसे लीक कहता है। कुछ भी लीक नहीं हुआ। होस्ट सुरंग इंटरफ़ेस, रूट और नियमों का समूह है जो होस्ट नेटवर्क नेमस्पेस के हैं, और ब्रिज पर एक कंटेनर अपने डिफ़ॉल्ट रूट वाला दूसरा नेमस्पेस है। मैं एक Compose स्टैक पर बैठा हूँ जहाँ VPN क्लाइंट हफ़्तों से जुड़ा था और एक भी कंटेनर पैकेट कभी उसमें नहीं गया।
ट्रे आइकन से पहले नेमस्पेस जाँचें
नेमस्पेस ही पूरी दलील है। जब 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 |
ओवरलैप पंक्ति अपना एक वाक्य हक़दार है। जो VPN प्रोफ़ाइल 172.17.0.0/16 के लिए, या ऐसे 10.0.0.0/8 के लिए रूट धकेलती है जिसमें संयोग से आपका ब्रिज प्रीफ़िक्स आ जाता है, वह सुरंग से कंटेनर सबनेट का दावा करा देती है, और अनुवादित पतों को जाने वाले उत्तर ग़लत दिशा में चले जाएँगे या गायब हो जाएँगे। Docker नेटवर्क को फिर से क्रमांकित करना आम तौर पर अपवाद जमा करने से साफ़तर है।
कवरेज को स्पष्ट करें, फिर उसे जानबूझकर तोड़ें
दो डिज़ाइन समीक्षा में टिकते हैं। VPN कंटेनर का नेमस्पेस साझा करें और हर कवर किया गया वर्कलोड एक ही रीस्टार्ट सीमा वाली एक सुरंग इस्तेमाल करता है, जो तब तक सरल है जब तक किसी एक सेवा को अलग एग्ज़िट या अपना DNS पथ न चाहिए। या कंटेनर नेटवर्क को होस्ट पर VPN गेटवे की ओर रूट करें: फ़ॉरवर्डिंग चालू, ब्रिज प्रीफ़िक्स सुरंग की ओर, वापसी ट्रैफ़िक स्पष्ट रूप से संभाला गया। यह प्रति-नेटवर्क नियंत्रण खरीदता है और डेमॉन व क्लाइंट अपग्रेड के दौरान बनाए रखने के लिए नियमों का एक सेट आपको महँगा पड़ता है।
जैसा भी हो, जो परीक्षण मायने रखता है वह विफलता का मामला है। कंटेनर का अनुरोध हवा में होते हुए सुरंग रोकें और देखें पैकेट कहाँ जाता है। अगर वह सीधे रास्ते पर लौट आता है, तो कवरेज कभी लागू ही नहीं हुआ था, क्योंकि क्लाइंट का kill switch क्लाइंट के अपने ट्रैफ़िक को नियंत्रित करता है, ब्रिज से आगे भेजे गए पैकेट को नहीं। इसके बाद डेमॉन और होस्ट फिर से शुरू करें और नतीजा दूसरी बार पुष्टि करें; वही वह पल है जब हाथ से लिखे नियम गायब हो जाते हैं।
इसे पूरा कहने से पहले चार बातें पुष्टि करें: सुरंग का इंटरफ़ेस ट्रैफ़िक जैसे ही नेमस्पेस में है, कंटेनर परीक्षण असली कंटेनर के अंदर चला, नाम-रिज़ॉल्यूशन और दोनों पता परिवार जाँचे गए, और सुरंग-विफलता परीक्षण अब भी बंद रूप में विफल होता है। फिर फ़ायरवॉल बैकएंड, क्लाइंट संस्करण और हर नियम का मालिक लिख लें। वही रिकॉर्ड अगले अपग्रेड को पुरानी धारणाओं का अप्रलेखित मिश्रण छोड़ने से रोकता है।