VPS वर OpenVPN: उघडण्यासाठी /dev/net/tun उपकरण नाही
कॉन्फिग बहुतेक वेळा ठीक असतो: गेस्टला tun उपकरण दिसत नाही. हे VM आहे की कर्नेल सामायिक करणारा कंटेनर, हे वेगळे करा आणि मग कर्नेलच्या मालकीचा थर दुरुस्त करा.
पहिली सुरुवात /dev/net/tun किंवा उघडता न येणाऱ्या TUN/TAP उपकरणाबद्दलच्या संदेशासह अयशस्वी होते। प्रमाणपत्रे अजून वाचलेली नाहीत, त्यामुळे प्रोफाइलमध्ये काहीही दोषी नाही। डेमन कर्नेलकडे अशा वस्तूची मागणी करत आहे जी या गेस्टकडे नाही।
ती वस्तू tun मॉड्यूलने पुरवलेले अक्षर उपकरण आहे। तुम्ही ते तयार करू शकता का, हे कर्नेल कोणाच्या मालकीचे आहे यावर अवलंबून आहे।
डेमन कर्नेलकडे काय मागतो
OpenVPN /dev/net/tun उघडते आणि ड्रायव्हरकडे इंटरफेस मागते। ड्रायव्हर म्हणजे tun मॉड्यूल, आणि उपकरण नोड म्हणजे वापरकर्ता जागा त्यापर्यंत पोहोचण्यासाठी वापरत असलेली हँडल। मॉड्यूल लोड नसेल तर नोड नसू शकतो किंवा उघडणे अयशस्वी होऊ शकते। दोन्ही स्थिती server.conf संपादित करून सुधारत नाहीत।
ही त्रुटी प्रथम प्लॅटफॉर्मबद्दलचा प्रश्न म्हणून वाचा। कॉन्फिग त्रुटी उपकरण उघडल्यानंतर दिसते, त्यापूर्वी नाही।
VM की कर्नेल सामायिक करणारा गेस्ट
KVM, Xen किंवा दुसऱ्या पूर्ण व्हर्च्युअल मशीनवर कर्नेल तुमच्या नियंत्रणात असते। तुम्ही मॉड्यूल लोड करू शकता आणि नोड तयार करू शकता। OpenVZ, Virtuozzo किंवा LXC शैलीतील कंटेनरमध्ये गेस्ट होस्टचे कर्नेल सामायिक करतो, त्यामुळे आतल्या root ला होस्टने लोड न केलेले मॉड्यूल लोड करता येत नाही।
म्हणून त्याच अयशस्वीतेचे दोन पूर्णपणे वेगळे मालक आहेत। पहिल्या स्थितीत तुम्ही ती इन्स्टन्सच्या आतून दुरुस्त करू शकता। दुसऱ्यात तुम्ही होस्ट किंवा प्रदात्याला काहीतरी उघड करण्यास सांगत आहात।
तुम्ही कोणत्या स्थितीत आहात हे ठरवण्यापूर्वी ls -l /dev/net/tun, lsmod | grep tun आणि ip -brief link show चालवा।
VM वर बूटच्या वेळी मॉड्यूल लोड करा
व्हर्च्युअल मशीनवर modprobe tun सहसा उपकरण नोड तयार करते। तो दिसला का ते तपासा, नंतर एकदा टाइप केलेल्या आदेशावर अवलंबून न राहता वितरणाच्या मॉड्यूल कॉन्फिगद्वारे लोड कायम करा। रीबूटनंतर जो नोड नाहीसा होतो तो पुढच्या महिन्यात तोच तिकीट बनतो।
तुम्ही बूट केलेल्या कर्नेलमध्ये ते मॉड्यूल अजिबात उपलब्ध आहे का तेही तपासा। कात्रीलेल्या विक्रेत्याच्या कर्नेलमध्ये ते नसू शकते।
नोड आहे पण उघडणे अजूनही अयशस्वी होत असेल, तर पुढील संशयित परवानग्या आणि उपकरणाचे major/minor क्रमांक आहेत। त्या स्थानिक दुरुस्त्या आहेत, प्रदात्याकडे केलेली विनंती नाही।
कंटेनरमध्ये उपकरण होस्टच्या मालकीचे असते
कंटेनरमध्ये उपकरण आणि क्षमता या दोन वेगळ्या आवश्यकता आहेत। रनटाइमने /dev/net/tun पास करून द्यावे लागते, आणि कंटेनरला इंटरफेस तयार करण्यासाठी नेटवर्क क्षमता लागते। दोन्ही न देणारा rootless रनटाइम प्रोफाइल कसेही लिहिले तरी तीच उघडण्याची त्रुटी देत राहील। अनेक OpenVZ होस्ट ग्राहक पॅनलमध्ये TUN/TAP टॉगल देतात, आणि तो सुरू करून रीस्टार्ट केल्यास बहुतेक वेळा संपूर्ण उपाय तोच असतो।
प्रदात्याला दोन नेमके प्रश्न विचारा: होस्टवर tun मॉड्यूल लोड आहे का आणि या इन्स्टन्सच्या आत उपकरण उपलब्ध आहे का? अस्पष्ट तिकिटाला अस्पष्ट उत्तर मिळते।
मॉड्यूल पुन्हा बांधणे का क्वचितच मदत करते
गेस्टच्या आत मॉड्यूल बांधणे क्वचितच मदत करते। कंपाइल करण्यासाठी नक्की चालू असलेल्या कर्नेलचे कॉन्फिग लागते, आणि /proc/config.gz ऐच्छिक आहे व किमान इमेजवर बहुतेक वेळा नसते। कार्यरत मॉड्यूलही कंटेनरच्या मालकीचे नसलेल्या कर्नेलमध्ये घालता येत नाही।
उपकरण दिसल्यानंतर सेवा रीस्टार्ट करा आणि रहदारी तपासण्यापूर्वी इंटरफेसची खात्री करा। tun0 दिसणे म्हणजे डेमनने उपकरण उघडले। फॉर्वर्डिंग, फायरवॉल नियम किंवा क्लायंटना मिळणाऱ्या मार्गांबद्दल ते अजून काहीही सांगत नाही।
ही स्वतंत्र पुराव्यांसह स्वतंत्र प्रश्न आहेत। उपकरण नसणे म्हणजे पूर्वअटीचे अपयश; असूनही काहीही न वाहणारा बोगदा म्हणजे धोरणाचे अपयश।