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'

त्यसपछि सेवा खाताले त्यो खोल्न सक्छ भनी पुष्टि गर्नुहोस्। त्यो खाताका रूपमा गरिएको छोटो परीक्षणले स्वामित्वको समस्यालाई सेवाको समस्याबाट अलग गर्छ। अन्तमा क्लाइन्ट सुरु गर्नुहोस् र टनेल इन्टरफेस देखा पर्छ भनी पुष्टि गर्नुहोस्; पहिला दुई पास हुन सक्छन् तर क्लाइन्ट प्रोफाइल वा क्षमता अझै गलत हुन सक्छ, त्यसैले पूरै मार्ग तेस्रो चरणले मात्र प्रमाणित गर्छ।

परिवर्तन स्वीकृत हुँदा इन्स्टेन्स, उपकरण लेबल, होस्ट स्रोत, अतिथि मार्ग र मालिक खाता अभिलेख गर्नुहोस्। ती पाँच मान पछिको पुनर्निर्माण, स्थानान्तरण वा प्रोफाइल परिवर्तनले जोगाउनुपर्ने हुन्, र सन्दर्भविहीन अनुमति त्रुटिभन्दा तिनको तुलना गर्न धेरै सजिलो छ।