Como reverter com segurança a configuração de um servidor VPN

Reverter um servidor é uma decisão sobre qual camada falhou, não um exercício de cópia de ficheiros. Configuração, credenciais e versões de pacotes avançam em relógios separados, e restaurar uma enquanto as outras se mantêm atualizadas produz um anfitrião que parece saudável e se comporta de forma inconsistente. A sequência abaixo assume que uma alteração já correu mal e pede que restaure o estado coerente mais pequeno. Percorra-a por ordem e trate a verificação de acesso fora de banda como o passo que ninguém deve saltar.

Capture um ponto de controlo que realmente possa restaurar

Registe a configuração que o serviço lê no arranque, juntamente com a versão que a analisou pela última vez. Um ficheiro que carregava limpo numa versão anterior pode ser rejeitado ou ignorado em silêncio após uma atualização, pelo que a versão pertence à mesma nota. Inclua o material para o qual a configuração aponta: chaves privadas, caminhos de certificados, definições de escuta e as entradas de DNS e firewall que tornam o serviço alcançável. Se uma restauração exigisse um ficheiro que não guardou, o ponto de controlo está incompleto.

Nomeie o proprietário de cada definição enquanto o sistema ainda está saudável. Uma rota instalada pelo painel do fornecedor, uma adicionada pela firewall do anfitrião e uma enviada aos clientes são três objetos diferentes, e restaurar a errada deixa as outras duas no lugar. Basta uma tabela curta de definição, proprietário e caminho do ficheiro.

Mantenha as revogações separadas da configuração

Uma configuração antiga pode voltar a ligar em silêncio um dispositivo que removeu de propósito, o que transforma uma recuperação numa regressão de segurança. Preserve a lista de revogações atual e as contas desativadas enquanto restaura a política de rede, e volte a aplicá-las antes que o serviço aceite clientes.

Trate o estado de identidade como uma reversão própria com as suas próprias provas. Os ficheiros de revogação de certificados, a desativação de contas e o registo em MFA raramente vivem no mesmo local que a configuração do daemon, e uma restauração da configuração não lhes tocará. Verifique primeiro o estado atual para saber o que tem de sobreviver. Após a restauração, confirme que a identidade removida continua a não conseguir ligar-se.

Chegue ao anfitrião quando o túnel falhar

Abra um caminho para a máquina que não dependa do componente que está a ser alterado. Uma consola de hipervisor, um endereço de gestão numa interface separada ou uma consola série servem; uma sessão SSH transportada pelo túnel não. Se a única entrada for a VPN que está prestes a reiniciar, uma rota ou regra de firewall errada retira-lhe a capacidade de a corrigir. Teste o caminho alternativo antes da alteração, não depois. Inicie sessão por ele uma vez, confirme que o sudo funciona e anote o endereço exato que usou.

O teste é simples: baixe o túnel enquanto está ligado pelo caminho alternativo e veja se a sessão sobrevive. Se cair, encontrou a falha antes de ela o poder deixar encalhado.

Aplique uma única revisão e saiba quando entra em vigor

Use a documentação de reload ou restart do serviço e descubra que diretivas são lidas em que momento. Alguns valores aplicam-se no reload, outros só quando começa uma nova sessão ou processo, pelo que editar um ficheiro não prova nada sobre o estado em execução. Restaure uma única revisão em vez de misturar um ficheiro novo com estado de execução antigo. Em caso de dúvida, um reinício completo do serviço é mais fácil de raciocinar do que um reload parcial.

Verifique a definição da unidade antes de escolher: systemctl show -p ExecReload openvpn@server diz-lhe se existe algum gancho de reload. Aplique depois a revisão e leia o registo para os primeiros erros novos antes de alterar qualquer outra coisa.

Verifique, registe e investigue depois

Ligue um cliente autorizado e exercite aquilo para que o serviço existe: resolução de nomes, uma reconexão e a aplicação que falhou. Confirme que a identidade revogada continua a ser recusada. Registe a revisão que restaurou, a hora e o motivo, porque o próximo operador precisará das três. Uma reversão que ninguém documentou torna-se um mistério da próxima vez que o serviço se portar mal.

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

Uma vez estável o serviço, reproduza a alteração falhada num anfitrião ou instantâneo que possa descartar. Isso separa uma configuração má de um pacote mau ou de um certificado expirado. Mantenha a configuração restaurada sob controlo de versões para que o próximo ponto de controlo parta de um commit conhecido. O objetivo do exercício é um ponto final documentado, não uma degradação permanente.