/dev/net/tun हराएको छ तर tun लोड छ: यन्त्र नोड मर्मत गर्नुहोस्

OpenVPN errno 2 उजुरीसहित रोकिन्छ, त्यो /dev/net/tun बारे हो, जबकि lsmod tun मोड्युल सहजै सूचीबद्ध गर्छ। दुवै तथ्य एकै समयमा सत्य हुन्। मोड्युलले ड्राइभर दिन्छ, र क्लाइन्टले खोल्ने बाटो यन्त्र नोड हो जुन अरू कुनैले बनाउनुपर्छ। दुवैलाई एउटै वस्तु मान्नु नै मोड्युल पुनः लोड गर्ने स्पष्ट उपायले केही नबदल्नुको कारण हो।

दुई वस्तु, दुई फरक मालिक

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

त्यसैले त्रुटि पाठ र मोड्युल सूची एकअर्कासँग विरोधाभासी छैनन्। क्लाइन्टले बाटो खोल्छ, बाटो छैन, र tun ड्राइभरलाई सोध्नुअघि नै कर्नेलले ENOENT फर्काउँछ। मोड्युल पुनः लोड गर्दा हराएको बाटो मर्मत हुँदैन, र बाटो बनाउँदा हराएको ड्राइभर मर्मत हुँदैन।

lsmod | grep -w tun
stat -c "%F %t:%T" /dev/net/tun
grep " /dev " /proc/mounts

devtmpfs र स्पष्ट mknod

सामान्यतया दुई संयन्त्रले त्यो नोड बनाउँछन्, र कुन जिम्मेवार हुनुपर्छ भन्ने थाहा भएमा के मर्मत गर्ने थाहा हुन्छ। devtmpfs ले कर्नेललाई माउन्ट गरिएको इन्स्टेन्समा यन्त्र नोड बनाउन दिन्छ, र udev ले तिनमा स्वामित्व र अनुमति लागू गर्छ। एउटा स्पष्ट mknod बुटमा दुवै नचल्ने इमेज र नेमस्पेसका लागि हातले गर्ने बाटो हो।

नियत होइन, नतिजा तुलना गर्नुहोस्। यदि devtmpfs /dev मा माउन्ट छ तर नोड अझै छैन भने, ड्राइभर तपाईंले अनुमान गरेको होइन, वा कसैले बुटपछि नोड हटाएको छ। यदि /dev खोलिएको rootfs भित्रको साधारण डाइरेक्टरी हो भने, कुनै स्वचालित संयन्त्र छैन र इमेज बनाउनेले नोड बनाउनुपर्छ।

stat -c "%F major=%t minor=%T" /dev/net/tun
# expect: character special file major=a minor=c8

दुवै संयन्त्र नचल्ने ठाउँमा नोड हातले बनाउनुपर्छ, र क्रम महत्त्वपूर्ण छ। पहिले अभिभावक डाइरेक्टरी बनाउनुहोस्, किनकि mknod ले त्यो बनाउन सक्दैन, त्यसपछि अक्षर यन्त्र, त्यसपछि root लाई मात्र लेख्न सकिने मोड। नोड बनाउनुअघि मोड्युल पुनः लोड गर्नुहोस्, र विद्यमान बाटो ls ले त्यो यन्त्र होइन, डाइरेक्टरी हो भनी देखाएपछि मात्र हटाउनुहोस्।

sudo modprobe tun
sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 600 /dev/net/tun
ls -l /dev/net/tun

सबैभन्दा छिटो भेदक stat ले रिपोर्ट गर्ने प्रकार हो, र त्यो बाटोमा डाइरेक्टरी हुनु न्यूनतम इमेजमा सबैभन्दा सामान्य आश्चर्य हो। राम्रो नियतले लेखिएको mkdir Dockerfile मा ठ्याक्कै त्यही छोड्छ, र जतिसुकै मोड्युल लोड गरे पनि डाइरेक्टरीलाई अक्षर यन्त्रले प्रतिस्थापन गर्न सकिँदैन। Major 10 र minor 200 tun का लागि दर्ता भएको जोडी हो, हेक्समा a र c8 का रूपमा व्यक्त गरिन्छ।

