Reconectar um cliente OpenVPN: três controles, três escopos

Alguém pede que o cliente VPN seja reconectado, e esse pedido pode significar três coisas diferentes. Pode significar descartar uma sessão autenticada, avisar cada cliente de que um servidor UDP está de saída, ou reiniciar o próprio daemon. Cada uma tem um raio de impacto diferente, e a escolha errada transforma uma correção para um usuário em uma queda. O escopo é a decisão, e o comando decorre dele.

Pergunte quem deve ser afetado antes de perguntar qual controle usar.

Uma instância: a interface de gerenciamento

Uma interface de gerenciamento configurada pode listar as instâncias conectadas e descartar exatamente uma delas. Cada sessão carrega um identificador de cliente, e client-kill CID aponta para esse identificador em vez de um nome comum. Leia o identificador vivo da saída de status atual, porque um valor copiado de um log mais antigo se refere a uma sessão que já não existe. Descartar a instância encerra essa conexão e nada mais.

Não garante uma conexão nova. Se o cliente volta depende de suas configurações de nova tentativa, das entradas remotas restantes, dos requisitos de autenticação e de a aplicação supervisora ainda estar em execução. Um cliente que volta recebe um novo identificador, e por isso comparar identificadores é a única forma confiável de distinguir o antigo do novo.

Um aviso de saída UDP não é um comando por cliente

explicit-exit-notify é uma diretiva de configuração sobre eventos de saída e reinício. Em um cliente UDP, ela informa ao par que a sessão está terminando, e o argumento numérico controla quantas vezes o aviso é repetido. Quando o servidor roda sobre UDP, ele envia uma mensagem de controle de reinício aos clientes conectados, e os valores documentados distinguem reconectar ao mesmo servidor de mudar para outra entrada remota. É um sinal de ciclo de vida com um público amplo.

Nada nele seleciona um cliente arbitrário em um momento arbitrário. Tratá-lo como um botão de reconexão alcança todas as sessões conectadas de uma vez.

Os sinais agem sobre o processo, não sobre uma sessão

SIGUSR1 pede a um processo em execução que reinicie sua conexão sem reler a configuração, e as opções de persistência decidem o que sobrevive a esse reinício. SIGHUP vai além: relê o arquivo de configuração e reabre seus recursos. SIGTERM e SIGINT pedem um desligamento ordenado. São operações no nível do processo: em um servidor com muitos clientes afetam cada sessão que o processo carrega, não a que está no ticket.

Quando o processo roda sob um gerenciador de serviços, use o controle do próprio gerenciador em vez de enviar um sinal a um PID que você encontrou em uma lista de processos. Leia a unidade para ver qual sinal o gerenciador envia, porque um reinício e um recarregamento fazem coisas diferentes ao mesmo daemon.

Decida o escopo antes de escolher o controle

Três perguntas resolvem. Quem deve ser afetado: um usuário, todos os clientes de um servidor ou o daemon e tudo o que ele carrega. O que deve sobreviver: a configuração, o estado do túnel ou nenhum dos dois. Quem tem autorização: a integração de gerenciamento, o dono do serviço ou o operador de rede que controla o aviso de saída. Responda a isso e só um controle se encaixa.

Adicionar um ouvinte de controle sem autenticação para obter um botão de reconexão entrega a quem alcançar a porta muito mais do que esse botão.

Verifique a nova sessão, não a desconexão

Um evento de desconexão prova que a sessão antiga terminou. Não diz nada sobre uma nova que se autentica, recebe um endereço, instala rotas ou alcança o recurso de que o usuário precisava. Verifique o novo identificador, depois o estado do túnel, depois um recurso real. Esses três passos são a diferença entre uma reconexão e uma conexão que funciona.

Escreva o escopo no registro de mudanças. «Reconectei o cliente» não é uma descrição quando o cliente era um de quarenta em um servidor compartilhado.