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 दस्तावेज़ उस जुड़ाव पथ और स्थायी डिवाइसों के स्वामित्व नियमों का वर्णन करता है। जो root शेल ip link चला सकता है, वह केवल यह सिद्ध करता है कि शेल के पास विशेषाधिकार हैं, डेमन के पास हैं यह नहीं। डिवाइस नोड का स्वामित्व, सेवा की क्षमताओं का समूह और वह उपयोगकर्ता जिसके रूप में यह चलती है — सबको मेल खाना चाहिए खुलने के सफल होने से पहले।

जो डिवाइस मौजूद है पर खुलता नहीं, वह स्वामित्व की समस्या है, रूटिंग की नहीं। डिबग करते समय उसे वही मानें, वरना दोपहर ऐसे रूट टेबल पढ़ने में चली जाती है जो कभी समस्या ही नहीं थे।

लिंक कौन कॉन्फ़िगर करता है: दो स्वामित्व मॉडल

पहले मॉडल में 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 करता है। पूर्ण स्टॉप वह जगह है जहाँ बाहरी प्रबंधक खुद को प्रकट करता है: यदि लिंक या उसके पते स्टॉप के बाद भी बने रहें, तो उनका स्वामी कोई और है, और वह या तो आपके द्वारा दर्ज की गई स्थिति है या अभी मिली हुई बग। दोनों अवलोकन प्रोफ़ाइल के पास लिखें, ताकि अगला बदलाव किसी आरेख से नहीं, साक्ष्य से शुरू हो।