Keyfile o Netplan: on es guarda realment el perfil de VPN?

Trobar el fitxer que heu importat és la part fàcil i sovint el començament equivocat. L’important és quin fitxer llegeix avui el NetworkManager com a connexió desada, i això depèn d’un identificador de connexió i del backend de configuració que els paquets instal·lats utilitzen realment. Editar la importació abans de respondre aquesta pregunta és com una VPN que funciona es converteix en dues configuracions mig correctes.

El fitxer importat no és el perfil desat

Tres noms volen al voltant de cada problema de VPN: el nom de la connexió, el nom del fitxer que heu importat i la interfície virtual que apareix quan el túnel s’aixeca. Cap d’ells identifica la configuració desada, i el nom d’una connexió es pot editar mentre el fitxer del darrere conserva el seu identificador original.

Comenceu amb un inventari només de lectura i trieu la VPN volguda per identificador en lloc d’etiqueta:

nmcli -f NAME,UUID,TYPE connection show

Deixeu els noms d’amfitrió dels extrems i les etiquetes d’identitat fora de qualsevol inventari que enganxeu en un tiquet. La part útil és el tipus i l’identificador; la resta és context que un desconegut no necessita. Redacteu la resta abans de compartir-ho i digueu que ho heu fet, perquè ningú no es pregunti què signifiquen els espais en blanc.

Les ubicacions del keyfile no signifiquen el mateix

Amb el connector keyfile natiu, els fitxers de connexió poden aparèixer en tres directoris, i la diferència entre ells és la persistència, no la comoditat.

Editar la còpia d’execució sembla exitós fins al proper inici, moment en què el canvi s’evapora i el fitxer sembla revertit misteriosament. Editar la còpia que subministra el paquet funciona fins que una actualització la substitueix, que és una versió més lenta i confusa de la mateixa lliçó.

La documentació del keyfile afegeix un detall que val la pena respectar: aquests fitxers poden contenir claus privades i contrasenyes, i el NetworkManager ignora qualsevol keyfile que usuaris diferents de root puguin llegir o escriure. Ampliar els permisos del directori per buscar un paràmetre trenca el comportament de càrrega que volíeu inspeccionar.

Quan el Netplan posseeix la persistència

A Ubuntu, la integració del NetworkManager descrita a la documentació del Netplan, disponible des de la 23.10, canvia on viu la còpia duradora. Per a les connexions no temporals escriu /etc/netplan/90-NM-<connection UUID>.yaml i genera un perfil efímer del NetworkManager sota /run/NetworkManager/system-connections/.

Això és una integració de distribució, no una regla per a cada instal·lació del NetworkManager. Confirmeu que els paquets instal·lats realment la utilitzen abans d’anar a buscar un fitxer YAML. Recordeu també que un perfil d’execució pot ser una representació generada d’una altra cosa en lloc de la font que val la pena editar. Dues ordres de comprovació estalvien una hora d’editar el fitxer equivocat.

L’exemple documentat desa una connexió OpenVPN a través del tipus Netplan nm-devices amb dades de pas del NetworkManager. El fet que el Netplan no tingui una interpretació dedicada d’un camp VPN concret no vol dir que la vostra VPN desada s’hagi perdut; vol dir que el camp viatja com a dades opaques.

Les interfícies transitòries no són perfils

L’activació crea connexions i interfícies virtuals temporals que mai havien de persistir. La integració deliberadament no escriu un fitxer YAML nou per a cadascuna, així que la seva absència a /etc/netplan no diu res sobre si el perfil pare s’ha desat.

Si perseguiu un fitxer que apareix i desapareix, probablement esteu mirant un d’aquests i no la vostra configuració. Comproveu si sobreviu a un reinici abans de treure cap conclusió del seu contingut. Un fitxer d’execució que desapareix en reiniciar us diu que mai no va ser la font, i aquesta sola observació redirigeix tota la investigació. També explica per què una edició va semblar exitosa en aquell moment.

Secrets i propietat

Un perfil pot referenciar un certificat o una clau desats en un altre lloc, i una contrasenya pot pertànyer al NetworkManager, ser subministrada per un agent secret de la sessió d’usuari, o bé no desar-se deliberadament. Per tant, localitzar un sol fitxer resol ben poc sobre què exigirà una arrencada sense supervisió.

Inspeccioneu les referències i els indicadors de secrets sense imprimir valors secrets. Un inici de sessió d’escriptori pot fer disponible un agent que no hi era durant l’arrencada, i copiar un fitxer d’execució generat no reprodueix aquell agent. El símptoma pràctic és un túnel que connecta quan una persona inicia sessió i falla quan la màquina arrenca sola. Aquest patró apunta a la propietat dels secrets, no a l’encaminament.

Feu els canvis aprovats a través del gestor que posseeix la connexió, i després verifiqueu tant l’identificador desat com la connexió efectiva. Manteniu un sol propietari persistent, perquè editar la importació, un keyfile generat i una font YAML per separat deixa tres explicacions competidores de què farà servir la propera reconnexió. Trieu la que realment persisteix, editeu només aquella i anoteu al tiquet quin fitxer heu tractat com a autoritatiu. La propera persona us agrairà una línia de procedència.