Lista de VPN com nmcli: perfis salvos vs. túneis ativos

Você executa nmcli connection show esperando uma lista de VPNs e recebe todas as conexões que a máquina já salvou, incluindo uma bridge e um hotspot. A VPN que você procura pode estar lá, pode estar tipada como algo diferente de vpn ou pode não ser uma conexão do NetworkManager de forma alguma. Saber em qual desses três casos você está exige dois comandos.

Duas listas, duas perguntas

connection show responde o que o NetworkManager salvou, e connection show --active responde o que está ligado a um dispositivo no momento. A primeira lista inclui perfis inativos, e isso é deliberado: uma VPN salva que está parada continua sendo um perfil que talvez você precise corrigir. Confundir as duas cria a impressão de que um túnel está rodando quando só a configuração existe.

Escolha campos em vez de ler a tabela padrão, porque a saída padrão esconde o tipo em terminais estreitos e quebra nomes longos.

NAME, UUID e TYPE costumam ser tudo o que você precisa numa primeira passada, e depois você inspeciona a única entrada que lhe interessa pela UUID.

TYPE é onde estão as surpresas

OpenVPN as conexões gerenciadas pelo plugin aparecem como tipo vpn, porque o plugin é um serviço dentro da estrutura genérica de VPN. O suporte nativo ao WireGuard é um tipo de conexão próprio e de primeira classe, então filtrar por vpn não o encontrará. Uma busca por um túnel WireGuard que não retorna nada costuma ser um problema de filtro e não um perfil ausente. Isso é uma diferença arquitetural, não uma esquisitice de nomenclatura.

O mesmo vale para outros tipos de túnel que o NetworkManager aprendeu a tratar nativamente com o tempo, então leia a coluna TYPE antes de concluir que algo falta.

Liste tudo e filtre depois, e o perfil aparece.

Leia a UUID, não apenas o nome

Nomes são rótulos que as pessoas editam, e dois perfis podem compartilhar um após uma importação descuidada. A UUID é a identidade a que comandos e arquivos se referem. Quando uma entrada parece duplicada, compare a UUID e as configurações subjacentes antes de apagar qualquer coisa.

Os comandos de ativação aceitam qualquer um dos dois, e é exatamente por isso que um hábito baseado em nome acaba modificando o perfil errado.

Copie a UUID para suas notas quando alterar algo que talvez precise desfazer.

O que um perfil salvo não lhe diz

Um perfil salvo não diz nada sobre se o túnel dele está no ar, e uma conexão ativa não diz nada sobre se o tráfego dentro dela funciona. Um túnel iniciado pelo wg-quick ou por uma unidade de serviço não é nenhuma conexão do NetworkManager, então ele falta nas duas listas enquanto a interface claramente passa tráfego. Verifique a interface e a tabela de rotas antes de supor que o perfil está ausente. Uma lista vazia prova apenas que o NetworkManager não é o dono.

Dois gerentes para a mesma interface é a outra versão deste problema, e produz uma lista que parece certa enquanto o estado do kernel pertence a outra coisa.

Um dono por interface mantém a lista honesta, e a referência do nmcli documenta quais campos cada visão realmente relata.

Relate sem vazar segredos

connection show com um nome imprime configurações, e adicionar --show-secrets imprime as chaves privadas e as senhas junto com elas. Para colar um diagnóstico em um ticket isso não é necessário. Relate o tipo, a UUID, o estado e as rotas relevantes em vez disso, e oculte tudo o que veio de um armazenamento de segredos.

A ativação interativa com --ask é a forma suportada de fornecer uma credencial ausente, e a automação sem supervisão precisa de outro arranjo aprovado em vez de uma senha salva em texto simples.

Um relatório curto e ocultado é mais fácil de revisar do que um despejo completo.