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 नीतिजस्तो अपरेशन सीमित गर्ने अरू केही लागू गरिरहेको हुन्छ। यो तेस्रो सीमा हो, जुन अनुप्रयोगले होइन रनटाइमले कागजात गर्छ।

कन्टेनर फ्ल्याग, इमेज र हरेक प्रयासको ठ्याक्कै त्रुटि लेख्नुहोस्। त्यो नोट पढ्ने अर्को व्यक्तिले पूरै अन्वेषण दोहोर्याउनु बिना कुन ढोका बन्द थियो भन्न सक्नेछ।