OpenVPN मध्ये आधीच तयार केलेला tun: दोन मालकी मॉडेलांची तुलना

कोणीतरी tun1 आधीच तयार केला, प्रोफाइल dev tun1 असे सांगते, आणि कनेक्शन तरीही जोडले जात नाही. होस्टवर नाव असणे जवळपास काहीच सांगत नाही, कारण जोडणी नेमस्पेस, उपकरणाचा प्रकार, दुव्याचा मालक कोण आहे आणि डेमनला काय करण्याची परवानगी आहे यावर अवलंबून असते. उपकरणाचा पुनर्वापर केल्याने डीफॉल्ट कॉन्फिगरेशन लपवत असलेला निर्णयही लादला जातो: पत्ते आणि मार्ग कोणता घटक लिहितो. दोन्ही मांडण्यांच्या अयशस्वी होण्याच्या पद्धती कॉन्फिगरेशनच्या ओळींपेक्षा खूपच वेगळ्या आहेत, म्हणून प्रोफाइल संपादित करण्यापूर्वी निर्णय घ्या.

नाव म्हणजे जोडणी नाही

dev tun1 OpenVPN कडे त्या नावाचा इंटरफेस मागतो, आणि पारंपरिक युजरस्पेस बिल्ड तो उघडण्याचा प्रयत्न करतील. जर नाव नेहमीच्या tun किंवा tap पॅटर्नचे पालन करत नसेल, तर प्रोफाइलला जुळणारा dev-type देखील लागतो, कारण प्रकार कधीही स्ट्रिंगमधून अनुमानित केला जात नाही. TAP उपकरण वेगळ्या लेबलचे TUN उपकरण नाही: चुकीचे जोडल्यास एकतर लगेच अयशस्वी होते, किंवा कोणीही अपेक्षा न करणारे फ्रेम वाहून नेणारा दुवा तयार होतो. इतर सर्वांपूर्वी प्रकार तपासा, कारण पुढील प्रत्येक तपासणी दोन्ही बाजू त्यावर सहमत आहेत असे गृहीत धरते. त्यानंतर, प्रक्रिया उपकरण खरोखर उघडू शकते का, केवळ पाहू शकते नाही, याची खात्री करा.

dev tun1
dev-type tun

नेटवर्क इंटरफेस आणि /dev/net/tun वेगवेगळ्या वस्तू आहेत: एक नेमस्पेसच्या आतला दुवा आहे, दुसरे युजरस्पेस प्रोग्राम जोडणीसाठी वापरत असलेले वर्ण उपकरण. Linux TUN/TAP दस्तऐवज तो जोडणी मार्ग आणि कायम उपकरणांच्या मालकीचे नियम वर्णन करतो. ip link चालवू शकणारे root शेल फक्त शेलला विशेषाधिकार आहेत हे सिद्ध करते, डेमनला आहेत हे नाही. उपकरण नोडची मालकी, सेवेच्या क्षमतांचा संच आणि ती ज्या वापरकर्त्याखाली चालते — सर्व जुळले पाहिजेत, उघडणे यशस्वी होण्यापूर्वी.

असलेले पण उघडता न येणारे उपकरण ही मालकीची समस्या आहे, राउटिंगची नाही. डीबग करताना तसेच घ्या, अन्यथा दुपार अशा राउट टेबल वाचण्यात जाईल जी कधीच समस्या नव्हती.

दुवा कोण कॉन्फिगर करतो: दोन मालकी मॉडेल

पहिल्या मॉडेलमध्ये OpenVPN कनेक्शन उभारण्याचा भाग म्हणून पत्ते आणि मार्ग कॉन्फिगर करतो. हे डीफॉल्ट वर्तन आहे आणि समजून घेण्यास सर्वात सोपे, कारण एकच घटक स्थिती तयार करतो आणि पुन्हा काढून टाकतो. दुसऱ्या मॉडेलमध्ये बाह्य व्यवस्थापक इंटरफेसचा मालक असतो, आणि ifconfig-noexec OpenVPN ला त्याचे पत्ता-कॉन्फिगरेशन आदेश चालवण्यापासून थांबवतो आणि पॅरामीटर स्क्रिप्टांना देतो. मग व्यवस्थापकाने स्वतः योग्य स्थानिक आणि पीअर कॉन्फिगरेशन लागू करावे लागते, जे पर्यायाच्या नावाने सुचवले त्यापेक्षा जास्त काम आहे. या दोन्हींमधून निवडणे म्हणजे दुवा उभा असताना तो कोण बदलू शकतो याचा प्रश्न.

ifconfig-noexec केवळ पत्त्यांचा समावेश करतो: राउटिंग टेबल अस्पर्शित राहते, आणि मार्ग कॉन्फिगरेशन route-noexec चे आहे. दोन्ही निर्देशांना वेगवेगळे नियंत्रण आणि वेगवेगळे मालक म्हणून पहा, कारण एक सेट करून दुसरे गृहीत धरणे अर्धवट कॉन्फिगर केलेल्या दुव्यांचा नेहमीचा स्रोत आहे. प्रत्येक स्तरासाठी नेमका एक मालक निवडा, पत्ते एका ठिकाणी आणि मार्ग एका ठिकाणी. नेटवर्क व्यवस्थापक आणि VPN सहाय्यक दोघेही पत्ते लिहित असतील तर डिस्कनेक्ट इतर बाजू अजूनही अवलंबून असलेली स्थिती पुसून टाकते.

महत्त्वाच्या नेमस्पेसवरून उपकरण तपासा

