Keyfile sau Netplan: unde este stocat de fapt profilul VPN?

Găsirea fișierului pe care l-ați importat este partea ușoară și adesea începutul greșit. Contează ce fișier citește NetworkManager astăzi ca conexiune salvată, iar asta depinde de un identificator de conexiune plus backend-ul de configurare pe care pachetele instalate îl folosesc efectiv. Editarea importului înainte de a răspunde la această întrebare este modul în care un VPN funcțional devine două configurații pe jumătate corecte.

Fișierul importat nu este profilul salvat

Trei nume plutesc în jurul fiecărei probleme VPN: numele conexiunii, numele fișierului pe care l-ați importat și interfața virtuală care apare când tunelul se ridică. Niciunul nu identifică configurația salvată, iar numele unei conexiuni poate fi editat în timp ce fișierul din spate își păstrează identificatorul original.

Începeți cu un inventar doar pentru citire și alegeți VPN-ul dorit după identificator, nu după etichetă:

nmcli -f NAME,UUID,TYPE connection show

Țineți numele de gazdă ale punctelor finale și etichetele de identitate în afara oricărui inventar pe care îl lipiți într-un tichet. Partea utilă este tipul și identificatorul; restul este context de care un străin nu are nevoie. Redactați restul înainte de a partaja și spuneți că ați făcut asta, ca să nu se întrebe nimeni ce înseamnă golurile.

Locațiile keyfile nu înseamnă același lucru

Cu pluginul keyfile nativ, fișierele de conexiune pot apărea în trei directoare, iar diferența dintre ele este persistența, nu comoditatea.

Editarea copiei de rulare pare reușită până la următoarea pornire, când modificarea se evaporă și fișierul pare readus în mod misterios. Editarea copiei furnizate de pachet funcționează până când o actualizare o înlocuiește, ceea ce este o versiune mai lentă și mai confuză a aceleiași lecții.

Documentația keyfile adaugă un detaliu care merită respectat: acele fișiere pot conține chei private și fraze de acces, iar NetworkManager ignoră orice keyfile pe care utilizatorii alții decât root îl pot citi sau scrie. Extinderea permisiunilor directorului pentru a căuta o setare strică comportamentul de încărcare pe care încercați să îl inspectați.

Când Netplan deține persistența

Pe Ubuntu, integrarea NetworkManager descrisă în documentația Netplan, disponibilă din 23.10, schimbă locul unde locuiește copia durabilă. Pentru conexiunile netemporare scrie /etc/netplan/90-NM-<connection UUID>.yaml și generează un profil NetworkManager efemer sub /run/NetworkManager/system-connections/.

Aceasta este o integrare de distribuție, nu o regulă pentru fiecare instalare NetworkManager. Confirmați că pachetele instalate o folosesc efectiv înainte de a căuta un fișier YAML. Amintiți-vă și că un profil de rulare poate fi o reprezentare generată a altceva, nu sursa care merită editată. Două comenzi de verificare economisesc o oră de editare a fișierului greșit.

Exemplul documentat stochează o conexiune OpenVPN prin tipul Netplan nm-devices cu date de passthrough NetworkManager. Faptul că Netplan nu are o interpretare dedicată unui anumit câmp VPN nu înseamnă că VPN-ul salvat s-a pierdut; înseamnă că câmpul călătorește ca date opace.

Interfețele tranzitorii nu sunt profiluri

Activarea creează conexiuni și interfețe virtuale temporare care nu ar fi trebuit să persiste niciodată. Integrarea în mod deliberat nu scrie un fișier YAML nou pentru fiecare, așa că absența lor din /etc/netplan nu spune nimic despre dacă profilul părinte este salvat.

Dacă urmăriți un fișier care apare și dispare, probabil priviți unul dintre acestea și nu configurația dvs. Verificați dacă supraviețuiește unei reporniri înainte de a trage vreo concluzie din conținutul lui. Un fișier de rulare care dispare la repornire vă spune că nu a fost niciodată sursa, iar acea singură observație redirecționează întreaga investigație. Explică și de ce o editare a părut reușită atunci.

Secrete și proprietate

Un profil poate face referire la un certificat sau o cheie stocate cu totul altundeva, iar o parolă poate aparține NetworkManager, poate fi furnizată de un agent secret al sesiunii de utilizator, sau poate să nu fie salvată în mod deliberat. Găsirea unui singur fișier lămurește deci foarte puțin despre ce va cere o pornire nesupravegheată.

Inspectați referințele și steagurile de secrete fără a afișa valori secrete. O autentificare pe desktop poate face disponibil un agent care lipsea la pornire, iar copierea unui fișier de rulare generat nu reproduce acel agent. Simptomul practic este un tunel care se conectează când o persoană se autentifică și eșuează când mașina pornește singură. Acest tipar indică proprietatea asupra secretelor, nu rutarea.

Faceți modificările aprobate prin managerul care deține conexiunea, apoi verificați atât identificatorul salvat, cât și conexiunea efectivă. Păstrați un singur proprietar persistent, pentru că editarea separat a importului, a unui keyfile generat și a unei surse YAML lasă trei explicații concurente despre ce va folosi următoarea reconectare. Alegeți-o pe cea care persistă cu adevărat, editați doar aceea și notați în tichet ce fișier ați tratat ca autoritar. Următoarea persoană vă va mulțumi pentru o linie de proveniență.