ConnMan VPN: o menu em falta é um daemon, não um protocolo

A crença é que um sistema ConnMan sem entrada VPN no ambiente de trabalho não tem qualquer suporte VPN instalado. Normalmente tem suporte para Wi-Fi e nenhum para o daemon VPN, a configuração do fornecedor ou o agente de autenticação, e essas são três ausências separadas. O menu é uma vista sobre esses componentes, não a funcionalidade em si. Verificar a versão e o empacotamento diz-lhe mais num único comando do que qualquer número de relatórios de erro do ambiente de trabalho.

O mito: o menu é a funcionalidade VPN

Comece pela versão instalada do ConnMan e pelos pacotes que a acompanharam. Um relatório de erro de uma versão mais antiga descreve outro conjunto de funcionalidades, e citá-lo costuma terminar com alguém a reinstalar um gestor de rede que não precisava de ser substituído.

Anote o que realmente tem antes de alterar seja o que for: o binário do daemon, o diretório de fornecedores e se existe um agente.

Que daemon é dono do túnel

Na documentação do ConnMan 1.41 para Debian bookworm, connman-vpnd é o daemon que gere as ligações VPN a par do connmand. Enumera integrações para assistentes VPN com nome, incluindo OpenVPN e OpenConnect. Essa lista é uma afirmação sobre os assistentes, não uma promessa de que todos os protocolos ou fluxos de autenticação funcionem. Leia-a como um menu do que verificar, não como uma garantia de compatibilidade.

Depois faça corresponder a integração ao protocolo aprovado do gateway. A palavra Cisco não lhe diz se precisa de uma ligação ao estilo vpnc antigo ou de um fluxo compatível com AnyConnect, e a escolha errada produz uma falha de autenticação que parece um problema de credenciais.

Se tanto um assistente autónomo como o ConnMan conseguem levantar o túnel, decida qual deles é dono das rotas, do DNS e do ciclo de vida antes de qualquer um arrancar.

As definições do daemon não são as definições do fornecedor

A configuração geral do daemon e a configuração de um fornecedor individual são ficheiros diferentes com formatos diferentes. Na disposição documentada do bookworm o daemon lê /etc/connman/connman-vpn.conf, enquanto os ficheiros de aprovisionamento dos fornecedores residem em /var/lib/connman-vpn/ com um sufixo .config. Colocar um perfil OpenVPN nesse diretório não o transforma num ficheiro de aprovisionamento do ConnMan. O manual do fornecedor para esta versão descreve as secções do fornecedor e os campos específicos do tipo de que esses ficheiros realmente precisam.

Traduza apenas através do mapeamento suportado da integração instalada. A confiança no certificado, as referências à chave privada, a identidade do gateway, as rotas e as entradas de autenticação mantêm cada uma o seu papel, e uma amostra para outro tipo de fornecedor não é intercambiável só porque ambos precisam de um endereço de servidor.

Quando um fornecedor não carrega, compare os seus campos com o manual da versão instalada em vez de com um exemplo de blogue.

O agente de autenticação é uma dependência separada

Uma definição de fornecedor ainda pode precisar de um agente para obter credenciais ou concluir uma troca de autenticação. Para a sua integração com OpenConnect, o mesmo manual explica que os valores relacionados com a autenticação em falta podem ser pedidos através da API do VPN Agent, e que um cookie de curta duração geralmente não serve como segredo permanente de configuração. Esse mecanismo não garante suporte para cada início de sessão no navegador, cada pedido MFA ou cada verificação de postura do gateway. Confirme o fluxo completo com quem é dono da implementação.

Não compense um agente ausente escrevendo uma palavra-passe ou um token de sessão num ficheiro amplamente legível. Isso transforma uma integração em falta numa exposição de credenciais, e o segundo problema sobrevive ao primeiro.

Se o gateway exigir um início de sessão interativo, o agente faz parte do desenho e não é um extra opcional.

Verifique quatro resultados, não um

Após um aprovisionamento autorizado, verifique quatro coisas em separado: o fornecedor está selecionado, a ligação foi autenticada, as rotas efetivas são as que pretendia e o resolver comporta-se como esperado. Um daemon em execução, um fornecedor listado e uma aplicação a alcançar o seu recurso são três resultados diferentes, e só o último é o objetivo real do utilizador. Registá-los em separado diz-lhe que etapa corrigir.

Inclua nessa verificação o comportamento de religação e a política de estado indisponível exigida, porque um túnel que sobe uma vez e nunca recupera não está implantado. Mantenha recuperável a configuração de rede base que funciona enquanto altera a integração VPN.

Substituir o gestor de Wi-Fi para obter um botão é uma alteração muito maior do que a operação em falta que era necessária, e normalmente é o mito a ganhar.