openvpn3 session-start ignora el vostre fitxer de credencials

Connecteu-vos amb el client 2.x i el perfil funciona; doneu el mateix fitxer al client 3.x i s’atura en una petició de contrasenya. Passeu --auth-user-pass creds.txt a openvpn3 session-start i el resultat és el mateix, perquè el client més nou no té cap etapa que llegeixi el fitxer. La negativa és deliberada: les credencials pertanyen a una sessió, i una sessió la crea un servei, no el procés del vostre terminal. Trieu entre la petició interactiva i l’auxiliar de càrrega automàtica, i sapigueu què desa cadascun.

Per què el fitxer desat no té on anar

En el disseny més nou, la gestió de la configuració i la gestió de sessions són serveis separats que parlen pel bus del sistema. Aquesta separació és el que permet a un usuari ordinari iniciar una sessió sense que un dimoni amb privilegis llegeixi en el seu nom un fitxer de contrasenyes protegit. Les credencials basades en fitxers no tenen lloc en aquest model, perquè no hi ha cap arrencada del costat del dimoni que les llegiria. La negativa és una conseqüència de l’arquitectura, no una funcionalitat que falti.

Val la pena posar nom al patró antic perquè sigui més fàcil desaprendre’l: un perfil fa referència a un fitxer de credencials, i el dimoni el llegeix quan arrenca el túnel. En el model nou, les credencials pertanyen a una sessió i es forneixen quan aquesta sessió comença. openvpn3 session-start --config work.ovpn les demana, i --auth-user-pass creds.txt es rebutja perquè res en aquest camí obriria el fitxer. Cada recepta per al 2.x que trobeu pressuposa una etapa que ja no existeix.

La configuració i els paràmetres locals del lloc també estan separats, cosa que explica una segona sorpresa. Un perfil pot semblar complet mentre la connexió que produeix no té configuració d’encaminament ni de resolució. Aquestes peces s’apliquen com a paràmetres locals del lloc, per separat del fitxer importat.

El camí de la petició i la sessió que deixa

Proporcionar la contrasenya quan comença la sessió és el flux de treball previst. El client demana una vegada, lliura les credencials al rerefons de la sessió i continua:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Per aquest camí no s’escriu res al disc. La sessió continua funcionant després que es tanqui el terminal, cosa que sorprèn qui espera que el procés mori amb la seva shell. Aquest és precisament el sentit de traslladar la gestió de sessions a un servei. La sessió sobreviu al terminal que l’ha demanada i s’ha d’aturar explícitament.

Per a una estació de treball amb una persona al davant, aquesta és també l’opció més segura, perquè no hi ha cap secret desat que calgui protegir o oblidar. Només és inadequada on no hi ha ningú per escriure.

Automatització sense ningú al teclat

On una màquina s’ha de connectar sense una persona, el projecte inclou openvpn3-autoload. Llegeix un directori de perfils i un descriptor corresponent per a cada perfil, i el descriptor forneix les credencials en text pla. L’auxiliar és un binari a part, normalment a /usr/sbin/openvpn3-autoload, no una opció de session-start. Configurar-lo vol dir crear el directori, copiar el perfil amb el nom que el descriptor espera i escriure el descriptor.

Una configuració per usuari té aquest aspecte i s’executa amb el compte que posseirà la sessió. El mode del directori manté fora els altres usuaris locals:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

El descriptor anomena les credencials i demana un inici automàtic. Manteniu el valor de la contrasenya fora del control de versions:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

A continuació invoqueu l’auxiliar una vegada i confirmeu que la sessió apareix. La segona ordre és la comprovació, no un altre pas de configuració:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

En arrencar, una unitat empaquetada anomenada openvpn3-autoload.service fa servir el directori de tot el sistema /etc/openvpn3/autoload, no el de cada usuari. Aquell lloc necessita propietat de root i un mode més estricte, i el descriptor encara conté la contrasenya en text clar. El compromís és explícit: la contrasenya ara és al disc, així que tracteu aquell directori com un secret, excloeu-lo de les còpies de seguretat fora de l’amfitrió i trieu el camí interactiu sempre que hi hagi una persona.

Fallades del bus que semblen fallades de contrasenya

Algunes fallades atribuïdes a les credencials no ho són de cap manera. Un error de permisos que anomena el camí d’activació del servei vol dir una de dues coses: el rerefons no està en marxa, o qui crida no té permís per activar-lo. Cap edició del perfil no canviarà ni l’una ni l’altra. Comproveu l’estat del servei i la política de bus que s’inclou abans de tocar la configuració.

Les ordres següents separen les dues coses. La primera informa si el rerefons s’està executant; la segona mostra errors de bus recents:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

L’altra lectura errònia freqüent és una sessió que apareix i desapareix de cop. Aquest patró normalment vol dir que els paràmetres locals del lloc no es van aplicar mai, així que el túnel va pujar sense els canvis d’encaminament i de resolució que el fan útil. Llegiu la seqüència i no l’última línia: si la sessió es va crear, si va arribar a un estat connectat i si va sobreviure són tres fets separats.

Quan el client antic encara s’utilitza

El client 2.x encara accepta un fitxer de credencials, i un clauer pot respondre a la seva petició sense que el secret arribi mai al disc. Un embolcall resol l’entrada, així que el fitxer anomena la consulta i no la contrasenya. Aquest arranjament depèn d’un clauer desbloquejat, cosa que un contenidor sense sessió d’inici o una unitat que arrenca abans que ningú iniciï sessió no poden oferir. L’eina de consulta informa llavors d’una col·lecció on no pot escriure, així que l’error sembla una fallada de credencials quan és una fallada del clauer.

Abans de construir res d’això, comproveu si un paràmetre keepalive del perfil elimina del tot la necessitat de reiniciar. Una sessió que es manté no arriba mai a la petició que intenteu automatitzar.