Importul în NetworkManager eșuează la fișierele OpenVPN și WireGuard

Am ales Importă din fișier… în Setările GNOME, am ales un profil care funcționează cu clientul furnizorului, iar dialogul s-a închis fără să adauge nimic în listă. Pe un al doilea laptop importul s-a încheiat, conexiunea a apărut sub numele profilului și apoi a eșuat la prima solicitare de autentificare. NetworkManager nu rulează niciodată fișierul tău .ovpn sau wg-quick ca atare. Îl predă unui parser, parserul îl transformă în formatul de conexiune propriu al NetworkManager, iar de acolo tunelul este construit din acel obiect parsat: secrete, rute, DNS și tot restul. Așadar întrebarea utilă nu este de ce fișierul este stricat, ci dacă parsarea a avut loc și ce a păstrat.

Ce face de fapt importul cu fișierul

Pentru OpenVPN, parserul se află în pachetul pluginului, iar conexiunea pe care o creează indică un serviciu D-Bus precum org.freedesktop.NetworkManager.openvpn. Fără plugin nu există parser: tipul este necunoscut pentru nmcli, iar lista grafică de adăugare a unui VPN poate să nu afișeze deloc o intrare de import. WireGuard diferă într-un punct important — NetworkManager are propriile setări WireGuard din seria 1.30, deci nu există un pachet de plugin separat, dar cititorul wg-quick există doar în build-urile care îl includ.

În orice caz, fișierul este citit o singură dată. Rezultatul este scris ca keyfile în /etc/NetworkManager/system-connections/, numit după conexiune, deținut de root și ilizibil pentru alți utilizatori pentru că conține materialul cheilor. Acel keyfile este acum conexiunea; editarea ulterioară a .ovpn original nu schimbă nimic.

Trei simptome aparțin la trei faze diferite. Lipsa unei intrări de import sau un tip necunoscut înseamnă că lipsește pluginul sau versiunea. O eroare de import care numește o directivă înseamnă că parserul a citit fișierul și a respins o parte din el. O conexiune care există dar nu se activează niciodată înseamnă că obiectul parsat este incomplet sau că serverul o refuză. Decide care dintre cele trei este cazul tău înainte de a edita ceva.

Confirmă pluginul înainte de a depana profilul

Un plugin lipsă arată exact ca un profil corupt, așa că verifică mai întâi pachetul. Pe Debian și Ubuntu suportul OpenVPN vine ca network-manager-openvpn plus un helper de desktop; pe Fedora pachetele sunt NetworkManager-openvpn și NetworkManager-openvpn-gnome; pe Arch este networkmanager-openvpn.

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

Apoi importă dintr-o cale absolută: nmcli connection import type openvpn file /home/you/profile.ovpn. Căile relative funcționează de obicei, dar un shell care a schimbat directorul transformă un import rapid într-un ocol. Pentru WireGuard, verifică nmcli --version și asigură-te că partea de kernel există cu modprobe wireguard; un import care reușește pe o mașină fără modul te lasă cu o conexiune al cărei dispozitiv nu apare niciodată. Referința nmcli documentează subcomanda import și numele de tip acceptate. Dacă type wireguard este respins direct, build-ul este mai vechi decât funcția, iar pasul corect este un pachet de distribuție sau un backport — nu copierea configurației într-un director arbitrar sperând că ceva o va citi.

Citește conexiunea OpenVPN, nu fișierul .ovpn

Odată ce conexiunea există, citește setările parsate în loc să recitești fișierul: nmcli connection show "Work VPN" | grep -E '^vpn\.'. Vrei remote și portul, transportul, materialul de identitate — ca, cert, key, tls-auth sau tls-crypt — și metoda de autentificare. Pe un profil cu parolă pentru cheia privată, adaugă sudo nmcli --show-secrets connection show "Work VPN" și uită-te la secret flags: 0 este none, deci secretul stă în keyfile; 1 este agent-owned; 2 este not-saved, adică nu este scris niciodată în keyfile; 4 este not-required, adică nu este nevoie deloc de secret. Sunt biți, nu o scară, deci 3 este pur și simplu agent-owned plus not-saved. Un secret care te întreabă o dată pe sesiune este agent-owned (1), agentul cerându-l; nu există un număr de flag separat pentru asta. O nepotrivire de flaguri este motivul obișnuit pentru care un profil se conectează din appletul de desktop și eșuează dintr-un script sau la boot.

