Cómo migrar su infraestructura IP a IPv4 arrendado sin tiempo de inactividad

Las migraciones de IP generan un tipo de estrés muy particular. A diferencia de la mayoría de los cambios de infraestructura, que pueden revertirse en segundos, pasar a una nueva dirección IP afecta a todo: registros DNS, reglas de cortafuegos, rutas BGP, configuraciones de aplicaciones, sistemas de monitorización y las expectativas de cada usuario y servicio que se conecta a usted. Si lo hace sin cuidado, no recibirá ningún aviso. Tendrá una caída del servicio.

La buena noticia es que una migración de IPv4 bien planificada a una subred arrendada puede ejecutarse sin ninguna interrupción del servicio. La diferencia entre un cambio fluido y un incidente en producción casi nunca está en la capacidad técnica: está en la preparación, la secuencia y el momento elegido. Esta guía aborda los tres aspectos.

Tanto si pasa a un bloque IPv4 arrendado por primera vez como si reasigna subredes dentro de un arrendamiento ya existente, los pasos siguientes le ofrecen un marco fiable para cambiar de IP sin tiempo de inactividad.

Lista de comprobación previa a la migración

Antes de iniciar cualquier configuración técnica, necesita una visión completa de lo que va a cambiar. Saltarse este paso es la causa más habitual de que las migraciones de IP provoquen incidentes imprevistos.

Confirme los datos de su subred arrendada

Empiece por lo básico: la notación CIDR, el tamaño de la subred y todos los detalles de su contrato de arrendamiento. La configuración de su subred en IPbnb mostrará el prefijo exacto que se le ha asignado, los datos del titular de las IP y el plazo de arrendamiento. Asegúrese de que esta información es correcta antes de cualquier otra cosa.

Confirme también:

• Si el titular de las IP ha creado una Route Origin Authorization (ROA) para su subred y su ASN. Sin una ROA válida en RPKI, su prefijo puede ser filtrado por los pares que validan RPKI.

• Si existe un objeto route de IRR en el registro de enrutamiento correspondiente. Para los recursos gestionados por RIPE, se trata de la base de datos de RIPE.

Audite sus dependencias de IP actuales

Elabore una lista completa de todos los sistemas, servicios y configuraciones que hacen referencia a sus direcciones IP actuales. Esto incluye:

• Todos los registros DNS A y PTR (DNS inverso) que apuntan a las IP actuales

• Reglas de cortafuegos y de control de acceso que hacen referencia a las direcciones actuales

• Archivos de configuración de aplicaciones con IP codificadas de forma fija

• Sistemas de monitorización y alertas que supervisan las direcciones actuales

• Configuraciones de servicios de terceros (CDN, protección DDoS, procesadores de pagos)

• Configuraciones de pares BGP y proveedores upstream

• Registros SPF, si su subred gestiona correo saliente

Esta auditoría es tediosa. Pero también es la parte que le salvará a las 3 de la madrugada.

Compruebe la reputación de su nueva subred

Los bloques IPv4 arrendados tienen un historial. Antes de migrar el tráfico de producción a su nueva subred, compruebe su situación en las principales bases de datos de reputación IP: Spamhaus, Talos Intelligence, MXToolbox y AbuseIPDB. Un bloque con mala reputación puede provocar filtrados en servidores de correo, CDN o dispositivos de seguridad antes incluso de que haya terminado la migración. Si detecta problemas de reputación, resuélvalos antes de la ventana de migración, no después.

Defina su plan de reversión

Todo plan de migración de IP necesita una salida. Antes de empezar, documente con exactitud cómo volverá a su antigua subred si algo sale mal. Esto implica mantener sus direcciones IP antiguas activas y enrutables durante toda la ventana de migración, no solo durante el cambio en sí.

Preparación del TTL de DNS

El TTL (Time to Live) de DNS es el valor que indica a los resolutores cuánto tiempo deben almacenar en caché un registro antes de consultar si hay una actualización. Durante una migración de IPv4, el TTL determina la rapidez con la que se propagan sus cambios de DNS por internet y, por tanto, la duración real de la ventana de transición.

Por qué importa el TTL

