BYOIP en Google Cloud: trae tus propias direcciones IPv4 a Compute Engine

Demuestras el control del bloque con un ROA que nombra el ASN de Google y un registro PTR que lleva un nombre que te da Google, y luego divides el bloque en prefijos delegados y creas a partir de ellos direcciones externas estáticas.

Esta guía cubre IPv4 en la configuración que recomienda Google, un prefijo regional (v2) en Premium Tier, mediante la gcloud CLI. Las direcciones globales para balanceadores de carga globales usan la configuración v1 más antigua, y antes tu proyecto tiene que estar en una lista de permitidos.

Qué acepta Google Cloud

Según la documentación de Google Cloud, el día que la consultamos:

• Tamaño. Un public advertised prefix de «/16 to /24» (traducción: «de /16 a /24») en Premium Tier, la opción por defecto, o «/16 to /23» (traducción: «de /16 a /23») en Standard Tier, que está en Preview. Puedes dividirlo hasta bloques /28.
• Registro. Google enlaza instrucciones de ROA para cada registro regional, entre ellos ARIN, el RIPE NCC y APNIC. No publica nada sobre el estado PA, PI o legacy, ni sobre a nombre de quién debe estar el bloque.
• Quién lo origina. Google, desde AS396982 en Premium Tier o AS19527 en Standard Tier. No documenta ninguna opción para anunciar desde tu propio ASN.
• Sin solapamiento. «Google does not support overlapping BYOIP route announcements» (traducción: «Google Cloud no admite anuncios de rutas BYOIP solapados»): ni el prefijo ni ninguna parte de él pueden anunciarse en otro sitio mientras Google lo anuncia.
• Regiones. Cada prefijo delegado sirve a una región, o al ámbito global. Las páginas de BYOIP de Google no nombran ninguna región excluida.
• Precio. «There are no charges for idle or in-use IP addresses.» (traducción: «No se cobra por las direcciones IP inactivas ni en uso.»)
• Plazo. «Approximately 2 weeks» (traducción: «unas 2 semanas») para un prefijo v2 tras la validación, «approximately 4 weeks» (traducción: «unas 4 semanas») para los v1 y los globales. El aprovisionamiento «cannot be accelerated» (traducción: «no puede acelerarse»).
• Recursos. La mayoría de los que aceptan una dirección externa estática, pero no los nodos y Pods de GKE ni la dirección externa de una pasarela Cloud VPN. Las direcciones no pueden pasar de un proyecto a otro.

Antes de empezar

Un ROA para el ASN de Google. En Premium Tier nombra el prefijo, su longitud exacta y AS396982. En Standard Tier nombra AS19527, ya sea en un ROA por cada prefijo que vayas a aprovisionar, como recomienda Google, o en un solo ROA con una longitud máxima de /24 (RPKI y ROA).

Un segunda ROA para tu propio ASN. Google recomienda uno con los mismos datos y tu ASN como origen, para que las redes que validan el origen de las rutas no consideren inválido el prefijo si alguna vez lo anuncias tú.

Control del DNS inverso. Google comprueba la propiedad con un registro PTR, no con un token en el registro. Eliges una dirección sin usar del prefijo, Google devuelve un nombre (su secreto compartido) y publicas un registro PTR para esa dirección que apunta a ese nombre bajo tu dominio.

Nada más del registro. Google no pide certificado, Letter of Authorization ni objeto route. Por su parte, necesitas el rol Compute Public IP Admin (roles/compute.publicIpAdmin) en el proyecto.

Paso a paso

01Crea el public advertised prefix, indicando la dirección que usarás para la validación DNS:

gcloud compute public-advertised-prefixes create pap-203-0-113-0-24 \
    --range=203.0.113.0/24 \
    --pdp-scope=REGIONAL \
    --dns-verification-ip=203.0.113.144

Para Standard Tier, usa gcloud beta y añade --network-tier=STANDARD.

02Publica el registro PTR. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' da el nombre. Si es 55kk88tt00 y tu dominio es example.net, entonces dig +short -x 203.0.113.144 debe devolver 55kk88tt00.example.net.

