Docker मधील OpenVPN /dev/net/tun उघडू शकत नाही: काय गहाळ आहे

कंटेनर इमेजेस आवश्यक असलेल्या प्रत्येक OpenVPN बाइनरी आणि कॉन्फिगरेशन फाइल घेऊन जाऊ शकतात आणि तरीही पहिल्या नेटवर्क कॉलवर अपयशी ठरू शकतात. त्रुटी /dev/net/tun चे नाव घेते कारण अनुप्रयोगाने कर्नेलला TUN इंटरफेस मागितला होता आणि कंटेनरकडे डिव्हाइस नोड किंवा तो तयार करण्याची क्षमता यापैकी काहीही नव्हते. या दोन वेगळ्या परवानग्या आहेत, आणि एक दुरुस्त केल्यास दुसरी अगदी जिथे होती तिथेच राहते.

त्या वेगळ्या करण्यासाठी प्रत्येकासाठी एक आदेश लागतो. त्यानंतरचा त्रुटी संदेश तुम्ही प्रत्यक्षात कोणत्या सीमेवर उभे होता हे सांगतो.

डिव्हाइस नोड आणि क्षमता दोन दरवाजे आहेत

डिव्हाइस नोड फाइलसिस्टमची वस्तू आहे, म्हणून कंटेनरला तो त्याच्या स्वतःच्या माउंट नेमस्पेसमध्ये दिसणे आवश्यक आहे. क्षमता ही परवानगी आहे, म्हणून प्रक्रियेला ज्या नेमस्पेसमध्ये इंटरफेस तयार होईल तिथे CAP_NET_ADMIN आवश्यक आहे. क्षमतेशिवाय डिव्हाइस पास केल्यास तुम्हाला उघडणारा नोड आणि अपयशी ठरणारा ioctl मिळतो. डिव्हाइसशिवाय क्षमता दिल्यास अनुप्रयोग काहीही उघडू शकत नाही, म्हणून उदाहरणांमध्ये दोन्ही सहसा एकत्र दिसतात.

Docker चे devices सेटिंग होस्ट डिव्हाइस कंटेनरमध्ये मॅप करते, तर cap_add क्षमता संच समायोजित करते. त्याच मार्गाचे bind mount डिव्हाइस प्रवेशाची अर्थशास्त्र लागू न करता फाइल दृष्टीत आणते.

हे Compose फाइलबाहेर पुनरुत्पादित करा

सेवा संपादित करण्यापूर्वी होस्टकडे डिव्हाइस आहे आणि रिकामा कंटेनर इंटरफेस तयार करू शकतो याची खात्री करा. खालील आदेश जाणूनबुजून किमान आहे, आणि त्याचा एकमेव उद्देश होस्ट समस्या compose समस्येपासून वेगळी करणे आहे. तो अपयशी ठरल्यास कोणताही compose बदल मदत करणार नाही.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

होस्टवर नोड नसणे म्हणजे tun मॉड्यूल उपलब्ध नाही, ही कंटेनरची नव्हे तर होस्ट बाजूची दुरुस्ती आहे. नोड असूनही कंटेनरमध्ये उघडू न शकणे डिव्हाइस प्रवेशाकडे निर्देश करते, आणि संदेश no such file नव्हे तर permission denied म्हणेल. या दोन अपयशांचा क्रम हाच संपूर्ण निदान आहे. कोणताही फ्लॅग बदलण्यापूर्वी तुम्ही कोणते पाहिले ते लिहून ठेवा.

TUN नंतरच्या त्रुटी वेगळ्या समस्या आहेत

इंटरफेस दिसताच पुढील अपयशाला वेगळा मालक असतो. प्रमाणीकरण त्रुटींचा अर्थ टनेल सर्व्हरपर्यंत पोहोचली आणि क्रेडेन्शियल्स नाकारली गेली, म्हणून क्षमता बदल मदत करणार नाहीत. अनुप्रयोग अजूनही अपयशी होत असताना टनेल स्थापित झाल्यास ते मार्ग, फॉरवर्डिंग, कंटेनरमधील DNS रिझोल्यूशन किंवा कंटेनरच्या स्वतःच्या नेटवर्क मांडणीकडे निर्देश करते. त्यातील प्रत्येक सामान्य नेटवर्किंग प्रश्न आहे ज्याचे उत्तर TUN परवानगी देऊ शकत नाही. प्रत्येक बदलानंतर मूळ चाचणी पुन्हा केल्यास अपयशे एका ठसामध्ये विलीन होण्यास प्रतिबंध होतो.

कार्यरत उदाहरणातून प्रत्येक सेटिंग कॉपी करणे हाच किमान दुरुस्तीला वाचन करण्यायोग्य नसलेल्या सेवा व्याख्येत बदलण्याचा मार्ग आहे. या तैनातीला आवश्यक असलेल्या गोष्टीच आणा आणि प्रत्येक का आहे ते लिहा.

कंटेनरमध्ये इंटरफेस सत्यापित करा

इंटरफेस आणि क्षमता संच तपासा होस्टवरून नव्हे तर चालू असलेल्या कंटेनरमधून. खालील आदेश डिव्हाइस नोड, क्षमतांची यादी आणि इंटरफेस अजिबात तयार होऊ शकतो का हे दाखवतात. ते क्लायंट चालवणाऱ्या त्याच कंटेनरमध्ये चालवा, आणि इमेज किमान असल्यास साधने स्थापित करा.

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

bounding set मध्ये असलेली पण effective set मध्ये नसलेली क्षमता कधीही न दिलेल्या क्षमतेपेक्षा वेगळी वागते, आणि capsh दोन्ही दाखवते. नोड असून आणि क्षमता असूनही तयारी अपयशी ठरत राहिल्यास रनटाइम seccomp प्रोफाइल किंवा AppArmor धोरणासारखे ऑपरेशन मर्यादित करणारे दुसरे काही लागू करत आहे. ही तिसरी सीमा आहे, जी अनुप्रयोग नव्हे तर रनटाइम दस्तऐवजीकरण करते.

कंटेनर फ्लॅग, इमेज आणि प्रत्येक प्रयत्नाची नेमकी त्रुटी लिहून ठेवा. ती नोंद वाचणारा पुढील व्यक्ती संपूर्ण तपास पुन्हा न करता कोणता दरवाजा बंद होता ते सांगू शकेल.