NetworkManager में OpenVPN और WireGuard फ़ाइलों का आयात विफल होता है

मैंने GNOME सेटिंग्स में फ़ाइल से आयात करें… चुना, विक्रेता के क्लाइंट के साथ काम करने वाली प्रोफ़ाइल चुनी, और संवाद बिना सूची में कुछ जोड़े बंद हो गया। दूसरे लैपटॉप पर आयात पूरा हुआ, कनेक्शन प्रोफ़ाइल के नाम से दिखा, और फिर पहले प्रमाणीकरण अनुरोध पर विफल हो गया। NetworkManager आपकी .ovpn या wg-quick फ़ाइल को कभी वैसे ही नहीं चलाता। वह फ़ाइल एक पार्सर को देता है, पार्सर उसे NetworkManager के अपने कनेक्शन प्रारूप में बदलता है, और उसके बाद सुरंग उसी पार्स की गई वस्तु से बनती है — रहस्य, रूट, DNS और सब कुछ। इसलिए उपयोगी सवाल यह नहीं कि फ़ाइल क्यों खराब है, बल्कि यह कि पार्सिंग हुई या नहीं और उसने क्या रखा।

आयात वास्तव में फ़ाइल के साथ क्या करता है

OpenVPN के लिए पार्सर प्लगइन पैकेज में रहता है, और जो कनेक्शन वह बनाता है वह org.freedesktop.NetworkManager.openvpn जैसी D-Bus सेवा की ओर इंगित करता है। प्लगइन नहीं तो पार्सर नहीं: प्रकार nmcli के लिए अज्ञात है, और VPN जोड़ने की ग्राफ़िकल सूची शायद आयात प्रविष्टि ही न दिखाए। WireGuard एक महत्वपूर्ण बिंदु पर अलग है — NetworkManager के पास 1.30 श्रृंखला से अपनी WireGuard सेटिंग्स हैं, इसलिए अलग प्लगइन पैकेज नहीं है, पर wg-quick पाठक केवल उन्हीं बिल्डों में है जो उसे देते हैं।

किसी भी तरह, फ़ाइल एक बार पढ़ी जाती है। परिणाम /etc/NetworkManager/system-connections/ के अंतर्गत keyfile के रूप में लिखा जाता है, कनेक्शन के नाम पर, root के स्वामित्व में और दूसरे उपयोगकर्ताओं के लिए अपठनीय क्योंकि इसमें कुंजी सामग्री है। वह keyfile अब कनेक्शन है; मूल .ovpn को बाद में संपादित करने से कुछ नहीं बदलता।

तीन लक्षण तीन अलग चरणों के हैं। आयात प्रविष्टि न होना या अज्ञात प्रकार का अर्थ है कि प्लगइन या संस्करण नहीं है। किसी निर्देश का नाम लेने वाली आयात त्रुटि का अर्थ है कि पार्सर ने फ़ाइल पढ़ी और उसका कुछ हिस्सा अस्वीकार किया। ऐसा कनेक्शन जो मौजूद है पर कभी सक्रिय नहीं होता, का अर्थ है कि पार्स की गई वस्तु अपूर्ण है या सर्वर उसे अस्वीकार कर रहा है। कुछ भी संपादित करने से पहले तय करें कि आपके पास तीन में से कौन सी स्थिति है।

प्रोफ़ाइल को डीबग करने से पहले प्लगइन की पुष्टि करें

गुम प्लगइन बिल्कुल खराब प्रोफ़ाइल जैसा दिखता है, इसलिए पहले पैकेज जाँचें। Debian और Ubuntu पर OpenVPN समर्थन network-manager-openvpn और एक डेस्कटॉप सहायक के रूप में आता है; Fedora पर पैकेज NetworkManager-openvpn और NetworkManager-openvpn-gnome हैं; Arch पर यह networkmanager-openvpn है।

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

फिर निरपेक्ष पथ से आयात करें: nmcli connection import type openvpn file /home/you/profile.ovpn। सापेक्ष पथ सामान्यतः काम करते हैं, पर जिस शेल ने निर्देशिका बदली हो वह तेज़ आयात को चक्कर में बदल देता है। WireGuard के लिए nmcli --version जाँचें और सुनिश्चित करें कि कर्नेल पक्ष modprobe wireguard के साथ मौजूद है; ऐसा आयात जो मॉड्यूल के बिना मशीन पर सफल होता है, आपको ऐसे कनेक्शन के साथ छोड़ता है जिसका उपकरण कभी नहीं दिखता। nmcli संदर्भ import उप-आदेश और स्वीकृत प्रकार नामों का दस्तावेज़ीकरण करता है। यदि type wireguard सीधे अस्वीकार हो जाए, तो बिल्ड इस सुविधा से पुराना है, और सही कदम वितरण पैकेज या backport है — कॉन्फ़िगरेशन को किसी मनमानी निर्देशिका में कॉपी करके यह आशा करना नहीं कि कोई उसे पढ़ेगा।

