LXD कंटेनर /dev/net/tun नहीं खोल पा रहा? unix-char प्रविष्टि जाँचें

LXD मेज़बान का कैरेक्टर डिवाइस कंटेनर को डिवाइस नोड जोड़कर देता है, अतिथि को उसे बनाना सिखाकर नहीं। अगर कंटेनर में /dev/net/tun नहीं है, तो डिवाइस मेज़बान पर हो सकता है और अतिथि फिर भी उसे नहीं खोल पाए। unix-char प्रविष्टि उस मार्ग का प्रबंधक-पक्षीय आधा हिस्सा है, और यह जानबूझकर विशेषाधिकार प्राप्त कंटेनर से संकरा है। इसलिए मेज़बान नोड और कंटेनर नोड अलग-अलग जाँच के योग्य हैं।

तंत्र इतना छोटा है कि नज़र में रखा जा सके: LXD मेज़बान का पथ हल करता है, इंस्टेंस के भीतर मेल खाता नोड बनाता है और डिवाइस को कंटेनर के डिवाइस cgroup में जोड़ता है। फिर अतिथि प्रक्रिया को नोड का किसी भी काम के लिए उपयोग करने हेतु अपनी अनुमति और क्षमता चाहिए।

unix-char प्रविष्टि वास्तव में क्या बदलती है

unix-char डिवाइस LXD से कहता है कि कंटेनर के भीतर चुने गए पथ पर मेज़बान का एक कैरेक्टर डिवाइस उपलब्ध कराए। प्रविष्टि के तीन महत्वपूर्ण भाग हैं: प्रबंधक द्वारा उपयोग किया जाने वाला डिवाइस लेबल, मेज़बान पर source पथ और वह path जो अतिथि देखता है। केवल अंतिम दो ही डिवाइस का वर्णन करते हैं। इनमें से किसी एक में टाइपिंग की गलती ऐसी जगह नोड बनाती है जिसे क्लाइंट कभी नहीं खोलता।

मेज़बान पर डिवाइस सामान्यतः /dev/net/tun होता है। कंटेनर के भीतर आप वही पथ रख सकते हैं या दूसरा चुन सकते हैं, पर पथ वही होना चाहिए जिसकी VPN क्लाइंट अपेक्षा करता है। /dev/net/tun रखना दूसरी कॉन्फ़िगरेशन समस्या से बचाता है, क्योंकि अधिकांश क्लाइंट वह पथ बिना पूछे खोलते हैं।

प्रबंधक प्रविष्टि तब लागू करता है जब इंस्टेंस शुरू होता है या डिवाइस हॉटप्लग होता है। यह अतिथि में कोई ड्राइवर नहीं कॉपी करता और टनल इंटरफ़ेस नहीं बनाता। यह नोड को दृश्यमान बनाता है और कंटेनर के डिवाइस नियंत्रण समूह के माध्यम से पहुँच की अनुमति देता है।

डिवाइस को इंस्टेंस पर घोषित करें, अतिथि के भीतर नहीं

LXD प्रशासन संदर्भ से प्रविष्टि जोड़ें, इंस्टेंस और ऐसा लेबल बताते हुए जिसे आप बाद में पहचान सकें। vpnbox नाम के कंटेनर के लिए आदेश है:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

लेबल tun इंस्टेंस कॉन्फ़िगरेशन तक ही स्थानीय है। यह इंटरफ़ेस का नाम नहीं है और इसे अतिथि में किसी चीज़ से मेल खाना ज़रूरी नहीं। अगर कोई प्रोफ़ाइल पहले से वही डिवाइस देती है, तो दूसरी प्रविष्टि जोड़ना अतिरेक नहीं बल्कि टकराव बनाता है, इसलिए पहले प्रभावी कॉन्फ़िगरेशन देखें।

कंटेनर के भीतर फ़ाइलें संपादित करना ग़लत परत है। स्टार्टअप स्क्रिप्ट में mknod विशेषाधिकार प्राप्त कंटेनर पर काम करता दिख सकता है, फिर पुनर्निर्माण पर ग़ायब हो सकता है या कम विशेषाधिकार वाले पर विफल हो सकता है। इंस्टेंस के डिवाइस समुच्चय का स्वामी प्रबंधक है; नोड का भी स्वामी उसे ही रहने दें।

स्वामित्व और मोड को अतिथि प्रक्रिया से मिलाएँ

