OpenVPN Access Server: reiniciar o daemon ou aplicar a definição

Duas comandos são colados para o que parece a mesma tarefa num OpenVPN Access Server, e fazem coisas diferentes. systemctl restart openvpnas para e arranca todo o produto. sacli start levanta os serviços internos que leem a configuração que acabou de alterar. Escolher entre eles não é uma questão de gosto: depende do que diz a documentação da própria definição, de a sua sessão passar pelo servidor que vai reiniciar e de estar sequer a olhar para o produto certo.

Duas camadas, um daemon

O Access Server corre como uma única unidade systemd, openvpnas, e esse daemon supervisiona os serviços internos atrás da interface web e os ouvintes de VPN. O sacli é a interface de linha de comandos para a mesma instalação, em /usr/local/openvpn_as/scripts/sacli, e pode iniciar, parar e consultar esses componentes internos sem substituir a unidade.

É por isso que existem os dois comandos. Um reinício do daemon volta a executar tudo, incluindo o processo que termina os túneis dos clientes. O sacli start pede ao daemon já em execução que levante os seus componentes para lerem a nova configuração, e é isso que a maioria das alterações de propriedades exige realmente.

Primeira condição: o que diz a documentação da definição

Leia a página da definição que alterou, não a de uma definição de há um mês. Uma propriedade escrita via ConfigPut é normalmente seguida de sacli start, e esse par é o passo de aplicação documentado. Uma alteração de comportamento ao nível do ouvinte, ou tudo o que a página descreva como exigindo reinício do serviço, é a classe em que o reinício da unidade está correto.

Os dois comandos não são intermutáveis, por isso o modo de falha ao adivinhar é assimétrico. Usar sacli start quando era preciso um reinício completo deixa um processo antigo a servir a configuração anterior, o que parece que a definição foi ignorada. Fazer um reinício completo quando bastava sacli start expulsa todos os clientes ligados sem motivo.

Segunda condição: a sua sessão está dentro do túnel

Se administra o Access Server através da VPN que ele fornece, o reinício remove a ligação que transporta a sua shell. O comando pode terminar depois de a sessão morrer, ficando a adivinhar se funcionou. O sacli start também pode interromper brevemente uma sessão pelo mesmo motivo quando o componente reiniciado trata do seu tráfego.

Mantenha um caminho fora de banda aberto antes de qualquer dos comandos: uma consola do fornecedor, uma consola do hipervisor ou uma sessão série. Esta condição decide quando executa o comando, não qual, e é ela que transforma uma alteração de dois minutos num relatório de indisponibilidade.

Terceira condição: é este o produto que pensa

O Access Server não é o Community OpenVPN. Uma instalação community executa unidades como openvpn@server ou openvpn-client@profile, com a configuração em /etc/openvpn, e o sacli não existe lá. Reiniciar todas as unidades com openvpn no nome num anfitrião partilhado é a forma como túneis não relacionados caem juntos.

Identifique antes de tocar em nada: systemctl status openvpnas --no-pager responde se é o Access Server que está a correr, sacli status lista os seus componentes internos, e systemctl list-units --type=service lista as unidades cujos nomes contêm openvpn. Se o último comando mostrar unidades com nomes de perfil, está no produto community e o resto disto não se aplica a si.

Aplique e depois verifique para além de active

Uma unidade que relata active tem um processo em execução, o que não é o mesmo que um caminho de autenticação a funcionar. Após o passo de aplicação, verifique sacli status para os componentes que esperava reiniciar, confirme que o valor foi guardado com sacli ConfigQuery e depois execute um início de sessão de cliente limitado com uma conta de teste.

Termine com algo ao nível da aplicação: chegue a um recurso privado pelo túnel, não apenas um ping ao endereço público do servidor. Um handshake que tem sucesso enquanto a rota empurrada ou a definição de DNS estão erradas passará todas as verificações de serviço e ainda assim falhará a pessoa que reportou o problema.

o tutorial do fornecedor sobre gestão de serviços é a referência de quais operações pertencem ao sacli, e vale a pena abri-la antes de decidir que um reinício é a opção segura.

A decisão numa passagem

Percorra estas quatro linhas e pare na primeira que se aplicar:

• A página da definição nomeia sacli start, ou acabou de executar ConfigPut: use sacli start.
• A página exige um reinício, ou a alteração toca ouvintes e não propriedades: use systemctl restart openvpnas.
• A sua shell chega por este servidor: prepare primeiro o acesso à consola e depois execute o comando escolhido pelas duas linhas acima.
• Verificação: sacli status, ConfigQuery para o valor, um início de sessão, um recurso privado. O estado do serviço por si só não é a meta.

Duas dessas linhas são verificações e duas são ações, e é esse o sentido da ordem. Se não conseguir responder à pergunta sobre o produto, pare: o comando que ia executar pertence a outra instalação, e o túnel que derrubar não será o que pretendia.