OpenVPN कनेक्शन पढ़ें, .ovpn नहीं

कनेक्शन बनने के बाद, फ़ाइल दोबारा पढ़ने के बजाय पार्स की गई सेटिंग्स पढ़ें: nmcli connection show "Work VPN" | grep -E '^vpn\.'। आपको remote और पोर्ट, ट्रांसपोर्ट, पहचान सामग्री — ca, cert, key, tls-auth या tls-crypt — और प्रमाणीकरण विधि चाहिए। निजी कुंजी के पासवर्ड वाली प्रोफ़ाइल में sudo nmcli --show-secrets connection show "Work VPN" जोड़ें और secret फ़्लैग देखें: 0 none है, यानी रहस्य keyfile में है; 1 agent-owned है; 2 not-saved है, यानी वह कभी keyfile में नहीं लिखा जाता; 4 not-required है, यानी किसी रहस्य की आवश्यकता ही नहीं। ये बिट हैं, पैमाना नहीं, इसलिए 3 सिर्फ़ agent-owned धन not-saved है। ऐसा रहस्य जो प्रति सत्र एक बार पूछा जाए, agent-owned (1) है जहाँ एजेंट उसे माँगता है; उसके लिए अलग फ़्लैग संख्या नहीं है। फ़्लैग बेमेल होना आम कारण है कि प्रोफ़ाइल डेस्कटॉप ऐपलेट से जुड़ती है और स्क्रिप्ट या बूट पर विफल होती है।

पार्सर ने क्या गिराया, यह देखने का सबसे तेज़ तरीका है प्लगइन से फ़ाइल वापस लिखने को कहना और फिर उसकी तुलना करना: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn। उस अंतर में जो निर्देश गायब हो जाएँ वे कनेक्शन के समय मौजूद नहीं होंगे। हुक आम संदिग्ध हैं — script-security, up, down और route-up ऊँचे अधिकारों से चलने वाली स्क्रिप्ट की अपेक्षा करते हैं और जानबूझकर स्थानांतरित नहीं होते। सत्यापन कम न करें और आयात सफल कराने के लिए अतिरिक्त विशेषाधिकार न दें; असमर्थित विकल्प आमतौर पर प्लगइन की सुविधा-सूची दर्शाता है, न कि किसी अगम्य सर्वर को। उस व्यवहार को NetworkManager डिस्पैचर स्क्रिप्ट या सर्वर-पक्ष नीति में ले जाएँ।

यह भी पुष्टि करें कि पहचान फ़ील्ड बचे रहे: CA संदर्भ, remote-cert-tls और कोई भी नाम जाँच जिस पर प्रोफ़ाइल निर्भर थी। जो कनेक्शन इनके बिना ऊपर आता है वह शायद उसी पते पर उत्तर देने वाले किसी भी चीज़ से बात कर रहा है।

WireGuard कनेक्शन पढ़ें, wg-quick फ़ाइल नहीं

wg-quick फ़ाइल शेल अर्थ वाला प्रारूप है; आयात किया गया कनेक्शन सेटिंग्स का समूह है। PrivateKey इंटरफ़ेस की निजी कुंजी बनती है, Address एक या अधिक IPv4 और IPv6 पते बनते हैं, DNS NetworkManager की resolver विशेषताओं पर मैप होता है, MTU wireguard.mtu पर मैप होता है (wg-quick का अपना डिफ़ॉल्ट 1420 है), और हर peer ब्लॉक सार्वजनिक कुंजी, endpoint, अनुमत IP और persistent keepalive वाली peer प्रविष्टि बनता है। जो संग्रहीत हुआ उसे nmcli --show-secrets connection show wg0 से प्रिंट करें; यदि peer सूची उस आउटपुट में न दिखे तो keyfile पढ़ें:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

