विक्रेता का VPN ऐप बनाम NetworkManager: स्थिति का स्वामी कौन है?
प्रोफ़ाइल एक प्लगइन का नाम देती है, विक्रेता क्लाइंट के व्यवहार का नहीं। प्रबंधित लैपटॉप बदलने से पहले तय करें कि नामांकन, DNS, अवरोधन और अपडेट का स्वामी कौन है।
प्रोफ़ाइल आयात करना क्लाइंट बदलने के बराबर नहीं है। NetworkManager प्लगइन प्रकार को प्लगइन-विशिष्ट डेटा और रहस्यों के साथ संग्रहीत करता है, और जो प्लगइन उस प्रकार का स्वामी है वही तय करता है कि कनेक्शन क्या कर सकता है। विक्रेता का एप्लिकेशन ऊपर जो कुछ भी परत चढ़ाता है, नामांकन से लेकर स्थायी अवरोधन तक, फ़ाइल के बाहर रहता है। बदलाव सुरक्षित है या नहीं, यह इस पर निर्भर करता है कि आप वास्तव में उनमें से किन परतों पर भरोसा करते हैं।
फ़ाइल प्लगइन का नाम देती है, सुविधाओं के समूह का नहीं
NetworkManager का VPN सेटिंग्स संदर्भ एक सेवा प्रकार का वर्णन करता है जो प्लगइन चुनता है, साथ ही एक अपारदर्शी डेटा शब्दकोश और एक रहस्य शब्दकोश जिसकी व्याख्या केवल प्लगइन करता है। प्रोफ़ाइल एक कार्यान्वयन के साथ अनुबंध है, ऐसे व्यवहार का वर्णन नहीं जिसे कोई भी क्लाइंट दोहरा सके। दो क्लाइंट एक ही प्रोटोकॉल बोल सकते हैं और फिर भी इसमें भिन्न हो सकते हैं कि वे क्या बातचीत करते हैं और कौन से डेटा पथ सक्षम करते हैं। प्रोटोकॉल का लेबल आपको बताता है कि सुरंग क्या है, कभी नहीं कि आसपास का क्लाइंट उसके साथ क्या करता है।
इसलिए आवरणों के बजाय आवश्यकताओं की तुलना करें। प्रश्न यह नहीं है कि विकल्प जुड़ सकता है या नहीं, क्योंकि सामान्यतः जुड़ सकता है; प्रश्न यह है कि मूल क्लाइंट को स्वीकार्य बनाने वाली हर आवश्यकता इस बदलाव में टिकती है या नहीं। कुछ भी स्थापित करने से पहले उन आवश्यकताओं को लिख लें, अन्यथा तुलना पहले क्या टूटेगा उसकी खोज में बदल जाएगी।
सुरंग के आसपास विक्रेता ऐप क्या जोड़ता है
विक्रेता क्लाइंट सामान्यतः नामांकन और डिवाइस मुद्रा जाँचें, अपने इंटरफ़ेस वाला दूसरा कारक प्रवाह, स्थायी अवरोधन, एक अपडेट चैनल और सहायता उपकरण एक साथ बाँधते हैं। इसमें से कुछ प्रोटोकॉल के बगल में बैठता है, और कुछ अलग उत्पाद है जो केवल इंस्टॉलर साझा करता है। NetworkManager सुरंग और उसके रूटिंग को बदल सकता है, और कनेक्शन की स्थिति बदलने पर डिस्पैचर स्क्रिप्ट क्रियाएँ चला सकती हैं। पर वह अवरोधन इंजन, प्रमाणपत्र नवीनीकरण प्रवाह या इस धारणा को दोहराता नहीं है कि कौन-सा उपयोगकर्ता कनेक्शन उठा सकता है।
अधिक घटकों का अर्थ अधिक सुरक्षित नहीं, और कम का अर्थ अधिक कमज़ोर नहीं। प्रश्न यह है कि कौन-सा घटक उस नीति को लागू करता है जिसका पालन करने को कहा गया था। यदि कोई लेखा-परीक्षक पूछे कि सुरंग गिरने पर ट्रैफ़िक कौन रोकता है, तो उत्तर में ऐसा कुछ नाम लेना होगा जो वास्तव में वह करता हो, और केवल जुड़ने वाली प्रोफ़ाइल वह उत्तर नहीं है।
स्वामित्व वास्तव में कहाँ भिन्न है
इसे चेकलिस्ट नहीं, स्वामित्व का नक्शा समझें, क्योंकि नीचे की विफलताएँ स्वामित्व के अंतराल हैं और क्लाइंट कॉन्फ़िगरेशन की कोई भी मात्रा उन्हें बंद नहीं करती। हर पंक्ति उस परत का नाम देती है, आज सामान्यतः उसे कौन रखता है, और अंतराल पहले कहाँ दिखता है।
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
हर पंक्ति को क्लाइंट के बारे में भावना के बजाय ऐसी टिप्पणी से जोड़ें जिसे आप दोहरा सकें। इच्छित रिज़ॉल्वर से हल किया गया नाम, सुरंग रुकने पर गायब होने वाला रूट, और अनुकरणीय कटाव के बाद अवरुद्ध कनेक्शन — ये तीन अवलोकन मिलकर तालिका का अधिकांश भाग ढक लेते हैं। अवलोकन को उस आवश्यकता के बगल में लिखें जिसे वह सिद्ध करता है, और विफल हुए लोगों को रखें, क्योंकि विफल अवलोकन ही रिकॉर्ड का वह अंश है जो अगली घटना का पूर्वानुमान करता है।
स्वामित्व को ओवरलैप किए बिना बदलना
एक ही सेवा के लिए विक्रेता क्लाइंट और NetworkManager कनेक्शन को एक साथ चलाना इन तुलनाओं के गलत होने का सबसे आम तरीका है। दोनों रूट स्थापित करते हैं, दोनों DNS सेट कर सकते हैं, और दोनों फ़ायरवॉल की स्थिति को छू सकते हैं। तब आप जो मापते हैं वह तीसरी व्यवस्था है जो दोनों क्लाइंटों के प्रलेखित व्यवहार से मेल नहीं खाती।
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"पहला आदेश बताता है कि प्रोफ़ाइल बिलकुल VPN प्रकार की है या नहीं। दूसरा प्लगइन सेवा प्रकार और संग्रहीत रहस्य दिखाता है, जो तब मायने रखता है जब कुंजी फ़ाइल के बजाय एजेंट से अपेक्षित हो। जर्नल वह जगह है जहाँ लोड हुआ पर बातचीत न कर सका प्लगइन यह कहेगा। यदि तीनों में से कोई समस्या न दिखाए, तो अंतराल कनेक्शन में नहीं, सुरंग के ऊपर की नीति परतों में है।
नया कनेक्शन सक्षम करने से पहले पुराना क्लाइंट डिस्कनेक्ट करें, एंडपॉइंट और खाता समान रखें, और लिखें कि रूट, रिज़ॉल्वर सेटिंग्स और अवरोधन का स्वामी कौन-सा घटक है। यही नोट अगले अपडेट को दो स्वामियों के साथ समाप्त होने से रोकता है।