Si sus registros A actuales tienen un TTL de 86.400 segundos (24 horas), incluso después de actualizarlos para que apunten a su nueva subred, los resolutores de todo el mundo pueden seguir sirviendo la dirección IP antigua durante un máximo de 24 horas. Durante esa ventana, parte del tráfico llegará a sus direcciones antiguas y parte a las nuevas. Si su antigua subred ya no está activa, el tráfico que llegue a las direcciones antiguas simplemente se pierde.

La solución es reducir el TTL con suficiente antelación a la migración.

Cómo prepararse

Reduzca su TTL a 300 segundos (5 minutos), o incluso a 60 segundos para los registros críticos, al menos un ciclo completo de TTL antes de que se abra su ventana de migración. El momento depende por completo de su valor de TTL actual:

• Si su TTL actual es de 86.400 s (24 horas), redúzcalo al menos 24 horas antes de la migración

• Si su TTL actual es de 3.600 s (1 hora), redúzcalo al menos 1 hora antes de la migración

Tras reducirlo, espere el periodo completo antes de realizar cualquier cambio de IP. Así se asegura de que, cuando actualice sus registros, ningún resolutor conserve una copia en caché del valor antiguo.

Qué registros actualizar

• Registros A: correspondencias directas entre nombre de host e IP; el objetivo principal de cualquier migración de IP

• Registros PTR: entradas de DNS inverso que asocian direcciones IP a nombres de host. En la región de RIPE, la delegación del DNS inverso se gestiona a través de la base de datos de RIPE: el titular de las IP o el LIR que gestiona el recurso crea un objeto domain que apunta a sus servidores de nombres. Esto no es automático y requiere una coordinación explícita con el titular de las IP antes de la ventana de migración, no durante ella. Plantéelo en la fase previa a la migración.

• Registros SPF: si su subred se utiliza para enviar correo, actualice su registro SPF para incluir el nuevo prefijo y eliminar el antiguo

Una vez que la migración haya finalizado y sea estable, vuelva a subir el TTL a un valor más alto (3.600 segundos o más). Un TTL bajo aumenta el volumen de consultas DNS y no debería mantenerse de forma permanente.

Configuración del anuncio BGP

Si anuncia su bloque IPv4 arrendado mediante BGP, ya sea directamente desde su propia infraestructura o a través de un acuerdo BYOIP con un proveedor cloud, la configuración del enrutamiento debe completarse y verificarse antes de dirigir cualquier tráfico a la nueva subred.

RPKI y ROA

La Route Origin Authorization (ROA) es el mecanismo que autoriza a un ASN concreto a originar un prefijo concreto en BGP. En la región de RIPE, las ROA las crea el titular del recurso, es decir, el titular de las IP y no el cliente que las arrienda. Antes de la migración, confirme con el titular de las IP que existe una ROA para su prefijo y su ASN, con la longitud máxima de prefijo correcta.

Puede verificar el estado de la ROA con el validador RPKI de RIPE NCC, el RPKI Toolkit de Cloudflare o Routinator. Si falta la ROA, su prefijo queda en estado UNKNOWN, que la mayoría de las redes aceptan, aunque algunos pares conservadores pueden filtrarlo. Una ROA incorrecta (ASN o longitud máxima de prefijo erróneos) lo marca como INVALID, lo que provoca un filtrado activo de la ruta por parte de todos los pares que validan RPKI. La distinción es importante: unknown e invalid son dos problemas diferentes con dos soluciones diferentes.

Objetos route de IRR

Además de RPKI, muchas redes filtran los anuncios BGP en función de los datos del IRR (Internet Routing Registry). Para los prefijos gestionados por RIPE, los objetos route deben registrarse en la base de datos de RIPE. Confirme que existe un objeto route para su prefijo con el ASN de origen correcto. Si falta, debe crearse, normalmente por parte del titular de las IP o del LIR de RIPE que gestiona el recurso.

Anunciar el prefijo

Una vez creados los objetos ROA e IRR, configure su sesión BGP para anunciar el nuevo prefijo. Antes de la migración, pruebe el anuncio con un looking glass BGP: herramientas como RIPE RIS, BGPView o el HE BGP Toolkit le permiten verificar que su prefijo es visible desde múltiples puntos de observación y que el ASN de origen coincide con la ROA.