VPN प्रक्रिया ज्या नेमस्पेसमध्ये चालते तिथून उपकरण तपासा, तुमचे शेल योगायोगाने ज्या नेमस्पेसमध्ये आहे तिथून नाही. खालील दोन आदेश वेगवेगळ्या प्रश्नांची उत्तरे देतात, आणि होस्टला कंटेनरला न दिसणारा इंटरफेस दिसतो तेव्हा फरक जाणवतो. ते दिलेल्या क्रमाने चालवा, कारण दुवा आहे की नाही हे कळल्यावरच दुसऱ्याला अर्थ आहे.

ip -details link show dev tun1
ip tuntap show

पहिला आदेश दुवा जसा कर्नेलला दिसतो तसा छापतो, फ्लॅग आणि इंटरफेस प्रकारासह, आणि याच पद्धतीने हेच तुमचे अभिप्रेत उपकरण आहे याची खात्री होते. दुसरा कायम tun/tap नोंदी सूचीबद्ध करतो, ज्या कोणत्याही प्रक्रियेने धरून न ठेवता अस्तित्वात असतात. आपल्या निश्चित मालकाची वाट पाहणारा इंटरफेस दुसऱ्या VPN ला जोडलेल्या जिवंत बोगद्यापेक्षा वेगळी परिस्थिती आहे, आणि तुमची स्वतःची जोडणी का अयशस्वी होते हे केवळ दुसरा स्पष्ट करतो. काहीही बदलण्यापूर्वी उपकरण धरून ठेवणारी प्रक्रिया शोधा, कारण कायम नोंद आणि व्यस्त इंटरफेस यांचे उपाय वेगळे आहेत.

मल्टिक्यू समर्थन ही स्वतःच्या गरजा असलेली विशिष्ट ड्रायव्हर मांडणी आहे, असंबंधित प्रक्रियांनी एक इंटरफेस सामायिक करण्याची परवानगी नाही. दुसऱ्या मालकाचे जिवंत सत्र समन्वयाची समस्या आहे, आणि कोणतेही प्रोफाइल संपादन ती सोडवत नाही.

दोन प्रकारची टिकाऊपणा

कर्नेल टिकाऊपणा आणि persist-tun अशा आयुष्यांचे वर्णन करतात जी एकत्र करणे सोपे आणि चूक करणे महाग आहे. कायम उपकरण कोणत्याही प्रक्रियेपासून स्वतंत्रपणे अस्तित्वात असते, म्हणून ते थांबवण्यातून टिकून राहते आणि पुढील सुरुवात ते पुन्हा वापरू शकते. persist-tun एकाच OpenVPN प्रक्रियेच्या आत समर्थित मऊ रीसेटमध्ये संसाधने टिकवून ठेवतो, खूपच लहान क्षितिज. दोन्हीपैकी कोणीही सेवा थांबवल्यावर मार्ग आणि पत्ते जागेवर राहतील असे वचन देत नाही, आणि दिसत राहणारा इंटरफेस कार्यरत एन्क्रिप्टेड सत्राचा पुरावा नाही.

बॅकएंडचीही खात्री करा, कारण आधीच तयार केलेला इंटरफेस कोणती अंमलबजावणी तो उघडेल याबद्दल काहीही सांगत नाही. थेट डेटा मार्ग असलेले समुदाय बिल्ड, रचना अन्यथा सांगत नसेल तर तो वापरण्याचा प्रयत्न करतील. जिथे आवृत्ती स्विचला समर्थन देते, तिथे disable-dco त्याऐवजी युजरस्पेस मार्ग निवडतो; जुन्या इंजिन आणि इतर क्लायंटकडे अशी सूचना नाही, म्हणून आवृत्तीची अट पर्यायाजवळ ठेवा, ती लागू होते असे गृहीत धरू नका.

केवळ सुरुवात तपासल्यास काय तुटते

मालकीचा करार पहिल्या चाचणीत उत्तीर्ण होऊन शेवटच्या चाचणीत अयशस्वी होऊ शकतो, ज्यामुळे सुरुवात एकटीच कमकुवत तपासणी ठरते. त्याऐवजी दोन संक्रमणे पहा: मऊ रीसेट, आणि पूर्ण थांबा त्यानंतर सुरुवात.

systemctl status openvpn-client@lab
ip -details link show dev tun1

सुरुवात सोपी स्थिती आहे: युनिट वर येते, दुवा दिसतो, आणि स्थितीचे आउटपुट लोड झालेल्या प्रोफाइलचे नाव सांगते. जोडणी म्हणजे डेमन उपकरण उघडतो तो क्षण, म्हणून युनिट सक्रिय असल्याचे कळवल्यानंतर दुवा तपासणी चालवा, त्यापूर्वी नाही. स्थिती अजून सक्रिय होत असतानाच दुवा असेल, तर तुम्ही अजून कोणीही न जोडलेले कायम उपकरण पाहत आहात, कार्यरत बोगदा नाही. पुढे जाण्यापूर्वी दुव्यातून खरा रहदारी पाठवा, कारण वापरण्यायोग्य मार्ग नसलेला जोडलेला इंटरफेसही अयशस्वीच आहे.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

मऊ रीसेटने सत्र वापरण्यायोग्य आणि संसाधने अखंड ठेवावीत, आणि तेच काम persist-tun करतो. पूर्ण थांबा ही अशी जागा आहे जिथे बाह्य व्यवस्थापक स्वतःला उघड करतो: दुवा किंवा त्याचे पत्ते थांब्यानंतर टिकले तर त्यांचा मालक दुसराच कोणी आहे, आणि ती एकतर तुम्ही नोंदवलेली स्थिती आहे किंवा आत्ताच सापडलेली बग. दोन्ही निरीक्षणे प्रोफाइलजवळ नोंदवा, जेणेकरून पुढील बदल आकृतीऐवजी पुराव्यावरून सुरू होईल.