Por quanto tempo o OpenConnect deve continuar tentando uma VPN caída?

--reconnect-timeout responde a uma pergunta estreita: depois que o túnel cai, por quanto tempo este processo cliente continua tentando antes de desistir e sair. A página do manual do OpenConnect registra essa opção com um padrão documentado de 300 segundos para novas tentativas que se seguem à perda do link ou a um par que parou de responder, e o número é um prazo para um único cliente em execução, não prova de que a VPN continue alcançável. Também não é uma política para manter o processo vivo, e é aí que começa a maior parte da confusão.

A confusão aumenta quando um segundo mecanismo fica por cima. Um supervisor que reinicia o cliente, um sondador que faz ping no gateway e a janela de novas tentativas embutida podem todos reagir a uma única falha, e o incidente então rende três linhas do tempo que ninguém consegue reconciliar.

O que a janela de reconexão realmente limita

Imagine que a rede de acesso desaparece por alguns segundos. O cliente vê o link cair, ou deixa de ouvir as respostas do par morto, e começa a restabelecer a sessão retendo o estado que consegue. As tentativas continuam até o gateway aceitar de novo ou até a janela acabar, e uma janela esgotada termina numa saída diferente de zero. É essa saída, e não o valor do tempo limite, o ponto em que a propriedade do ciclo de vida passa para quem supervisiona o processo.

A janela não diz nada sobre a frequência com que uma sonda roda, e não pode estender a autenticação. Se o gateway revogou a sessão, ou a conta agora exige um segundo fator novo, esperar mais não tornará a sessão antiga válida de novo. Uma nova tentativa só dá certo quando o caminho volta, o gateway ainda reconhece a sessão e as credenciais pedidas continuam utilizáveis, então leia o número como prazo e não como intervalo de vitalidade.

A janela também não governa o que as aplicações fazem enquanto ela corre. Dependendo da plataforma e de até onde a falha chegou, o cliente pode estar reconectando com as rotas ainda instaladas, ou depois de elas terem sido removidas. Por isso uma requisição emitida no meio de uma interrupção costuma ficar pendurada até o tempo limite em vez de falhar rápido.

Reinícios do supervisor e novas tentativas do cliente são duas camadas

Deixe o cliente em execução gastar a própria janela, e deixe o gerenciador de serviços reagir à saída. Um cliente em primeiro plano sob systemd com uma política de reinício dá exatamente essa divisão: tentativas por um período limitado, depois uma única decisão de reinício. O resultado é uma única linha do tempo que você ainda pode reconstruir depois.

Um cliente em segundo plano mais um sondador independente que inicia outra cópia quando não vê uma interface é o padrão que dá errado. Então os dois processos disputam o mesmo nó de dispositivo, as rotas e as configurações do resolvedor. Se você realmente quer um daemon, ponha a opção na linha de comando com que o cliente de fato inicia:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Dois detalhes nessa linha pesam. --background desacopla o processo, de modo que o arquivo pid se torna a única alça confiável sobre ele, e o tempo limite só é gasto enquanto esse mesmo processo vive; um supervisor que o mata não deixa orçamento para continuar.

Desconexões intencionais precisam do próprio sinal. Uma pausa planejada e uma queda real parecem idênticas para um observador ingênuo, e ambas são lidas como «não conectado». Conduza a pausa pela operação de parada do supervisor, ou por um marcador que o invólucro entenda, para que uma parada deliberada não dispare um reinício que ninguém pediu.

Evitar que a entrega corra contra o laço de novas tentativas

A recuperação sem supervisão depende de credenciais que se renovam sem uma pessoa presente. Um chaveiro que só se destranca dentro de uma sessão interativa de desktop, ou um token que sempre exige um código digitado, deixará o cliente preso na etapa de autenticação assim que o caminho voltar. Resolva esse fluxo antes de alongar a janela, porque uma janela mais longa só dá à mesma solicitação bloqueada mais tempo para falhar.

A verificação do servidor não deve ser afrouxada para reduzir solicitações. Justamente o pin ou a âncora de confiança que valida o gateway é o que torna uma reconexão automática segura, e desativá-lo para evitar uma pergunta sobre certificado troca uma interrupção visível por outra invisível. Mantenha a identidade verificada e conserte a solicitação; um cliente disposto a se conectar a qualquer gateway é pior do que um que para e espera.

A presença da interface também não é sinal de saúde. Um dispositivo de túnel pode existir com uma sessão morta atrás dele, e um processo lançador pode existir sem túnel nenhum. Nenhuma dessas observações resiste a uma requisição real. A saúde tem de vir do que o usuário precisa, como uma requisição que atravessa o túnel até um serviço interno conhecido.

O que verificar durante e depois de uma interrupção

Execute quatro eventos como testes separados: uma interrupção mais curta que a janela, uma queda mais longa que ela, uma falha de autenticação e uma parada intencional. Cada um deve terminar num estado diferente e previsível, e a fronteira entre os dois primeiros é toda a razão para escolher um valor.

Mantenha as checagens voltadas para fora, porque a tabela de processos por si só prova muito pouco. Observe o pid se manter estável durante o corte curto e depois confirme que ele sumiu e foi substituído uma vez após o longo:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Durante a interrupção curta, confirme que o cliente realmente tentou de novo em vez de sair cedo, e que as rotas e as entradas do resolvedor voltaram sem duplicatas. Para a queda mais longa, confirme uma saída limpa e exatamente um reinício depois. Para a falha de autenticação, confirme que o cliente não gira contra um gateway que continuará a recusá-lo. Acrescente uma checagem de que o pid volta a um único valor em vez de se acumular.

Para a parada deliberada, a URL de saúde deve continuar inalcançável e o processo deve continuar parado. Depois feche o laço pelo lado da aplicação: a mesma requisição deve falhar enquanto o túnel não está e deve ter sucesso depois que ele volta, a partir do endereço de origem que sua política espera. Um ícone verde de túnel não é prova, mas uma requisição concluída é.