nmcli pide o contrasinal VPN unha e outra vez: garda o segredo localmente

O mesmo perfil, dúas sesións: conéctase desde o escritorio e colga por SSH nunha petición que nada pode responder. Nada está roto e non se perdeu ningún axuste. NetworkManager pide a credencial a un axente de segredos, e un axente de segredos é un compoñente de escritorio que non existe na sesión que estás a usar.

Executa a secuencia de abaixo e o túnel levantarase sen interfaz gráfica, coa advertencia de que gardar un segredo cambia quen pode usar ese perfil.

Confirma o diagnóstico antes de tocar nada

A diferenza entre a activación interactiva e a non interactiva é todo o diagnóstico. Se nmcli --ask connection up ten éxito mentres unha activación normal se atasca, o perfil é correcto e falta a orixe do segredo. Esa única comparación aforra che reescribir unha configuración que funciona.

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

Le as opcións en vez de adiviñalas. Os valores que significan "pregunta a un axente" son o que buscas, e os nomes exactos das chaves varían entre complementos de VPN porque viven no dicionario de datos propio do complemento. Un perfil FortiSSL e un perfil IPsec non usan necesariamente os mesmos nomes, así que parte da saída do teu propio perfil.

Comproba tamén que o paquete do complemento para ese protocolo estea instalado. Un complemento ausente aparece como un tipo de conexión descoñecido ou como un erro de activación que non di nada sobre contrasinais, e perseguir o segredo nese estado desperdicia a mesma hora dúas veces. Unha consulta de paquetes é máis barata ca unha tarde enteira editando ficheiros de chaves.

Move o segredo ao ficheiro de chaves

O ficheiro de conexión vive en /etc/NetworkManager/system-connections/. Os segredos non se gardan aí por defecto, e ese é o sentido das opcións que acabas de ler. Cambiar unha opción a cero dille a NetworkManager que o valor se garda co perfil en vez de pedirse no momento da activación.

[vpn]
password-flags=0

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

Para un perfil con dous segredos, o patrón repítese: unha opción por segredo na sección [vpn], e os valores en [vpn-secrets]. Un perfil IPsec adoita levar unha chave precompartida xunto coa credencial de usuario, e o complemento nomeaos de forma distinta a un campo de contrasinal normal, así que copia os nomes das chaves da saída de vpn.data en vez dun artigo de blog que usase outro complemento. Un só nome de chave equivocado produce un perfil que carga e despois falla na autenticación, o que se le exactamente como un contrasinal incorrecto. Compara o teu ficheiro cun perfil que funcione do mesmo complemento antes de volver conectarte.

Pon entre comiñas os valores que conteñan espazos, comiñas ou un signo de dólar. Un valor sen comiñas cun $ dentro lerase literalmente ou expandirase segundo onde se analice, e o fallo de autenticación resultante parece un contrasinal incorrecto.

Despois corrixe a propiedade e o modo do ficheiro. Estes ficheiros de chaves léxeos un servizo privilexiado, e un ficheiro que outros usuarios poden ler trátase como pouco fiable, que é a razón habitual pola que un perfil editado parece ignorarse. Propietario root, modo 600, sen excepcións.

Recarga e despois activa

O ficheiro lese cando se carga a conexión, así que editalo non abonda. Recarga os perfís e despois levanta a conexión explicitamente.

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

Se a recarga non recolle o cambio, un reinicio completo do servizo si o fai, e hai informes de exactamente iso. Prefire a recarga cando importan outros enlaces, porque reiniciar o servizo corta todas as conexións xestionadas, e nun host remoto iso pode rematar a túa sesión antes de que o túnel que querías estea levantado.

Usa o UUID cando os nomes son ambiguos. As máquinas con varios perfís de clientes acumulan case duplicados, e activar o equivocado produce un fallo que parece un problema de credenciais.

Cando o segredo gardado non é o problema

Un perfil FortiSSL pode fallar mesmo cunha credencial gardada correcta porque o cliente nunca confía no certificado da pasarela. Ese axuste non está no diálogo principal; está detrás das opcións avanzadas da VPN, onde se introduce o resumo do certificado de confianza. Se o rexistro menciona o certificado en vez do contrasinal, estás nesta rama e ningunha cantidade de edición de [vpn-secrets] axudará.

Aquí corresponden dúas comprobacións máis. Confirma que o perfil non se importou desde un ficheiro que aínda apunta a unha ruta que o complemento non pode ler, e confirma que o perfil é o activo e non un duplicado obsoleto. Ambos producen fallos de activación que se len como erros de autenticación.

Decide se gardar é aceptable

Unha PSK e un contrasinal gardados son lexibles por calquera cousa que se execute como root nesa máquina. Nunha máquina que controlas, é un intercambio razoable para un servizo sen interfaz. Nun host compartido merece unha conversa, porque o perfil agora contén unha credencial que antes protexía o chaveiro do escritorio. Pregunta quen máis pode chegar a root nese host antes de decidir, non despois de que o cambio estea feito.

Se a política prohibe gardar segredos de VPN, non debilites o perfil para facer funcionar unha tarefa de cron. Executa a conexión desde unha sesión que teña un axente, ou usa outro mecanismo para a automatización.

Por último, anota que perfís levan segredos para que ninguén copie un a un portátil sen decatarse. Un comentario encima da sección de segredos coa data e o motivo abonda, e aforrará a alguén unha revisión incómoda máis adiante.