No inicie la migración de IP hasta que su prefijo sea visible y se enrute correctamente. Un prefijo sin anunciar o mal enrutado significa que el tráfico hacia su nueva subred simplemente no llega a ninguna parte.

Longitud mínima de prefijo

Antes de configurar BGP, confirme que su bloque IPv4 arrendado es un /24 o mayor. La gran mayoría de los pares de internet y de los route servers de los IXP aplican filtros de longitud de prefijo que descartan silenciosamente los anuncios más largos que /24, lo que significa que los prefijos /25, /26 y menores no se propagarán por internet, aunque sus objetos ROA e IRR estén correctamente configurados. Si su bloque arrendado es menor que /24, coordine con el titular de las IP o con su proveedor upstream las opciones de anuncio. La solución habitual es que el titular de las IP anuncie el agregado que lo cubre y utilice rutas más específicas internamente.

En el caso de BYOIP en AWS, GCP o Azure, el proveedor cloud se encarga del anuncio BGP en su nombre una vez que usted aprovisiona el pool de direcciones. El proceso de configuración detallado para cada plataforma se explica en la guía BYOIP de IPbnb para AWS, GCP y Azure.

Migración paso a paso

Con la lista de comprobación completada, el TTL reducido y el enrutamiento BGP verificado, está listo para ejecutar la migración. El enfoque más seguro es el funcionamiento en paralelo: poner la nueva subred completamente en marcha antes de retirar la antigua.

Fase 1: funcionamiento en paralelo

Configure todos los servicios y aplicaciones en la nueva subred arrendada manteniendo activas las direcciones antiguas. En esta fase, ambas subredes están operativas simultáneamente. Pruebe a fondo sus servicios desde las nuevas IP antes de realizar cualquier cambio de DNS. Si su proveedor upstream admite comunidades BGP, considere utilizar una comunidad NO_EXPORT durante esta fase para limitar el anuncio del nuevo prefijo a determinados pares mientras valida el enrutamiento, y elimínela cuando esté seguro de que el prefijo se comporta correctamente. Este es su último punto de control de bajo riesgo.

Antes de continuar, confirme que:

• Los servicios responden correctamente desde las nuevas direcciones IP

• El enrutamiento BGP es estable y el prefijo es visible a nivel global

• La monitorización está activa en la nueva subred

• Los registros PTR de la nueva subred están operativos y correctamente configurados

Fase 2: cambio de DNS

Actualice sus registros DNS A para que apunten a la nueva subred. Como el TTL se redujo durante la fase de preparación, este cambio se propagará en 5 minutos, o en el periodo de TTL reducido que haya establecido.

Siempre que sea posible, actualice todos los registros afectados a la vez para minimizar la ventana de incoherencia. Después de actualizarlos, supervise la propagación DNS con varios resolutores:

# Verificar la resolución desde distintos resolutores públicos

dig A yourdomain.com @8.8.8.8

dig A yourdomain.com @1.1.1.1

dig A yourdomain.com @9.9.9.9

Fase 3: monitorización del tráfico

Tras el cambio de DNS, vigile las métricas de tráfico tanto en la subred antigua como en la nueva. El tráfico en la subred antigua debería disminuir de forma constante a medida que caducan las entradas DNS en caché en internet. El tráfico en la nueva subred debería aumentar en la misma medida. Espere hasta que el tráfico de la subred antigua haya bajado prácticamente a cero antes de pasar a la siguiente fase.

Fase 4: retirada de la subred antigua

Una vez que haya confirmado que no llega tráfico significativo a las direcciones antiguas:

• Elimine las direcciones IP antiguas de sus servicios y configuraciones de aplicaciones

• Retire el anuncio del prefijo BGP antiguo si lo estaba anunciando directamente

• Actualice o elimine las referencias restantes a IP antiguas en reglas de cortafuegos y archivos de configuración

• Notifique a sus socios o servicios externos que las direcciones antiguas ya no están activas

No precipite esta fase. Mantener las direcciones antiguas activas durante 24–48 horas adicionales una vez que el tráfico se ha agotado no cuesta nada y ofrece una red de seguridad para cualquier entrada DNS en caché que no se detectara durante la auditoría inicial.

