nmcli demana la contrasenya VPN una vegada i una altra: deseu el secret localment

El mateix perfil, dues sessions: es connecta des de l'escriptori i s'encalla per SSH en una petició que res no pot respondre. No hi ha res trencat i no s'ha perdut cap paràmetre. NetworkManager demana la credencial a un agent de secrets, i un agent de secrets és un component d'escriptori que no existeix a la sessió que feu servir.

Executeu la seqüència següent i el túnel s'aixecarà sense interfície gràfica, amb l'advertiment que desar un secret canvia qui pot utilitzar aquest perfil.

Confirmeu el diagnòstic abans de tocar res

La diferència entre l'activació interactiva i la no interactiva és tot el diagnòstic. Si nmcli --ask connection up funciona mentre una activació normal s'encalla, el perfil és correcte i l'origen del secret falta. Aquesta única comparació us estalvia reescriure una configuració que funciona.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Llegiu les opcions en lloc d'endevinar-les. Els valors que volen dir "pregunta a un agent" són el que busqueu, i els noms exactes de les claus varien entre connectors VPN perquè viuen al diccionari de dades propi del connector. Un perfil FortiSSL i un perfil IPsec no utilitzen necessàriament els mateixos noms, així que partiu de la sortida del vostre propi perfil.

Comproveu també que el paquet del connector per a aquest protocol estigui instal·lat. Un connector que falta apareix com un tipus de connexió desconegut o com un error d'activació que no diu res sobre contrasenyes, i perseguir el secret en aquest estat fa perdre la mateixa hora dues vegades. Una consulta de paquets és més barata que tota una tarda editant fitxers de claus.

Moveu el secret al fitxer de claus

El fitxer de connexió viu a /etc/NetworkManager/system-connections/. Els secrets no s'hi guarden per defecte, i aquest és el sentit de les opcions que acabeu de llegir. Canviar una opció a zero diu a NetworkManager que el valor es desa amb el perfil en lloc de demanar-se en el moment de l'activació.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

Per a un perfil amb dos secrets, el patró es repeteix: una opció per secret a la secció [vpn], i els valors a [vpn-secrets]. Un perfil IPsec normalment porta una clau prèviament compartida al costat de la credencial d'usuari, i el connector els dona noms diferents d'un camp de contrasenya normal, així que copieu els noms de les claus de la sortida de vpn.data en lloc d'un article de blog que feia servir un altre connector. Un sol nom de clau equivocat produeix un perfil que es carrega i després falla a l'autenticació, cosa que es llegeix exactament com una contrasenya incorrecta. Compareu el vostre fitxer amb un perfil que funcioni del mateix connector abans de tornar-vos a connectar.

Poseu entre cometes els valors que continguin espais, cometes o un signe de dòlar. Un valor sense cometes amb un $ a dins es llegirà literalment o s'expandirà segons on es parsegi, i la fallada d'autenticació resultant sembla una contrasenya incorrecta.

Després arregleu la propietat i el mode del fitxer. Aquests fitxers de claus els llegeix un servei privilegiat, i un fitxer que altres usuaris poden llegir es tracta com a no fiable, que és el motiu habitual pel qual un perfil editat sembla ignorat. Propietari root, mode 600, sense excepcions.

Recarregueu, i després activeu

El fitxer es llegeix quan es carrega la connexió, així que editar-lo no n'hi ha prou. Recarregueu els perfils i després aixequueu la connexió explícitament.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Si la recàrrega no recull el canvi, un reinici complet del servei sí que ho fa, i hi ha informes exactament d'això. Preferiu la recàrrega quan altres enllaços importen, perquè reiniciar el servei fa caure totes les connexions gestionades, i en un amfitrió remot això pot acabar la vostra sessió abans que el túnel que volíeu estigui aixecat.

Feu servir l'UUID quan els noms són ambigus. Les màquines amb diversos perfils de clients acumulen gairebé duplicats, i activar el equivocat produeix una fallada que sembla un problema de credencials.

Quan el secret desat no és el problema

Un perfil FortiSSL pot fallar fins i tot amb una credencial desada correcta perquè el client mai no confia en el certificat de la passarel·la. Aquest paràmetre no és al diàleg principal; és darrere de les opcions avançades de la VPN, on s'introdueix el resum del certificat de confiança. Si el registre esmenta el certificat en lloc de la contrasenya, sou en aquesta branca i cap quantitat d'edició de [vpn-secrets] no ajudarà.

Hi ha dues comprovacions més que pertanyen aquí. Confirmeu que el perfil no es va importar d'un fitxer que encara apunta a un camí que el connector no pot llegir, i confirmeu que el perfil és l'actiu i no un duplicat obsolet. Totes dues produeixen fallades d'activació que es llegeixen com a errors d'autenticació.

Decidiu si desar és acceptable

Una PSK i una contrasenya desades són llegibles per qualsevol cosa que s'executi com a root en aquella màquina. En una màquina que controleu, és un intercanvi raonable per a un servei sense interfície. En un amfitrió compartit, mereix una conversa, perquè el perfil ara conté una credencial que abans protegia l'anell de claus de l'escriptori. Pregunteu qui més pot arribar a root en aquell amfitrió abans de decidir, no després que el canvi estigui fet.

Si la política prohibeix desar secrets VPN, no afebliu el perfil per fer funcionar una tasca de cron. Executeu la connexió des d'una sessió que tingui un agent, o feu servir un altre mecanisme per a l'automatització.

Finalment, anoteu quins perfils porten secrets perquè ningú no en copiï un a un portàtil sense adonar-se'n. Un comentari a sobre de la secció de secrets amb la data i el motiu n'hi ha prou, i estalviarà a algú una revisió incòmoda més endavant.