O AnyConnect cai quando fecha um terminal: verificações de sessão

O túnel está ativo, fecha um terminal extra e a VPN cai sem uma única tecla no cliente. No cliente AnyConnect para Linux a causa indicada é a contabilização de sessões e não o encaminhamento: o cliente registra quais sessões de início de sessão existiam quando o túnel subiu e trata o fim de qualquer uma delas como motivo para derrubá-lo. As verificações abaixo correm por ordem, e a primeira que falhar diz se está mesmo diante deste comportamento. Nada na saída habitual do cliente menciona um terminal, e é por isso que o primeiro impulso, culpar o concentrador, costuma ser esforço perdido.

Não comece por editar ficheiros do sistema. Cada passo ou explica a queda ou elimina um candidato, e os passos baratos vêm primeiro.

Separar uma queda de sessão de uma queda da camada inferior

Volte a ligar imediatamente após a desconexão. Um túnel que regressa em segundos, na mesma rede e sem novas credenciais, aponta para um gatilho local, como uma sessão fechada, e não para um uplink morto, roaming Wi-Fi ou um tempo limite de inatividade no concentrador. Um túnel que fica pendurado em Connecting, ou que só falha até mudar de rede, é outro artigo.

Anote o que estava aberto quando o túnel subiu: o terminal a partir do qual executou o cliente, qualquer segunda shell, o início de sessão gráfico e qualquer sessão SSH de outra máquina. Vai precisar dessa lista dentro de instantes, e reconstruí-la de memória após a próxima queda não é fiável.

Verificar o que o cliente registou no momento da ligação

O cliente não inspeciona processos progenitores nem a propriedade do terminal. Tira uma fotografia do conjunto de sessões de início de sessão presentes no momento da ligação e compara esse conjunto mais tarde; quando um membro desaparece, a comparação falha e o túnel vai com ele. É por isso que fechar a janela a partir da qual se ligou pode ser inofensivo, enquanto fechar um terminal extra sem relação mata a ligação: o que importa é se essa sessão estava no conjunto original. É uma comparação de conjuntos, não uma contagem, e por isso substituir uma sessão pode ser tão fatal como perder uma.

Liste o que o cliente podia ver antes de alterar seja o que for:

who
w
last -n 10
sudo ls -l /run/utmp

Cada linha de who é um registo de processo de utilizador em utmp. Se a sua sessão aparece duas vezes, uma para o início de sessão gráfico e outra para o terminal, ambos os registos existiam no momento da ligação e ambos são candidatos.

Remover apenas o seu próprio registo do utmp

A solução publicada torna invisível no utmp a sessão que vai usar, antes de o cliente arrancar. Um pequeno programa em C percorre getutent(), encontra o registo cujo ut_line é igual ao TTY da entrada padrão e reescreve esse registo. A ordem é deliberada: setutent(), ler o registo, copiar o seu ut_id, definir ut_type como DEAD_PROCESS, limpar os campos de utilizador e de linha, reescrevê-lo com pututline() e depois endutent().

Compile-o e depois execute-o como root a partir da shell que vai iniciar o cliente:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Dois modos de falha explicam a maioria dos relatos de que a ferramenta não faz nada. Atua sobre o TTY ligado à entrada padrão, por isso executá-la a partir de um script ou de uma tarefa cron sem terminal não deixa nada para corresponder. E /run/utmp não é gravável por utilizadores comuns, por isso uma execução sem root falha em silêncio, a menos que verifique o estado de saída.

Confirmar que o túnel sobrevive ao fecho

Teste o mecanismo em vez de o assumir. Ligue-se a partir de uma sessão que pretende manter, abra um segundo terminal, feche o segundo e confirme com vpn state e uma vista da lista de interfaces que o túnel continua ativo. Se o túnel sobreviver, o gatilho era um tipo específico de sessão e não todas, e encontrou a sessão que tem de ficar aberta.

Se continuar a cair, a sessão vigiada estava noutro lugar, muitas vezes o início de sessão gráfico que criou o seu terminal, e retirar um registo TTY não ajuda. Repita a observação com a lista completa do primeiro passo em vez de acrescentar mais cirurgia.

Quando reescrever o utmp é a resposta errada

O utmp é contabilidade partilhada, não uma tabela privada. Reescrever o registo de uma sessão ainda viva faz com que who, w e algumas ferramentas de auditoria a reportem a menos, e um programa que mais tarde feche esse mesmo registo pode falhar por completo. Mantenha a ferramenta limitada à sua própria sessão, guarde uma cópia do ficheiro original e não a transforme num serviço de arranque que remove todos os registos.

Se o seu site recolhe contabilidade de sessões para conformidade, a solução entra em conflito com esse requisito e a resposta suportada é uma versão do cliente ou outro método de acesso, não um utmp corrigido. Para a maioria das pessoas, a correção menos invasiva é simplesmente iniciar o cliente a partir de uma sessão que fique aberta todo o dia e deixar essa janela em paz.

Antes de fechar o ticket, registe qual sessão o cliente estava a vigiar quando o túnel subiu. Essa única linha transforma uma desconexão misteriosa numa condição reproduzível para a próxima pessoa na máquina.