Lista de VPN con nmcli: perfiles guardados frente a túneles activos
Una lista es lo que la máquina guardó, la otra es lo que está conectado. La VPN que quiere puede estar tipada como wireguard o no ser una conexión de NetworkManager en absoluto.
Ejecuta nmcli connection show esperando una lista de VPN y recibe todas las conexiones que la máquina ha guardado alguna vez, incluidos un puente y un punto de acceso. La VPN que busca puede estar ahí, puede estar tipada como algo distinto de vpn o puede no ser una conexión de NetworkManager en absoluto. Saber en cuál de esos tres casos está requiere dos comandos.
Dos listas, dos preguntas
connection show responde qué ha guardado NetworkManager, y connection show --active responde qué está conectado ahora a un dispositivo. La primera lista incluye perfiles inactivos, y eso es deliberado: una VPN guardada que está caída sigue siendo un perfil que quizá tenga que arreglar. Confundir las dos da la impresión de que un túnel funciona cuando solo existe su configuración.
Elija campos en lugar de leer la tabla predeterminada, porque la salida predeterminada oculta el tipo en terminales estrechos y parte los nombres largos.
NAME, UUID y TYPE suelen ser todo lo necesario para una primera pasada, y luego inspecciona la única entrada que le interesa por UUID.
TYPE es donde están las sorpresas
OpenVPN las conexiones gestionadas por el complemento aparecen como tipo vpn, porque el complemento es un servicio dentro del marco genérico de VPN. El soporte nativo de WireGuard es un tipo de conexión propio y de primera clase, así que filtrar por vpn no lo encontrará. Una búsqueda de un túnel WireGuard que no devuelve nada suele ser un problema de filtro y no un perfil ausente. Eso es una diferencia arquitectónica, no una rareza de nomenclatura.
Lo mismo se aplica a otros tipos de túnel que NetworkManager aprendió a manejar de forma nativa con el tiempo, así que lea la columna TYPE antes de concluir que algo falta.
Liste todo y filtre después, y el perfil aparece.
Lea el UUID, no solo el nombre
Los nombres son etiquetas que la gente edita, y dos perfiles pueden compartir uno tras una importación descuidada. El UUID es la identidad a la que se refieren los comandos y los archivos. Cuando una entrada parece duplicada, compare el UUID y la configuración subyacente antes de borrar nada.
Los comandos de activación aceptan cualquiera de los dos, y por eso mismo una costumbre basada en el nombre acaba modificando el perfil equivocado.
Copie el UUID en sus notas cuando cambie algo que quizá tenga que deshacer.
Lo que un perfil guardado no le dice
Un perfil guardado no dice nada sobre si su túnel está levantado, y una conexión activa no dice nada sobre si el tráfico que hay dentro funciona. Un túnel iniciado por wg-quick o por una unidad de servicio no es ninguna conexión de NetworkManager, así que falta en ambas listas mientras la interfaz claramente pasa tráfico. Compruebe la interfaz y la tabla de rutas antes de suponer que el perfil falta. Una lista vacía solo demuestra que NetworkManager no es el propietario.
Dos gestores para la misma interfaz es la otra versión de este problema, y produce una lista que parece correcta mientras el estado del núcleo lo posee otra cosa.
Un propietario por interfaz mantiene la lista honesta, y la referencia de nmcli documenta qué campos informa realmente cada vista.
Informe sin filtrar secretos
connection show con un nombre imprime ajustes, y añadir --show-secrets imprime las claves privadas y las contraseñas junto con ellos. Para pegar un diagnóstico en un ticket no hacen falta. Informe en su lugar del tipo, el UUID, el estado y las rutas relevantes, y redacte todo lo que venga de un almacén de secretos.
La activación interactiva con --ask es la forma admitida de aportar una credencial que falta, y la automatización sin supervisión necesita otro acuerdo aprobado en lugar de una contraseña guardada en texto plano.
Un informe breve y redactado es más fácil de revisar que un volcado completo.