जो नहीं बचता वह wg-quick का शेल वाला आधा है। PreUp, PostUp, PreDown, PostDown और Table उस उपकरण का व्यवहार हैं, WireGuard इंटरफ़ेस के गुण नहीं, इसलिए आयात के बाद उन्हें कोई नहीं चलाता। यदि मूल ने Table = off इस्तेमाल किया तो डिफ़ॉल्ट रूट को अछूता रखने के लिए, तो नए NetworkManager संस्करण उसी उद्देश्य के लिए ip4-auto-default-route और ip6-auto-default-route देते हैं; उन्हें स्पष्ट रूप से सेट करें, बजाय यह मानने के कि कनेक्शन स्क्रिप्ट की तरह व्यवहार करता है। जो हुक कस्टम रूट धकेलता था उसे वह रूट कनेक्शन की रूटिंग सेटिंग्स में चाहिए, वरना वह बस गायब रहेगा।

कनेक्शन को ठीक एक स्वामी दें

क्लासिक बाद वाली विफलता वह कनेक्शन है जो अगले बूट तक काम करता है और फिर लूप में पड़ जाता है। आमतौर पर [email protected] पिछले प्रयोग से अब भी सक्षम था, या विक्रेता का क्लाइंट अपना डेमॉन चला रहा था, और दो स्वामी एक ही गंतव्य के लिए रूट और DNS लिख रहे थे। NetworkManager resolver को अपने रास्ते से सेट करता है, wg-quick resolvconf के ज़रिए लिखता है, और अंतिम लिखने वाला जीतता है — इसलिए नाम विश्लेषण काम करता है, फिर रुकता है, फिर दोबारा काम करता है। systemctl status wg-quick@wg0, nmcli connection show --active और ip link show type wireguard जाँचें, फिर दूसरे स्वामी को अक्षम करें, उसका metric ट्यून करने के बजाय।

यदि आपको वाकई दोनों चाहिए, तो उन्हें अलग इंटरफ़ेस और असंबद्ध अनुमत IP दें, और ठीक एक को डिफ़ॉल्ट रूट इंस्टॉल करने दें। अलग metrics वाले दो डिफ़ॉल्ट रूट split tunnel नहीं हैं; यह एक दौड़ है जिसे वह सेवा तय करती है जो दूसरी शुरू होती है। और पुनः कनेक्ट के बाद, लागू स्थिति फिर देखें — resolver का एकबारगी मैनुअल संपादन जो चीज़ें चला देता है, आयात के पूर्ण होने का प्रमाण नहीं है।

ट्रैफ़िक से सत्यापित करें और रीबूट झेलें

कनेक्शन को nmcli connection up "Work VPN" से ऊपर उठाएँ, फिर आइकन पर भरोसा करने के बजाय स्थिति, पता और रूट पढ़ें: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default और ऐसे नाम की वास्तविक क्वेरी जो केवल सुरंग के भीतर ही हल होता है। हैंडशेक या सफल ping केवल यह सिद्ध करता है कि क्रिप्टोग्राफ़ी काम करती है; यह फ़ॉरवर्डिंग, split tunnel उपसर्ग या निजी DNS के बारे में कुछ नहीं कहता, और आमतौर पर यही हिस्से टूटते हैं।

फिर रीबूट करें और दोहराएँ। autoconnect व्यवहार, बदला हुआ इंटरफ़ेस नाम और उपकरण के बाद लोड होने वाला प्लगइन — ये सब वे विफलताएँ हैं जो केवल साफ़ बूट पर दिखती हैं। journalctl -u NetworkManager -b --no-pager | tail -n 40 दिखाता है कि डेमॉन ने इस बूट में इस कनेक्शन के साथ क्या किया। दूसरे कंप्यूटर के लिए keyfile कॉपी करें और उसे root स्वामित्व में 600 मोड के साथ रखें, या OpenVPN के लिए nmcli connection export इस्तेमाल करें और बनी .ovpn को दोबारा आयात करें — निर्यात पथ का WireGuard में कोई समकक्ष नहीं है, इसलिए वह दिशा फ़ाइल कॉपी या संरक्षित मूल से नया आयात है।

छोटा संस्करण, क्रम से: प्लगइन या NetworkManager संस्करण की पुष्टि करें, निरपेक्ष पथ से आयात करें, secret फ़्लैग सहित पार्स की गई सेटिंग्स पढ़ें, OpenVPN निर्यात की मूल से तुलना करें, WireGuard पक्ष पर हुक और रूट जाँचें, कोई भी दूसरा स्वामी अक्षम करें, और फिर रीबूट के बाद नाम विश्लेषण और रूट तालिका सत्यापित करें। जब कोई कनेक्शन यह सब पास कर ले, तो उसे शुरू करने वाली प्रोफ़ाइल फ़ाइल संरक्षित भंडार में लौट सकती है।