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 क्लायंटच्या स्वतःच्या रहदारीवर नियंत्रण ठेवतो, ब्रिजवरून पुढे पाठवलेल्या पॅकेटवर नाही. नंतर डेमन आणि होस्ट पुन्हा सुरू करा आणि निकाल दुसऱ्यांदा निश्चित करा; हाताने लिहिलेले नियम गायब होण्याचा तोच क्षण आहे.
ते पूर्ण म्हणण्यापूर्वी चार गोष्टी निश्चित करा: सुरंगाचा इंटरफेस रहदारीप्रमाणेच त्याच नेमस्पेसमध्ये आहे, कंटेनर तपासणी खऱ्या कंटेनरमध्ये झाली, नाव-निराकरण आणि दोन्ही पत्ता कुटुंबे तपासली गेली, आणि सुरंग-अपयश तपासणी अजूनही बंद स्वरूपात अपयशी ठरते. नंतर फायरवॉल बॅकएंड, क्लायंट आवृत्ती आणि प्रत्येक नियमाचा मालक लिहा. तीच नोंद पुढील अपग्रेडला जुन्या गृहीतकांचे अप्रलेखित मिश्रण सोडू देत नाही.