Porque nc -uz não consegue provar que um servidor OpenVPN está pronto

Executar nc -uz contra um servidor OpenVPN quase não mede nada, e o manual do OpenBSD diz isso nas suas ressalvas: as análises UDP nesse modo reportam sucesso quer algo esteja a escutar quer não. O estado de saída reflete o envio local, não o estado remoto, por isso um supervisor que confia nele mantém um servidor morto marcado como saudável enquanto a tabela de processos parecer plausível. Substituí-lo começa por decidir a que pergunta a verificação deve responder, porque processo, ouvinte, autenticação e alcance da aplicação são quatro observações diferentes. Uma sonda que nomeia uma delas é útil; uma sonda que implica as quatro é um fardo.

O que uma sonda UDP pode e não pode observar

nc -uz envia um datagrama e sai, e o estado que devolve descreve o envio local. Um porto fechado pode responder com ICMP port unreachable, mas o comportamento documentado deste modo de análise não o converte numa falha, e um porto filtrado não produz qualquer resposta. Por isso, silêncio e sucesso significam o mesmo para quem chama.

Isso torna a sonda num teste da pilha local, não do servidor. Não estabelece que o anfitrião esteja acessível, que o porto esteja ligado, que o processo OpenVPN esteja a correr ou que um cliente pudesse autenticar-se. Um teste de ligação TCP é mais forte porque o aperto de mão dá uma resposta definitiva, mas só quando a implementação escuta realmente em TCP. Mudar a sonda para TCP no mesmo número testa um ouvinte que pode não existir, e contra um servidor apenas UDP fará falhar um serviço saudável.

Ajustar a sonda ao transporte configurado vem antes de confiar em qualquer dos dois resultados. Uma implementação UDP precisa de um sinal diferente, não de um protocolo diferente.

Três quem chama, três perguntas diferentes

A prontidão depende de quem pergunta. O gestor de serviços que reinicia um processo bloqueado precisa de saber que a instância arrancou e ligou o seu ouvinte. O balanceador de carga precisa de saber que um cliente que chegue agora seria aceite. O sistema de monitorização precisa de saber que o caminho desde uma rede real ainda transporta uma sessão até um recurso permitido.

Não são a mesma verificação, e uma única sonda não pode cobrir honestamente as três. Escolha primeiro quem chama e depois a evidência.

Construa a sonda a partir da instância atual

O OpenVPN escreve uma linha de arranque quando uma instância termina a inicialização, e essa linha é uma evidência útil sobre o arranque local. Leia-a do arranque atual e não da cauda de um ficheiro a que se acrescenta, porque um sucesso da semana passada lê-se exatamente como um sucesso de há um minuto. Um servidor também pode terminar a inicialização antes de algum cliente se ter ligado, por isso a linha não diz nada sobre a autenticação.

Para uma verificação de arranque, combine o estado do processo com a evidência atual do registo e um ouvinte que corresponda ao transporte configurado. A verificação deve falhar quando o processo está em execução mas não terminou a inicialização, o que significa que a consulta ao registo tem de ficar limitada a este arranque e a esta unidade.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Três saídas, três afirmações: a unidade está ativa, este arranque produziu a linha de inicialização e algo ocupa o porto UDP. Nenhuma delas diz que um cliente se pode ligar. Mantenha-as separadas na página de estado para que um incidente não colapse num único ponto verde.

Quebre-a de propósito e observe a sonda

Uma sonda só é fiável quando a viu falhar. Pare o servidor, execute a sonda e confirme o resultado que espera. Depois volte a arrancá-lo e confirme que a sonda recupera sem qualquer outra alteração.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Leia o bloco linha a linha. O comando netcat imprime exit=0 enquanto nada está ligado, e esse é todo o problema numa linha. O primeiro ss não imprime nada, o reinício tem sucesso, e o segundo ss volta a mostrar o ouvinte. Se a sua sonda passa contra o servidor parado, está a medir a pilha local e nada mais.

A falha oposta também importa. Uma sonda que falha contra um servidor saudável provoca reinícios que nunca foram necessários, e um ciclo de reinícios é por si só uma interrupção. Teste as duas direções antes de ligar a sonda a qualquer coisa que possa agir sobre ela.

O que a linha de estado deve dizer

Registe que fronteira cada verificação cobre: processo, ouvinte, autenticação ou aplicação. Uma verificação raramente cobre mais de uma, e uma página de estado que as comprime em “up” esconde a diferença que importa durante um incidente. Para o caminho de rede, use um cliente real com uma identidade dedicada, deixe-o completar o aperto de mão e uma operação permitida inofensiva, e depois desligue-o. Isso exercita o canal de controlo, a política de autenticação e o ouvinte num único passo.

Mantenha essa identidade separada dos utilizadores reais e dê-lhe as permissões mínimas de que a verificação precisa. Uma sonda de prontidão com acesso amplo é uma nova superfície de ataque acrescentada por conveniência. Rode as suas credenciais como qualquer outra conta, porque uma sonda que deixa de autenticar parece exatamente um servidor que deixou de aceitar clientes.

Nomeie a fronteira no texto do alerta, para que o primeiro interveniente saiba se deve olhar para a unidade, o socket, o certificado ou a rota. Uma sonda que não consegue dizer o que provou será confiada pela razão errada, e foi assim que a verificação com netcat sobreviveu em primeiro lugar.