unix-char प्रविष्टि कंटेनर के भीतर नोड के लिए uid, gid और mode सेट कर सकती है। इन्हें VPN क्लाइंट चलाने वाले खाते से मिलाने के लिए उपयोग करें, न कि डिवाइस को हर उपयोगकर्ता के लिए खोलने या कंटेनर को विशेषाधिकार मोड में बदलने के लिए।

दृश्यता अनुमति के समान नहीं है। root के स्वामित्व वाला और मोड 600 वाला नोड अविशेषाधिकार प्राप्त उपयोगकर्ता के रूप में चल रही सेवा को दिखता है और फिर भी वह उसे खोल नहीं सकती। पहले अतिथि खाता जाँचें, फिर स्वामित्व उस खाते को दें, और मोड को क्लाइंट की ज़रूरत से अधिक चौड़ा न रखें।

प्रक्रिया को टनल इंटरफ़ेस कॉन्फ़िगर करने की क्षमता भी चाहिए, सामान्यतः कंटेनर के नेटवर्क नामस्थान में CAP_NET_ADMIN। डिवाइस देना वह क्षमता नहीं देता, और क्षमता देना डिवाइस नहीं देता; ये स्वतंत्र आवश्यकताएँ हैं।

जानें प्रविष्टि क्या नहीं देती

दिखाई देने वाला नोड काम करता VPN नहीं है। क्लाइंट पैकेज अभी भी स्थापित करना होगा, प्रोफ़ाइल अभी भी वैध होनी चाहिए, और सेवा अभी भी शुरू होनी चाहिए। प्रमाणीकरण, मार्ग और DNS क्लाइंट का ही काम रहता है, और वहाँ की विफलता डिवाइस प्रविष्टि के ग़लत होने का प्रमाण नहीं है।

systemd एक और प्रतिबंध जोड़ सकता है। DeviceAllow वाली यूनिट या कठोर डिवाइस नीति कंटेनर प्रबंधक द्वारा दिए गए नोड तक पहुँच से इनकार कर सकती है। जब नोड मौजूद हो पर सेवा अनुमति त्रुटि बताए, तो यूनिट की डिवाइस नीति जाँचें, और कंटेनर चौड़ा करने के बजाय वही नीति बदलें।

हॉटप्लग वैकल्पिक और स्पष्ट है। required=false वाली प्रविष्टि को स्रोत पथ चाहिए और मेज़बान डिवाइस बदलने पर वह आ या जा सकती है। ऐसा जीवनचक्र आते-जाते हार्डवेयर के लिए उपयुक्त है; VPN को बूट पर जिस TUN डिवाइस की ज़रूरत होती है, उसके लिए वैकल्पिक प्रविष्टि सेवा को उसकी पूर्वशर्त मौजूद होने से पहले ही शुरू कर सकती है।

दृश्यता, खोलना और इंटरफ़ेस इसी क्रम में जाँचें

पहले इच्छित कंटेनर के भीतर नोड की पुष्टि करें। पथ, प्रमुख और लघु संख्या तथा स्वामित्व मेज़बान डिवाइस और आपकी जोड़ी प्रविष्टि से मेल खाना चाहिए। नोड न होने का अर्थ है कि प्रबंधक ने प्रविष्टि लागू नहीं की, या किसी दूसरे इंस्टेंस पर लागू की।

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

फिर पुष्टि करें कि सेवा खाता उसे खोल सकता है। उस खाते के रूप में छोटा परीक्षण स्वामित्व की समस्या को सेवा की समस्या से अलग करता है। अंत में क्लाइंट शुरू करें और पुष्टि करें कि टनल इंटरफ़ेस दिखता है; केवल वही तीसरा चरण पूरा मार्ग सिद्ध करता है, क्योंकि पहले दो पास हो सकते हैं जबकि क्लाइंट प्रोफ़ाइल या क्षमता अभी भी ग़लत हो।

बदलाव स्वीकृत होने पर इंस्टेंस, डिवाइस लेबल, मेज़बान स्रोत, अतिथि पथ और स्वामी खाता दर्ज करें। वही पाँच मान वे हैं जिन्हें बाद का पुनर्निर्माण, स्थानांतरण या प्रोफ़ाइल परिवर्तन सुरक्षित रखना चाहिए, और संदर्भ-रहित अनुमति त्रुटि की तुलना में इनकी तुलना कहीं आसान है।