Mover un servidor VPN a unha nova IP pública: que comprobar primeiro

Reasignar un enderezo leva un minuto. A semana seguinte é onde rompe a mudanza, e rara vez onde o suxire a consola do provedor. Unha IP pública nova referénciase en catro lugares: o socket no que escoita o daemon, a áncora de confianza que verifican os clientes, cada regra que nomea o enderezo antigo e o rexistro DNS que os une. Dúas mudanzas parecen idénticas desde un panel de control pero compórtanse de xeito totalmente distinto: reasignar o enderezo na máquina que vostede opera, ou levantar un segundo endpoint e mover clientes a el. As comprobacións de abaixo pon primeiro os fallos baratos, e cada sección indica a que mudanza se aplica.

A substitución no lugar e o corte paralelo son traballos distintos

A substitución no lugar conserva o host, as chaves, a táboa de rutas e a lista de usuarios; só cambia o enderezo. Iso é o que fai unha reasignación de IP flotante, e en varios provedores o convidado non se entera, porque a tradución ocorre diante da instancia. Unha reconstrución ou unha reasignación do provedor é máis dura: o convidado ve o cambio, e todo o que cacheara o valor antigo apréndeo no mesmo momento.

Un endpoint paralelo é un segundo host que fai o mesmo traballo. Constrúao, próbeo cun perfil e deixe que o vello responda ata que o novo se demostre por unha ruta real. O prezo é o estado. Sen entradas de peer compartidas, revocacións e rexistro, ten dúas redes que casualmente comparten un nome.

Atope cada lugar onde está escrita a dirección antiga

Comece cun varrido de texto, porque os ficheiros de configuración son a metade fácil. Busque na configuración do daemon, os fragmentos de cortafuegos, os obxectivos de monitorización e calquera paquete de cliente xerado no disco. Inclúa o enderezo IPv6 se publica un; unha mudanza que só segue o rexistro A deixa os clientes de dobre pila na ruta antiga.

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

Despois varra o núcleo, porque un sistema en marcha garda o enderezo en lugares que ningún ficheiro menciona. Unha regra NAT de orixe estática, unha entrada de ipset, un enderezo de enlace e unha entrada de conntrack sobreviven á edición de configuración que as eliminou, e algunhas sobreviven a un reinicio porque volveron dun conxunto de regras gardado. Unha capa máis arriba, os grupos de seguridade do provedor, os obxectivos do balanceador e as comprobacións de monitorización non están no seu sistema de ficheiros en absoluto.

Escriba o inventario antes de cambiar nada; tamén serve como guión de reversión.

Os clientes con nome de host recupéranse; os clientes con IP literal calan

Se os clientes chegan ao servidor por nome de host, o corte é sobre todo un problema de DNS, e o TTL que fixou onte decide canto de malo será. Os resolvedores cachean, os resolvedores stub cachean outra vez, e moitos clientes só buscan o nome nunha conexión nova, así que un túnel establecido conserva o seu enderezo inicial.

Se o endpoint é un enderezo literal, nada se volve resolver e nada rexistra unha queixa. WireGuard garda un enderezo de socket resolto: Endpoint = vpn.example.net:51820 convértese nunha IP no momento en que se executa wg-quick up e segue sendo esa IP ata que a cambie. OpenVPN é máis indulgente: resolve o nome de host remote ao conectar e, con resolv-retry infinite, volve probar DNS ao reconectar. Cunha IP literal, ambos seguen marcando unha máquina que xa non existe.

O que engana á xente é a imaxe especular. Un cliente xa apuntado ao enderezo novo, mentres o escoitador vello aínda responde, pasa todas as probas que faga desde o seu escritorio. A min enganoume: o novo endpoint subiu nun teléfono ao primeiro intento, e un cliente cun perfil obsoleto só apareceu cando o escoitador vello se apagou moito despois.

A confianza non se muda co enderezo

WireGuard separa a identidade da accesibilidade, o que fai case gratis mover un enderezo. Os peers identifícanse por clave pública, e o endpoint é só onde van os paquetes agora; un host actualiza o endpoint dun peer a partir do enderezo de orixe do paquete autenticado máis recente. Un peer inactivo segue necesitando un motivo para falar co sitio novo, e aprende o enderezo só cando a súa sesión caduca e os reintentos de handshake fallan nalgún lugar visible. O inicio rápido de WireGuard cobre o campo endpoint.

Os servidores baseados en TLS son o caso oposto. O certificado está ligado a un nome, e un cliente que marca un enderezo compara o marcado cos nomes alternativos do suxeito. Conecte por IP a un certificado que só leva un SAN de DNS e a verificación falla: o nome que usou o cliente non está no certificado. Reemitir cun SAN de IP arranxa esa conexión e empeora a seguinte mudanza. Manter un nome de host no perfil e deixar verify-x509-name no seu sitio mantén a comprobación estrita mentres o enderezo de abaixo cambia.

Logo comprobe a que está ligado o daemon; un socket fixado ao enderezo antigo falla en silencio. Un servidor OpenVPN arrincado con local 203.0.113.10 négase a subir unha vez que ese enderezo desaparece, mentres que un escoitador en 0.0.0.0 segue o cambio gratis. NAT divídese igual: MASQUERADE segue o enderezo que agora teña a máquina, e un SNAT --to-source 203.0.113.10 estático segue reescribindo cara a un enderezo que xa non posúe, así que o tráfico de retorno desaparece. Se o enderezo novo chega con outra pasarela upstream, comprobe rp_filter: o filtrado de ruta inversa descarta o tráfico de retorno que chega por unha interface que o núcleo non esperaba.

Orde do corte e as probas de que funcionou

Baixe o TTL un día antes, levante o novo escoitador e demóstroo cun perfil que só teña vostede. Unha proba desde dentro da mesma rede non demostra case nada, así que use un teléfono con datos móbiles e probe algo que o túnel deba transportar en lugar dun ping ao endpoint.

Vixíe ambos os enderezos durante a xanela. wg show all latest-handshakes no host novo, ou o ficheiro de estado de OpenVPN, dille cantos peers se moveron de verdade. Cando o novo endpoint teña os peers que espera e o vello só teña atrasados, retire o escoitador vello, elimine a regra NAT obsoleta e saque o enderezo do cortafuegos do provedor. Retirar o escoitador vello é o paso que se salta, e pecha o oco onde un perfil obsoleto aínda alcanza a rede antiga.

Fixe por escrito o disparador de reversión antes de comezar: se o novo endpoint non ten handshake dun só cliente real tras a xanela acordada, restaure o enderezo antigo e deixe de distribuír perfís. Volva executar o varrido despois e confirme que ningún escoitador segue ligado a un enderezo retirado. Dúas cousas pasan á seguinte mudanza: un nome de host no perfil do cliente para que o seguinte cambio sexa unha edición de DNS, e o inventario gardado xunto ás notas de recuperación do servidor.