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 બાજુએ હૂક અને રૂટ તપાસો, કોઈપણ બીજા માલિકને નિષ્ક્રિય કરો, અને પછી રીબૂટ પછી નામ વિશ્લેષણ અને રૂટ કોષ્ટક ચકાસો. જ્યારે કનેક્શન આ બધું પાસ કરે, ત્યારે તેને શરૂ કરનારી પ્રોફાઇલ ફાઇલ સુરક્ષિત ભંડારમાં પાછી જઈ શકે છે.