OpenConnect vpnc-script: qual arquivo está em execução?

O OpenConnect pode concluir o handshake do túnel e ainda assim deixá-lo sem rota para a sub-rede privada, porque o cliente e o auxiliar que altera o estado da rede local são dois programas diferentes. A autenticação prova que o gateway aceitou a sessão; não prova nada sobre qual interface, quais rotas ou quais configurações de resolver foram instaladas depois. A maioria dos relatos confusos vem de substituir o auxiliar por uma cópia de uma resposta antiga, o que muda o comportamento de cada conexão na máquina. Encontre o auxiliar que o cliente em execução realmente chama antes de alterar qualquer parte dele.

Dois programas, duas responsabilidades

O cliente possui o transporte, a autenticação e o dispositivo do túnel. Um auxiliar separado possui o que acontece no sistema local depois que o túnel existe: o endereçamento na interface, as rotas para as sub-redes anunciadas pelo gateway e a configuração do resolver. A documentação do auxiliar do OpenConnect descreve essa separação e o ambiente que o auxiliar recebe. A distinção importa durante uma falha, porque uma senha recusada e uma rota ausente não são o mesmo incidente mesmo quando a área de trabalho mostra uma única caixa de diálogo para os dois.

Ter essa separação em mente também explica por que uma conexão pode relatar sucesso enquanto os nomes privados continuam sem resolver. O túnel está ativo nos dois casos, e só a etapa de integração local difere.

Encontre o auxiliar usado pelo cliente em execução

O caminho é definido quando o pacote é compilado e pode ser substituído a cada invocação, então o arquivo que você lembra de outra distribuição talvez não tenha nada a ver com esta conexão. Pergunte ao processo em execução, não à documentação que estiver aberta por acaso.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Se a linha do processo trouxer um --script argumento, esse arquivo prevalece sobre o padrão compilado. Caminhos mais antigos como /etc/vpnc/vpnc-script podem existir e continuar sem uso, e por isso apagá-los ou editá-los não muda nada em uma compilação recente. Verifique também a data de modificação, porque um auxiliar que ninguém tocou por anos é um sinal forte de que o padrão empacotado faz o trabalho.

A integração com o NetworkManager é um terceiro proprietário, com auxiliar próprio e configurações de perfil próprias. Empilhar um segundo script de rotas ou de resolver sobre essa integração duplica rotas e deixa um resolver que dois programas afirmam administrar. Escolha um único proprietário por conexão e desative o outro antes de testar.

Leia a primeira operação que falhou, não o último aviso

A configuração da interface, a instalação de rotas, a escolha do resolver e a limpeza do estado obsoleto são etapas separadas, e o aviso impresso por último costuma ser uma queixa de limpeza e não a falha que quebrou a conexão. Leia para cima até a primeira operação concreta que falhou. Um erro do auxiliar que nomeia um arquivo ou um endereço vale mais que dez linhas de ruído de desmontagem.

Compare o resultado local pretendido com o observado: o dispositivo do túnel existe, uma rota para um endereço privado conhecido passa por ele e o resolver responde por um nome privado. Um auxiliar que acerta os dois primeiros e falha no terceiro aponta para a política do resolver e não para o roteamento. Um auxiliar que não configura o dispositivo de forma alguma provavelmente nunca foi executado, e isso é uma questão de permissões e não de rede. Confirme o bit de execução e a conta de serviço antes de reescrever qualquer lógica.

Verifique conexão, reconexão e desconexão

A configuração é só metade do contrato, porque o mesmo auxiliar precisa restaurar ou remover o estado que possui quando o túnel fecha. Um auxiliar que adiciona rotas e nunca as remove deixa a máquina com um caminho obsoleto que sobrevive à sessão.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Execute as três primeiras enquanto estiver conectado, desconecte e execute-as de novo e confirme que a rota e a entrada do resolver desapareceram. A quarta linha mostra se o auxiliar foi invocado e qual caminho executável o serviço usou. Guarde esse par de saídas no chamado, porque é o antes e depois que torna um bug de limpeza evidente.

Mantenha o auxiliar empacotado e executável pela conta de serviço, porque um script que roda no seu shell ainda pode ser negado sob uma política de serviço restrita. Quando uma personalização for realmente necessária, documente o objetivo e o proprietário e compare-a com a versão empacotada a cada atualização. Um fork inexplicado de um auxiliar é uma das poucas coisas que podem fazer uma conexão que funcionava falhar um ano depois.