चार चिन्ह, चार कारण

चार कारणले लगभग हरेक घटना व्याख्या गर्छन्, र प्रत्येकले लगमा फरक चिन्ह छोड्छ। बुट वातावरणबाट सुरु गर्नुहोस्। डिस्कविहीन इमेज, इम्बेडेड बोर्ड र initramfs चरणहरूले प्रायः devtmpfs वा udev-व्यवस्थित /devमाउन्ट गर्दैनन्, त्यसैले कुनै प्रक्रियाले कहिल्यै नोड लेख्दैन। त्यसपछि /devहोस्ट गर्नेको माउन्ट विकल्प पढ्नुहोस्, किनकि nodev ले बाटो रहन दिन्छ तर खोल्न अस्वीकार गर्छ, र कठोर बनाइएको होस्टबाट लिइएको bind माउन्टले आफ्नो घोषणा नगरी यो झन्डा बोक्छ। पढ्न-मात्र माउन्ट अझ अगाडि र ठूलो स्वरमा असफल हुन्छ: mknod त्यहाँ EROFS फर्काउँछ, जबकि EPERM भन्नाले प्रक्रियामा क्षमता छैन, फाइलप्रणाली आफैँलाई बचाइरहेको छ भन्ने होइन। अन्तमा, आफ्नै /dev tmpfs भएको कन्टेनर रनटाइमले नोड आफ्नै नेमस्पेसमा इन्जेक्ट गर्नुपर्छ, र त्यसको यन्त्र cgroup ले major र minor जोडीलाई अनुमति दिनुपर्छ।

अनुमति फेरि बदल्नुअघि नीति तह जाँच्नुहोस्। SELinux र AppArmor ले फाइलको हरेक गुणले अनुमति दिने खोलाइ अस्वीकार गर्न सक्छन्, र त्यो अस्वीकृति क्लाइन्ट आउटपुटमा होइन, अडिट लगमा देखिन्छ। कुनै अस्वीकृतिमा कहिल्यै नदेखिने अनुमति परिवर्तन पूर्ण रूपमा गलत तहमा बिताइएको समय हो।

sudo journalctl -k -n 20 --no-pager
sudo ausearch -m AVC -ts recent | tail -5

सूचीले होइन, इन्टरफेसले प्रमाणित गर्नुहोस्

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

head -c 1 /dev/net/tun
head: error reading '/dev/net/tun': File descriptor in bad state

निर्णायक परीक्षणले इन्टरफेस बनाउँछ, किनकि त्यसले एउटै चरणमा ड्राइभर, नोड र तपाईंका विशेषाधिकार परीक्षण गर्छ। थप सफल भई लिङ्क देखियो भने तीनै काम गर्छन्। असफल हुँदा errno ले कारण अलग गर्छ: ENOENT भन्नाले प्रयोगयोग्य नोड छैन, EPERM ले क्षमता, माउन्ट झन्डा वा नीतितर्फ संकेत गर्छ, र EBUSY भन्नाले अर्को प्रक्रियाले इन्टरफेस पहिले नै ओगटेको छ।

sudo ip tuntap add dev tun7 mode tun
ip -brief link show tun7
sudo ip tuntap del dev tun7 mode tun

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

जब यन्त्र समस्या होइन

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

हरेक पटक नयाँ आविष्कार गर्नुको सट्टा ती पाँच जाँच चलाउनुहोस्: मोड्युल प्रतिद्वन्द्वी मोड्युल बिना लोड छ कि, बाटो सही major र minor भएको अक्षर यन्त्र हो कि, माउन्ट विकल्प सफा छन् कि, प्रक्रिया सन्दर्भमा क्षमता छ कि, र असफलताको समयमा नीति अस्वीकृति छ कि। पाँचै पार गर्ने खराबी यन्त्रको समस्या होइन, सन्देशले जे भने पनि।