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 नीति जो क्रिया को सीमित करती है। यह तीसरी सीमा है, जिसे एप्लिकेशन नहीं बल्कि रनटाइम प्रलेखित करता है।

कंटेनर फ़्लैग, इमेज और हर प्रयास की सटीक त्रुटि लिख लें। वह नोट पढ़ने वाला अगला व्यक्ति पूरी जाँच दोहराए बिना बता सकेगा कि कौन-सा दरवाज़ा बंद था।