Si todavía se encuentra en la fase de planificación y busca un bloque IPv4 arrendado al que migrar, explore las subredes disponibles en IPbnb para encontrar la que mejor se adapte a los requisitos de su infraestructura.

Verificación posterior a la migración

El cambio no es el final del proceso. Las horas y los días siguientes requieren una monitorización activa para confirmar que todo funciona según lo previsto y que su nueva subred se comporta de forma limpia.

Comprobación del enrutamiento

La verificación del enrutamiento confirma que el tráfico llega correctamente a su nueva subred desde todas las regiones geográficas relevantes, no solo desde su propio punto de observación.

Propagación de rutas BGP

Utilice looking glasses BGP para confirmar que su prefijo es visible desde múltiples puntos de observación de distintos AS y que no han aparecido anomalías de enrutamiento inesperadas:

• RIPE RIS Looking Glass (ris.ripe.net): amplia cobertura de pares europeos y globales

• HE BGP Toolkit (bgp.he.net): muestra las rutas upstream y la visibilidad entre pares

• BGPView (bgpview.io): visibilidad e historial claros por prefijo

Verifique que el ASN de origen coincide con su ROA, que el prefijo no se está anunciando con prepends inesperados en la ruta y que no se están filtrando prefijos más específicos desde fuentes no previstas.

Conectividad de extremo a extremo

Pruebe la conectividad desde varias ubicaciones con traceroute o MTR para confirmar que el tráfico sigue las rutas previstas hacia su nueva subred:

# Traceroute para verificar la ruta

traceroute -n yourdomain.com

# MTR para monitorizar la ruta de forma continua (-r modo informe, -n sin resolución DNS)

mtr -rn yourdomain.com

Si utiliza BYOIP a través de un proveedor cloud, verifique que el tráfico atraviesa correctamente la infraestructura perimetral del proveedor antes de llegar a sus cargas de trabajo. La guía BYOIP de IPbnb explica los pasos de verificación específicos de AWS, GCP y Azure.

Monitorización de la reputación IP

La reputación IP no es estática después de una migración. Incluso una subred limpia puede acumular señales negativas rápidamente si algo falla: un servidor de correo mal configurado, un proxy abierto o un servicio comprometido pueden hacer que sus nuevas IP acaben en una lista de bloqueo a los pocos días de la migración.

Configure una monitorización continua en:

• Listas negras de correo: Spamhaus (SBL, XBL, PBL), Barracuda, SpamCop; fundamental si su subred gestiona cualquier tipo de correo saliente

• Bases de datos de reputación general: Talos Intelligence, AbuseIPDB, AlienVault OTX

• MXToolbox: útil para obtener una visión consolidada de las listas negras más comunes

Revíselas a las 24 horas, a las 72 horas y una semana después de la migración. Si su nueva subred aparece en una lista negra, investigue el origen de inmediato. Puede indicar un error de configuración o un servicio comprometido en su infraestructura, no necesariamente un problema histórico del propio bloque IP.

Confirme también que los registros PTR están correctamente configurados para la nueva subred. Los registros PTR ausentes o que no coinciden provocan fallos parciales en la entrega del correo y son señalados por muchas herramientas de análisis de seguridad.

Para conocer los pasos detallados de configuración de la subred y cómo configurar correctamente su bloque arrendado desde el principio, la guía de configuración de subredes de IPbnb es la referencia adecuada.

Una última cosa

Una migración de IPv4 satisfactoria es un 80 % preparación y un 20 % ejecución. Los pasos técnicos (actualizar DNS, configurar BGP, reconfigurar servicios) no son complicados. Lo que hace que salgan mal son las auditorías de dependencias incompletas, una planificación insuficiente del TTL y avanzar por las fases demasiado deprisa.

Siga la lista de comprobación. Reduzca el TTL con antelación. Verifique el enrutamiento BGP antes de tocar el DNS. Mantenga la subred antigua activa hasta que el tráfico se haya agotado por completo. Supervise activamente la reputación tras el cambio.

Haga esas cinco cosas y una migración de IP que parece arriesgada se convertirá en una tarea operativa rutinaria.