Cea mai rapidă cale de a vedea ce a abandonat parserul este să ceri pluginului să scrie fișierul înapoi și apoi să îl compari: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn. Directivele care dispar în acel diff nu vor exista la momentul conectării. Hook-urile sunt suspecții obișnuiți — script-security, up, down și route-up așteaptă un script rulat cu privilegii ridicate și nu sunt preluate în mod deliberat. Nu coborî verificarea și nu acorda privilegii suplimentare pentru ca un import să reușească; o opțiune nesuportată reflectă de obicei setul de funcții al pluginului, nu un server inaccesibil. Mută comportamentul respectiv într-un script dispatcher NetworkManager sau într-o politică pe partea de server.

Confirmă și că câmpurile de identitate au supraviețuit: referința CA, remote-cert-tls și orice verificare de nume pe care se baza profilul. O conexiune care urcă fără ele poate vorbi cu orice răspunde la acea adresă.

Citește conexiunea WireGuard, nu fișierul wg-quick

Un fișier wg-quick este un format cu semantică de shell; conexiunea importată este un set de setări. PrivateKey devine cheia privată a interfeței, Address devine una sau mai multe adrese IPv4 și IPv6, DNS se mapează pe proprietățile de resolver ale NetworkManager, MTU se mapează pe wireguard.mtu (valoarea implicită a wg-quick este 1420), iar fiecare bloc peer devine o intrare peer cu cheie publică, endpoint, IP-uri permise și keepalive persistent. Afișează ce s-a stocat cu nmcli --show-secrets connection show wg0; dacă lista de peers nu apare în acea ieșire, citește keyfile-ul:

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

Ce nu supraviețuiește este jumătatea de shell a wg-quick. PreUp, PostUp, PreDown, PostDown și Table sunt comportamentul acelui instrument, nu atribute ale unei interfețe WireGuard, așa că nimic nu le rulează după un import. Dacă originalul folosea Table = off pentru a lăsa ruta implicită în pace, versiunile recente de NetworkManager expun ip4-auto-default-route și ip6-auto-default-route în același scop; setează-le explicit în loc să presupui că conexiunea se comportă ca scriptul. Un hook care împingea o rută personalizată are nevoie de acea rută în setările de rutare ale conexiunii, altfel va lipsi pur și simplu.

Dă conexiunii exact un proprietar

Eșecul clasic de după este o conexiune care funcționează până la următorul boot și apoi intră în buclă. De obicei [email protected] era încă activat dintr-un experiment anterior, sau un client al furnizorului își lansa propriul daemon, și doi proprietari scriau rute și DNS pentru aceeași destinație. NetworkManager setează resolverul pe calea sa proprie, wg-quick scrie prin resolvconf, și câștigă ultimul care scrie — așa că rezolvarea numelor funcționează, apoi se oprește, apoi funcționează din nou. Verifică systemctl status wg-quick@wg0, nmcli connection show --active și ip link show type wireguard, apoi dezactivează al doilea proprietar în loc să-i reglezi metrica.

Dacă ai cu adevărat nevoie de amândouă, dă-le interfețe separate și IP-uri permise disjuncte, și lasă exact unul dintre ele să instaleze ruta implicită. Două rute implicite cu metrici diferite nu sunt un split tunnel; este o cursă decisă de serviciul care pornește al doilea. Și după o reconectare, inspectează din nou starea aplicată — o modificare manuală unică a resolverului care face lucrurile să meargă nu este dovada că importul este complet.

Verifică cu trafic și supraviețuiește unei reporniri

Ridică conexiunea cu nmcli connection up "Work VPN", apoi citește starea, adresa și rutele în loc să te bazezi pe pictogramă: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default și o căutare reală a unui nume care se rezolvă doar în interiorul tunelului. Un handshake sau un ping reușit dovedește doar că criptografia funcționează; nu spune nimic despre forwarding, prefixele de split tunnel sau DNS-ul privat, care sunt părțile care se strică de obicei.

Apoi repornește și repetă. Comportamentul de autoconnect, o interfață redenumită și un plugin care se încarcă după dispozitiv sunt tot atâtea eșecuri pe care le vezi doar la un boot curat. journalctl -u NetworkManager -b --no-pager | tail -n 40 arată ce a făcut daemonul cu această conexiune în acest boot. Pentru un al doilea desktop, copiază keyfile-ul și păstrează-l deținut de root cu modul 600, sau folosește nmcli connection export pentru OpenVPN și reimportă .ovpn rezultat — calea de export nu are echivalent WireGuard, deci acea direcție este o copie de fișier sau un import nou din originalul protejat.

Versiunea scurtă, în ordine: confirmă pluginul sau versiunea NetworkManager, importă dintr-o cale absolută, citește setările parsate inclusiv secret flags, compară exportul OpenVPN cu originalul, verifică hook-urile și rutele pe partea WireGuard, dezactivează orice al doilea proprietar, apoi verifică după o repornire o rezolvare de nume și tabela de rutare. Când o conexiune trece de toate acestea, fișierul de profil care a pornit-o poate reveni în stocarea protejată.