03Lanza la validación:

gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --status=PTR-CONFIGURED

El estado pasa a VALIDATED, o a REVERSE_DNS_LOOKUP_FAILED si Google no encuentra el registro. El aprovisionamiento ha terminado cuando describe con --format='value(status)' muestra PREFIX_CONFIGURATION_COMPLETE.

04Delega un bloque a una región. Puedes hacerlo mientras esperas:

gcloud compute public-delegated-prefixes create pdp-203-0-113-0-25 \
    --public-advertised-prefix=pap-203-0-113-0-24 \
    --range=203.0.113.0/25 \
    --region=europe-west4

05Crea direcciones. Los prefijos delegados públicos regionales creados después del 13 de diciembre de 2025 permiten direcciones sueltas:

gcloud compute addresses create web-1 --network-tier=PREMIUM \
    --ip-collection=pdp-203-0-113-0-25 --addresses=203.0.113.10 --region=europe-west4

Los prefijos más antiguos y las direcciones globales toman bloques enteros, mediante delegated-sub-prefixes create --create-addresses. Asocia las direcciones a VM o a forwarding rules. Todavía no son alcanzables.

06Anuncia. Asegúrate de que ninguna otra red anuncia el bloque. Anuncia primero el prefijo delegado, que Google lleva dentro de su propia red, y luego el advertised prefix, que sale a internet desde todos los puntos de presencia de Google:

gcloud compute public-delegated-prefixes update pdp-203-0-113-0-25 --region=europe-west4 --announce-prefix
gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --announce-prefix

Desde fuera, el validador de RIPEstat debería dar el prefijo como válido para AS396982: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Errores que cuestan un día

• Dos redes anunciando. El solapamiento incluye una ruta más específica: cuenta un /24 anunciado en otro sitio dentro de un /23 que traes. Google advierte de «unexpected routing and packet loss» (traducción: «enrutamiento inesperado y pérdida de paquetes»).
• v1 se anuncia solo. Un prefijo global (v1) se anuncia en cuanto se aprovisiona su prefijo delegado. Google dice que no crees prefijos delegados hasta que nadie más anuncie el bloque.
• Un ROA caducado. Si el ROA caduca y no lo renuevas en las cuatro semanas siguientes al aviso de renovación de Google, Google deja de anunciar el prefijo.
• Los nombres y las regiones son fijos. Cambiar el nombre de un prefijo supone eliminarlo y volver a crearlo, y trasladar un prefijo delegado a otra región «can take approximately eight weeks» (traducción: «puede llevar unas ocho semanas»). Elige nombres como pap-203-0-113-0-24 y delega solo lo que tengas claro.
• Quitar el ROA demasiado pronto. Tras eliminar un public advertised prefix, espera 14 días antes de quitar el ROA para el ASN de Google.

Si alquilas el bloque

Google no publica ninguna regla sobre a nombre de quién está registrado el bloque, y no pide Letter of Authorization. Sus dos comprobaciones, el ROA y el registro PTR, dependen ambas del titular de un bloque alquilado. El titular crea el ROA para AS396982 o AS19527, y el de tu ASN si lo quieres. El titular también crea el registro PTR con el nombre de Google, o delega la zona inversa del bloque en servidores de nombres que controlas tú. Acordad que el ROA se renueve mientras Google anuncie el bloque, y que se mantenga 14 días después de que te vayas.

Dónde encaja RTM Networks

Alquilamos /24 y mayores de nuestro propio espacio de direcciones del RIPE NCC, y vendemos bloques en las regiones RIPE NCC, ARIN y APNIC. Para el espacio que nos alquilas, creamos el ROA para el ASN de Google y el registro PTR con el nombre de Google (alquilar IPv4). Si necesitas menos de 256 direcciones en una VM de Compute Engine, anunciamos nosotros un bloque y lo entregamos por GRE o WireGuard, en cualquier tamaño hasta una sola dirección (túneles GRE y WireGuard). Cómo se suma el cargo por hora de IPv4 en las grandes nubes: el coste real de IPv4 en la nube. Otros proveedores: guías BYOIP.