Mover um servidor VPN para um novo IP público: o que verificar primeiro

Reatribuir um endereço leva um minuto. A semana seguinte é onde a mudança quebra, e raramente onde o console do provedor sugere. Um novo IP público é referenciado em quatro lugares: o socket em que o daemon escuta, a âncora de confiança que os clientes verificam, cada regra que nomeia o endereço antigo e o registro DNS que os liga. Duas mudanças parecem idênticas num painel de controlo mas comportam-se de forma totalmente diferente: reatribuir o endereço na máquina que você opera, ou levantar um segundo endpoint e mover os clientes para ele. As verificações abaixo põem primeiro as falhas baratas, e cada secção indica a que mudança se aplica.

A substituição no local e a transição paralela são trabalhos diferentes

A substituição no local mantém o host, as chaves, a tabela de rotas e a lista de utilizadores; só o endereço muda. É o que faz uma reatribuição de IP flutuante, e em vários provedores o convidado nem nota, porque a tradução acontece à frente da instância. Uma reconstrução ou reatribuição pelo provedor é mais dura: o convidado vê a mudança, e tudo o que tinha o valor antigo em cache aprende-o no mesmo momento.

Um endpoint paralelo é um segundo host que faz o mesmo trabalho. Construa-o, teste-o com um perfil e deixe o antigo responder até o novo se provar num caminho real. O preço é o estado. Sem entradas de peer partilhadas, revogações e registo, tem duas redes que partilham um nome por acaso.

Encontre cada lugar onde o endereço antigo está escrito

Comece com uma varredura de texto, porque os ficheiros de configuração são a metade fácil. Procure na configuração do daemon, nos fragmentos de firewall, nos alvos de monitorização e em qualquer pacote de cliente gerado no disco. Inclua o endereço IPv6 se publicar um; uma mudança que só segue o registo A deixa os clientes de dupla pilha no caminho antigo.

OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpoints

Depois varra o núcleo, porque um sistema em execução guarda o endereço em lugares que nenhum ficheiro menciona. Uma regra NAT de origem estática, uma entrada de ipset, um endereço de bind e uma entrada de conntrack sobrevivem à edição de configuração que as removeu, e algumas sobrevivem a um reinício porque voltaram de um conjunto de regras guardado. Uma camada acima, os grupos de segurança do provedor, os alvos do balanceador e as verificações de monitorização não estão no seu sistema de ficheiros de todo.

Escreva o inventário antes de mudar qualquer coisa; também serve como script de reversão.

Os clientes com nome de host recuperam; os clientes com IP literal ficam calados

Se os clientes chegam ao servidor por nome de host, a transição é sobretudo um problema de DNS, e o TTL que definiu ontem decide quão mau será. Os resolvers fazem cache, os resolvers stub fazem outra, e muitos clientes só consultam o nome numa ligação nova, por isso um túnel estabelecido mantém o seu endereço inicial.

Se o endpoint é um endereço literal, nada volta a resolver-se e nada registra uma queixa. O WireGuard guarda um endereço de socket resolvido: Endpoint = vpn.example.net:51820 torna-se um IP no momento em que wg-quick up corre e continua a ser esse IP até o alterar. OpenVPN é mais tolerante: resolve o nome de host remote no momento da ligação e, com resolv-retry infinite, tenta DNS novamente ao religar. Com um IP literal, ambos continuam a marcar uma máquina que já não existe.

O que engana as pessoas é a imagem no espelho. Um cliente já apontado ao endereço novo, enquanto o antigo serviço de escuta ainda responde, passa todos os testes que fizer da sua secretária. Eu já fui enganado por isso: o novo endpoint subiu num telefone à primeira tentativa, e um cliente com um perfil desactualizado só apareceu quando o antigo serviço foi desligado muito mais tarde.

A confiança não se desloca com o endereço

O WireGuard separa a identidade da acessibilidade, o que torna a deslocação de endereço quase gratuita. Os peers são identificados por chave pública, e o endpoint é apenas onde os pacotes vão agora; um host actualiza o endpoint de um peer a partir do endereço de origem do último pacote autenticado. Um peer inactivo ainda precisa de um motivo para falar com o local novo, e só aprende o endereço quando a sua sessão envelhece e as tentativas de handshake falham num lugar visível. O arranque rápido do WireGuard cobre o campo endpoint.

Os servidores baseados em TLS são o caso oposto. O certificado está ligado a um nome, e um cliente que marca um endereço compara o que marcou com os nomes alternativos do sujeito. Ligue por IP a um certificado que só leva um SAN de DNS e a verificação falha: o nome que o cliente usou não está no certificado. Reemitir com um SAN de IP corrige essa ligação e piora a mudança seguinte. Manter um nome de host no perfil e deixar verify-x509-name no lugar mantém a verificação estrita enquanto o endereço por baixo muda.

Depois verifique a que está ligado o daemon; um socket preso ao endereço antigo falha em silêncio. Um servidor OpenVPN iniciado com local 203.0.113.10 recusa subir assim que esse endereço desaparece, enquanto um serviço de escuta em 0.0.0.0 segue a mudança de graça. O NAT divide-se da mesma forma: MASQUERADE segue o endereço que a máquina tem agora, e um SNAT --to-source 203.0.113.10 estático continua a reescrever para um endereço que já não possui, pelo que o tráfego de retorno desaparece. Se o endereço novo vier com outra gateway upstream, verifique rp_filter: a filtragem de caminho inverso descarta o tráfego de retorno que chega a uma interface que o núcleo não esperava.

Ordem da transição e as provas de que funcionou

Baixe o TTL um dia antes, levante o novo serviço de escuta e prove-o com um perfil que só você tem. Um teste de dentro da mesma rede não prova quase nada, por isso use um telefone em rede móvel e teste algo que o túnel deve transportar em vez de um ping ao endpoint.

Vigie os dois endereços durante toda a janela. wg show all latest-handshakes no host novo, ou o ficheiro de estado do OpenVPN, diz-lhe quantos peers se deslocaram realmente. Quando o novo endpoint tiver os peers que espera e o antigo só tiver retardatários, retire o serviço de escuta antigo, remova a regra NAT obsoleta e tire o endereço da firewall do provedor. Remover o serviço antigo é o passo que é saltado, e fecha a brecha onde um perfil obsoleto ainda alcança a rede antiga.

Defina por escrito o gatilho de reversão antes de começar: se o novo endpoint não tiver handshake de um único cliente real após a janela acordada, restaure o endereço antigo e pare de distribuir perfis. Volte a executar a varredura depois e confirme que nenhum serviço de escuta continua ligado a um endereço retirado. Duas coisas passam para a mudança seguinte: um nome de host no perfil do cliente para que a próxima alteração seja uma edição de DNS, e o inventário guardado ao lado das notas de recuperação do servidor.