Keyfile या Netplan: VPN प्रोफ़ाइल असल में कहाँ सहेजी जाती है?
सहेजा गया VPN किसी keyfile में या किसी जनरेट किए गए Netplan फ़ाइल में रह सकता है। फिर से लिखी जाने वाली कोई चीज़ संपादित करने से पहले कनेक्शन के UUID को उसके असली मालिक से मिलाएँ।
जो फ़ाइल आपने आयात की है उसे ढूँढ़ना आसान हिस्सा है और अक्सर ग़लत शुरुआत। असली बात यह है कि NetworkManager आज किस फ़ाइल को सहेजा हुआ कनेक्शन मानकर पढ़ता है, और यह एक कनेक्शन पहचानकर्ता तथा उस कॉन्फ़िगरेशन बैकएंड पर निर्भर है जिसे इंस्टॉल किए गए पैकेज वास्तव में इस्तेमाल करते हैं। उस सवाल का जवाब दिए बिना आयात संपादित करना ही वह तरीका है जिससे एक काम करता VPN दो आधी-सही कॉन्फ़िगरेशन बन जाता है।
आयात की गई फ़ाइल सहेजी गई प्रोफ़ाइल नहीं है
हर VPN समस्या के आसपास तीन नाम घूमते हैं: कनेक्शन का नाम, आपके द्वारा आयात की गई फ़ाइल का नाम, और वह वर्चुअल इंटरफ़ेस जो सुरंग उठने पर दिखता है। इनमें से कोई भी सहेजे गए कॉन्फ़िगरेशन की पहचान नहीं करता, और कनेक्शन का नाम संपादित किया जा सकता है जबकि उसके पीछे की फ़ाइल अपना मूल पहचानकर्ता बनाए रखती है।
केवल-पढ़ने वाली सूची से शुरू करें और लेबल के बजाय पहचानकर्ता से इच्छित VPN चुनें:
nmcli -f NAME,UUID,TYPE connection showटिकट में चिपकाई गई किसी भी सूची से एंडपॉइंट होस्टनाम और पहचान लेबल बाहर रखें। उपयोगी हिस्सा प्रकार और पहचानकर्ता है; बाकी ऐसा संदर्भ है जिसकी किसी अजनबी को ज़रूरत नहीं। साझा करने से पहले बाकी को छिपाएँ और कहें कि आपने ऐसा किया, ताकि कोई यह न सोचे कि खाली जगहों का क्या मतलब है।
keyfile की जगहों का एक ही मतलब नहीं होता
मूल keyfile प्लगइन के साथ, कनेक्शन फ़ाइलें तीन निर्देशिकाओं में दिख सकती हैं, और उनके बीच का अंतर स्थायित्व है, सुविधा नहीं।
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
रनटाइम प्रति को संपादित करना अगले शुरू होने तक सफल दिखता है, तब बदलाव वाष्पित हो जाता है और फ़ाइल रहस्यमय ढंग से वापस लौटी दिखती है। पैकेज द्वारा दी गई प्रति को संपादित करना तब तक काम करता है जब तक कोई अपग्रेड उसे बदल न दे, जो उसी सबक का धीमा और अधिक उलझाने वाला संस्करण है।
keyfile दस्तावेज़ एक ऐसा विवरण जोड़ता है जिसका सम्मान करना चाहिए: उन फ़ाइलों में निजी कुंजियाँ और पासफ़्रेज़ हो सकते हैं, और NetworkManager हर ऐसी keyfile को अनदेखा करता है जिसे root के अलावा अन्य उपयोगकर्ता पढ़ या लिख सकते हों। किसी सेटिंग को खोजने के लिए निर्देशिका अनुमतियाँ बढ़ाना उसी लोडिंग व्यवहार को तोड़ देता है जिसकी आप जाँच करना चाहते थे।
जब Netplan के पास स्थायित्व हो
Ubuntu पर, Netplan के दस्तावेज़ में वर्णित NetworkManager एकीकरण, जो 23.10 से उपलब्ध है, टिकाऊ प्रति के स्थान को बदल देता है। गैर-अस्थायी कनेक्शनों के लिए यह लिखता है /etc/netplan/90-NM-<connection UUID>.yaml और इसके अंतर्गत एक अस्थायी NetworkManager प्रोफ़ाइल जनरेट करता है: /run/NetworkManager/system-connections/।
यह एक वितरण एकीकरण है, हर NetworkManager इंस्टॉलेशन के लिए नियम नहीं। YAML फ़ाइल ढूँढ़ने जाने से पहले पुष्टि करें कि इंस्टॉल किए गए पैकेज वास्तव में इसका उपयोग करते हैं। यह भी याद रखें कि रनटाइम प्रोफ़ाइल किसी और चीज़ का जनरेट किया गया निरूपण हो सकता है, न कि वह स्रोत जिसे संपादित करना उचित है। दो कमांड की जाँच ग़लत फ़ाइल संपादित करने का एक घंटा बचाती है।
दस्तावेज़ी उदाहरण NetworkManager पासथ्रू डेटा के साथ Netplan nm-devices प्रकार के माध्यम से एक OpenVPN कनेक्शन सहेजता है। यह तथ्य कि Netplan की किसी विशेष VPN फ़ील्ड की अपनी व्याख्या नहीं है, इसका मतलब यह नहीं कि आपका सहेजा गया VPN खो गया है; इसका मतलब है कि वह फ़ील्ड अपारदर्शी डेटा के रूप में यात्रा करता है।
क्षणिक इंटरफ़ेस प्रोफ़ाइल नहीं होते
सक्रियण अस्थायी वर्चुअल कनेक्शन और इंटरफ़ेस बनाता है जो कभी टिकने के लिए नहीं थे। एकीकरण जान-बूझकर हर एक के लिए नई YAML फ़ाइल नहीं लिखता, इसलिए /etc/netplan में उनकी अनुपस्थिति इस बारे में कुछ नहीं कहती कि मूल प्रोफ़ाइल सहेजी गई है या नहीं।
अगर आप ऐसी फ़ाइल का पीछा कर रहे हैं जो आती और गायब हो जाती है, तो आप शायद अपने कॉन्फ़िगरेशन के बजाय इनमें से एक को देख रहे हैं। उसकी सामग्री से कोई निष्कर्ष निकालने से पहले जाँचें कि क्या वह पुनः आरंभ के बाद बची रहती है। रीबूट पर गायब होने वाली रनटाइम फ़ाइल आपको बताती है कि वह कभी स्रोत नहीं थी, और वह अकेला अवलोकन पूरी जाँच की दिशा बदल देता है। यह यह भी समझाता है कि उस समय संपादन सफल क्यों दिखा।
रहस्य और स्वामित्व
एक प्रोफ़ाइल कहीं और सहेजे गए प्रमाणपत्र या कुंजी का संदर्भ दे सकती है, और पासवर्ड NetworkManager का हो सकता है, किसी उपयोगकर्ता-सत्र गुप्त एजेंट द्वारा दिया जा सकता है, या जान-बूझकर न सहेजा जाए। इसलिए एक फ़ाइल का पता लगाना इस बारे में बहुत कम तय करता है कि बिना निगरानी वाले स्टार्टअप को क्या चाहिए होगा।
गुप्त मान छापे बिना संदर्भों और गुप्त-फ़्लैग की जाँच करें। डेस्कटॉप लॉगिन ऐसे एजेंट को उपलब्ध कर सकता है जो बूट के समय नहीं था, और जनरेट की गई रनटाइम फ़ाइल की नकल करने से वह एजेंट फिर से नहीं बनता। व्यावहारिक लक्षण वह सुरंग है जो किसी व्यक्ति के लॉगिन पर जुड़ती है और मशीन के अकेले शुरू होने पर विफल हो जाती है। यह पैटर्न रूटिंग की नहीं, रहस्य-स्वामित्व की ओर संकेत करता है।
स्वीकृत बदलाव उस प्रबंधक के माध्यम से करें जो कनेक्शन का मालिक है, फिर सहेजे गए पहचानकर्ता और प्रभावी कनेक्शन दोनों को सत्यापित करें। एक ही स्थायी मालिक रखें, क्योंकि आयात, जनरेट की गई keyfile और YAML स्रोत को अलग-अलग संपादित करने से इस बारे में तीन प्रतिस्पर्धी व्याख्याएँ रह जाती हैं कि अगला पुनः कनेक्शन क्या इस्तेमाल करेगा। जो वास्तव में टिकता है उसे चुनें, केवल उसी को संपादित करें, और टिकट में लिखें कि आपने किस फ़ाइल को प्रामाणिक माना। अगला व्यक्ति एक पंक्ति की उत्पत्ति के लिए आपका आभारी होगा।