Lleva tus propias direcciones con Google Cloud

Con el INTERLIR Marketplace, tienes la flexibilidad de usar las direcciones IP rentadas como Bring Your Own IP (BYOIP) con Google Cloud. BYOIP te permite aprovisionar y utilizar tus propias direcciones IPv4 públicas para tus recursos en Google Cloud. Esta característica permite una integración perfecta de tus direcciones IP existentes con la plataforma de Google Cloud, brindándote mayor control y comodidad en la gestión de tu infraestructura de red.

Una vez que las direcciones IP se importan a Google Cloud a través de BYOIP, Google las administra de manera similar a sus propias direcciones IP provistas, con algunas excepciones:

Las direcciones IP importadas están exclusivamente disponibles para el cliente que las trajo, lo que garantiza su uso dedicado.
No hay cargos por direcciones IP inactivas o en uso, lo que proporciona eficiencia de costos para el cliente.

Google Cloud no permite anuncios de rutas BYOIP que se superpongan. Esto significa que si un rango de direcciones IP, como 203.0.112.0/23, o un subconjunto de él, como 203.0.112.0/24, ya se está anunciando fuera de Google, no se admite la importación del mismo rango o un subconjunto de él en Google Cloud. Tener anuncios de rutas superpuestas con longitudes de prefijo coincidentes o no coincidentes entre Google y otra red puede provocar problemas de enrutamiento inesperados y pérdida de paquetes.

Para gestionar el anuncio de ruta de tu prefijo importado, Google Cloud ofrece una función llamada migración en vivo (live migration). La migración en vivo te permite controlar el momento en que Google Cloud comienza a anunciar rutas para tu rango de direcciones IP importado. Sin embargo, es importante tener en cuenta que la migración en vivo no está disponible de forma predeterminada y debe solicitarse a Google Cloud. Para solicitar acceso a la función de migración en vivo, puedes comunicarte con tu representante de Google Cloud.

Un resumen

Para llevar tus propias IP a Google Cloud, primero debes crear un prefijo de anuncio público (PAP). Se realiza una verificación de propiedad para este PAP a través del uso de la Autorización de Origen de Ruta (ROA) y la validación inversa de DNS. Después de una verificación exitosa, se configura el anuncio de este PAP a internet, pero el prefijo no se anuncia hasta que se somete a aprovisionamiento. El proceso de aprovisionamiento para el prefijo de anuncio público generalmente lleva hasta cuatro semanas.

Durante el período de espera para el aprovisionamiento, divides el prefijo en prefijos públicos delegados (PDP). Estos PDP pueden tener alcance regional o global, y tienes la opción de dividirlos aún más o utilizarlos para crear direcciones IP asignables. El aprovisionamiento del prefijo público delegado también lleva hasta cuatro semanas.

Una vez que se completa el aprovisionamiento del prefijo público delegado, entonces se anuncia el prefijo de anuncio público a internet. Si estás utilizando migración en vivo, puede haber pasos adicionales involucrados, por lo que se recomienda consultar las guías específicas para el uso de migración en vivo proporcionadas por Google Cloud.

Prefijos de Anuncio Público

Un prefijo de anuncio público (PAP) es un recurso dentro de Compute Engine de Google Cloud que te permite llevar tu propio prefijo de IP a la plataforma. Esto te permite asignar direcciones IP de tu propio prefijo a los recursos de Google Cloud. El PAP representa una única unidad de anuncio de ruta, y la infraestructura global de Google lo anuncia desde todos sus puntos de presencia. Las direcciones IP dentro del prefijo de anuncio público siempre utilizan el nivel Premium de Network Service Tiers.

Al crear un nuevo prefijo de anuncio público, debe tener un rango de IP IPv4 con un rango CIDR mínimo de /24. No es posible crear un nuevo prefijo de anuncio público con un rango CIDR más pequeño, como /25. Sin embargo, una vez creado el prefijo de anuncio público, tienes la flexibilidad de dividirlo en prefijos públicos delegados más pequeños, como /24 o /23.

Prefijos Públicos Delegados

Un prefijo público delegado (PDP) es un bloque de IP específico dentro de tu prefijo de anuncio público que se configura para operar dentro de un alcance definido, que puede ser una región específica o global en Google Cloud. Antes de poder asignar direcciones IP a tu proyecto u organización, estos bloques de IP deben ser delegados y asignados a un alcance específico.

Google Cloud proporciona la flexibilidad de dividir un prefijo de anuncio público en varios prefijos públicos delegados. Cada uno de estos prefijos públicos delegados puede configurarse con su propio alcance en tus proyectos de Google Cloud. Además, tienes la opción de dividir aún más un único prefijo público delegado en varios bloques más pequeños, pero es importante tener en cuenta que estos bloques más pequeños deben tener el mismo alcance que el bloque principal. Dentro de un alcance determinado, también puedes configurar múltiples prefijos públicos delegados no contiguos, que también se conocen como subprefijos.

Direcciones IP

Una vez que se crean direcciones IP a partir de un prefijo público delegado, están restringidas para su uso dentro del proyecto y alcance específico al que se les asigna. Cualquier usuario con los permisos IAM adecuados en el proyecto puede utilizar estas direcciones IP para sus fines designados:

compute.addresses. * para direcciones IP regionales

compute.globalAddresses. * para direcciones IP globales

Papel de administrador de IP públicas

Para designar un administrador para tus prefijos y direcciones BYOIP, puedes otorgarle el papel de Administrador de IP Públicas de Compute (roles/compute.publicIpAdmin). Con este rol, obtienen la capacidad de gestionar IPs públicas enrutables dentro de tu organización.

Las tareas del Administrador de IP Públicas incluyen:

Configurar prefijos de anuncio público dentro de su propio proyecto.
Establecer prefijos públicos delegados utilizando los prefijos de anuncio público configurados dentro de su propio proyecto.
Delegar subprefijos de los prefijos públicos delegados a proyectos específicos dentro de la organización.
Revocar subprefijos previamente delegados de los prefijos públicos delegados para proyectos específicos dentro de la organización.
Eliminar prefijos públicos delegados.

Planificación de su implementación

Una planificación efectiva es crucial al implementar direcciones BYOIP, ya que los procesos de provisión y eliminación pueden llevar varias semanas en completarse. Para ayudar en el proceso de planificación, considere las siguientes decisiones:

Responsabilidad de Administración: Determine quién será responsable de administrar las direcciones BYOIP. Por lo general, esto es un administrador o un grupo específico, distinto de aquellos que gestionan proyectos individuales. Utilice roles y permisos de IAM para diferenciar los privilegios para los prefijos de anuncio público y delegados.

Gestión de Prefijos: Considere cómo se administrarán los prefijos en diferentes proyectos. Se recomienda gestionar centralmente los prefijos en un proyecto dedicado, separado de los proyectos donde se utilizarán las direcciones IP. Este aislamiento ayuda a evitar confusiones y el uso no autorizado de los prefijos.

Convención de Nombres: Cada recurso BYOIP (prefijo de anuncio público, prefijo de anuncio público delegado, subprefijo) requiere un nombre para fines de gestión. Seleccione nombres descriptivos y fáciles de gestionar durante la creación del recurso, ya que no se pueden cambiar sin recrear el recurso.

Ubicaciones de Provisión: Considere el proceso de provisión como «abastecer» IPs en regiones o el alcance global. Planifique e implemente prefijos públicos delegados con suficiente antelación a su necesidad real, ya que la provisión lleva varias semanas. Si no está seguro de dónde se utilizarán las IPs, provea solo los prefijos necesarios de inmediato. Mover un prefijo público delegado requiere su eliminación y recreación, lo que puede llevar hasta ocho semanas. Una vez completada la provisión, delegue subprefijos a proyectos y cree direcciones para su uso con recursos.

Para ilustrar, supongamos que tiene un prefijo de anuncio público /24 y necesita IPs en us-central1 y para equilibradores de carga globales, con algunas reservadas para uso futuro. Podría crear el siguiente plan:

Prefijo de Anuncio Público: 203.0.113.0/24
Prefijo de Anuncio Público Delegado: 203.0.113.0/28 (para us-central1)
Prefijo de Anuncio Público Delegado: 203.0.113.16/28 (para global)
IP restantes reservadas para uso futuro.

Al planificar con anticipación y gestionar eficazmente los prefijos, puede garantizar una implementación sin problemas de direcciones BYOIP en sus proyectos de Google Cloud.

Migración en tiempo real (Live Migration)

La migración en tiempo real es una potente función que le permite importar un prefijo BYOIP cuando alguna parte del prefijo ya está anunciada públicamente. Requiere una planificación y ejecución cuidadosas para evitar enrutamientos inesperados y pérdida de paquetes.

Para utilizar la migración en tiempo real, asegúrese de que el prefijo que está importando no esté siendo anunciado públicamente. La migración en tiempo real no está ampliamente disponible, así que contacte a su representante de Google Cloud para solicitar acceso antes de crear un prefijo delegado público con la migración en tiempo real habilitada.

Para habilitar la migración en tiempo real, debe crear un prefijo delegado público y asegurarse de que todos los prefijos delegados públicos dentro del prefijo anunciado públicamente tengan un alcance regional, no global.

Además, asegúrese de que ninguna dirección IP dentro del rango del prefijo anunciado públicamente esté asignada a ningún recurso. Siguiendo estas recomendaciones y configuraciones, puede evitar que Google anuncie el prefijo anunciado públicamente a sus pares durante el proceso de migración.

La Figura 2 ilustra las diferentes configuraciones en un proyecto, con una que evita que el prefijo sea anunciado y otras dos que causan que el prefijo anunciado públicamente sea anunciado. Administrando cuidadosamente el alcance y las asignaciones de direcciones IP garantizará una migración en tiempo real exitosa de su prefijo BYOIP.

La Figura 2 presenta tres escenarios para ilustrar los resultados del uso de la migración en tiempo real para prefijos delegados públicos dentro de un prefijo anunciado públicamente:

En el primer ejemplo de proyecto, todos los prefijos delegados públicos en el prefijo anunciado públicamente tienen la migración en tiempo real habilitada, pero ninguna máquina virtual (VM) está configurada con direcciones IP de este prefijo. Como resultado, el prefijo anunciado públicamente no se anuncia.

En el segundo ejemplo de proyecto, todos los prefijos delegados públicos en el prefijo anunciado públicamente tienen la migración en tiempo real habilitada, y una VM está configurada con una dirección IP de este prefijo. En este caso, el prefijo anunciado públicamente se anuncia.

En el tercer ejemplo de proyecto, un prefijo delegado público dentro del prefijo anunciado públicamente no está configurado con la migración en tiempo real habilitada, pero ninguna VM está configurada con direcciones IP de este prefijo. A pesar de que los otros prefijos delegados tienen la migración en tiempo real habilitada, el prefijo anunciado públicamente todavía se anuncia.

Usted tiene control sobre cuándo comienza la publicación del prefijo anunciado públicamente al asignar direcciones IP de su prefijo delegado público a recursos de Google Cloud. Para obtener información detallada sobre el uso de la migración en tiempo real, consulte la documentación relevante.

Después de completar el proceso de migración en tiempo real, es recomendable que se comunique con su representante de Google Cloud para deshabilitar la migración en tiempo real para su prefijo. Por defecto, la migración en tiempo real se deshabilita 30 días después del inicio de la publicación del prefijo anunciado públicamente. Si necesita que la opción de migración en tiempo real esté disponible por un período más prolongado, asegúrese de comunicarlo a su representante de Google Cloud.

Limitaciones de la migración en tiempo real

Al considerar una migración en tiempo real, es crucial tener en cuenta requisitos y limitaciones específicas:

Los prefijos delegados públicos con migración en tiempo real habilitada no pueden tener alcance global; deben configurarse con alcance regional. Consulte las recomendaciones de migración en tiempo real para administrar la migración en tiempo real con recursos globales.
El prefijo más largo que se puede migrar mediante la migración en tiempo real es un /24, ya que esta es la longitud máxima de prefijo enrutable en internet.
Tenga en cuenta que no todos los pares de Google pueden respetar el prefijo más largo entre dos sitios. Algunos pares pueden no tener tablas de enrutamiento completas, lo que puede llevar a una situación en la que un prefijo más corto anunciado por Google tiene prioridad para esos pares. Esto significa que la existencia de cualquier prefijo de Google tendrá prioridad, incluso si está anunciando una ruta más específica desde su ubicación local.

Por ejemplo, suponga que tiene un prefijo /23 enrutado activamente desde su ubicación local. Planea desagregar el /23 en dos prefijos /24 y anunciar las rutas más específicas desde su ubicación local. Al mismo tiempo, configura un prefijo publicado públicamente /23 para BYOIP. Si bien puede asumir que las rutas más específicas desde su ubicación local tienen prioridad sobre el prefijo BYOIP más corto, esto no siempre es el caso:

Los pares de Google con tablas de enrutamiento completas preferirán los prefijos /24 más específicos desde las ubicaciones locales.

Los pares de Google con tablas de enrutamiento incompletas preferirán el prefijo anunciado públicamente de /23 anunciado por Google ya que sus tablas de enrutamiento carecen de los prefijos más específicos.

Es crucial comprender que si Google recibe tráfico para un prefijo publicado públicamente válido para el cual no ha provisionado servicios, incluso si hay un anuncio activo en la ubicación local para el prefijo, el tráfico no se le entregará. Por ejemplo, si tiene una red en la ubicación local con dos prefijos /24 y un prefijo anunciado públicamente es el agregado /23, migrar un solo /24 a Google y retirar el prefijo en la ubicación local mientras deja el otro /24 activo en la ubicación local puede llevar a que parte del tráfico se enrute a Google para todo el prefijo /23. Esto puede causar confusión ya que el tráfico se entrega a destinos diferentes basados en las rutas de enrutamiento de diversos Sistemas Autónomos. Por lo tanto, es importante planificar y configurar cuidadosamente su migración en tiempo real para evitar problemas de enrutamiento inesperados y asegurar una entrega adecuada del tráfico.

Recomendaciones para la migración en tiempo real

Estas son las prácticas recomendadas para usar la migración en tiempo real:

Desagregue todos los prefijos destinados a la migración en tiempo real en los prefijos más largos que reflejen con precisión cómo desea anunciarlos durante la migración. Por ejemplo, si tiene un prefijo /23, debe desagregarlo en dos prefijos /24 y anunciarlos como tales desde su ubicación local antes de crear el prefijo anunciado públicamente.
Cree solicitudes de Autorización de Origen de Ruta (ROA) con longitud exacta de prefijo y evite depender del parámetro de longitud máxima para que se respete. Esto garantiza una autorización precisa y confiable para los prefijos.
Asegúrese de que existan solicitudes de RPKI ROA tanto para el Número de Sistema Autónomo (ASN) de origen de ubicación local como para el ASN de origen de Google. Tener ROAs adecuadas para ambos orígenes es importante ya que la falta de un ROA para el prefijo de ubicación local mientras se crea un ROA de origen de Google podría hacer que los Proveedores de Servicios de Internet (ISPs) de terceros filtren los prefijos de ubicación local si están utilizando el filtrado automático de RPKI.
Si necesita utilizar la migración en tiempo real, cree prefijos anunciados públicamente separados para recursos globales y recursos regionales. Habilitar la migración en tiempo real en un prefijo delegado público requiere especificar una región para el alcance. No se admite especificar alcance global para un prefijo delegado público con migración en tiempo real habilitada. Al tener prefijos regionales en un prefijo anunciado públicamente y prefijos globales en otro prefijo anunciado públicamente, puede administrarlos por separado. Luego, puede manejar la migración en tiempo real de los recursos regionales mientras trabaja con su representante de Google Cloud para gestionar la migración en tiempo real de los recursos globales. Esta separación permite un mejor control y gestión del proceso de migración en tiempo.

Arquitectura del proyecto

Recomendamos utilizar organizaciones para aprovechar características como permisos de IAM centralizados y Shared VPC, lo que proporciona una mejor gestión de recursos y seguridad en su entorno de Google Cloud.

Administración de direcciones BYOIP en una organización

En este escenario, dentro de una organización, se designa un proyecto separado llamado «Proyecto de IP Pública» para administrar las direcciones BYOIP. El Administrador de IP Pública, quien supervisa la gestión de direcciones IP para la organización, crea el prefijo publicado públicamente y los prefijos delegados públicos dentro de este proyecto.

Cuando un Proyecto de VPC requiere direcciones IP públicas, el Administrador de IP Pública crea las direcciones IP necesarias dentro del Proyecto de VPC.

La organización tiene la flexibilidad de tener varios proyectos, y el Administrador de IP Pública puede delegar direcciones IP a todos ellos desde el «Proyecto de IP Pública» central. Este enfoque centralizado agiliza la gestión de direcciones IP en los proyectos de la organización.

Administración de direcciones BYOIP con Shared VPC

En esta organización con Shared VPC, se designa un proyecto separado llamado «Proyecto de IP Pública» para administrar las direcciones BYOIP. El Administrador de IP Pública, responsable de la gestión de direcciones IP en toda la organización, ha creado el prefijo publicado públicamente y los prefijos delegados públicos dentro de este proyecto central.

Cuando el Proyecto de Host de Shared VPC o los proyectos de servicio relacionados requieren direcciones IP públicas, el Administrador de IP Pública crea las direcciones IP necesarias dentro del Proyecto de Host de Shared VPC. Tanto el proyecto de host como los proyectos de servicio pueden acceder a las direcciones BYOIP desde el proyecto de host.

Es importante tener en cuenta que no se admite la creación de direcciones IP directamente en un proyecto de servicio de Shared VPC; toda la gestión de direcciones IP ocurre dentro del «Proyecto de IP Pública» central y se comparte en los proyectos relevantes dentro de la organización.

Administración de direcciones BYOIP sin una organización

Si su proyecto no forma parte de una organización, no puede crear un proyecto separado únicamente para la administración de direcciones BYOIP. En estos casos, debe crear el prefijo publicado públicamente y los prefijos delegados públicos directamente dentro del mismo proyecto que requiere el uso de direcciones BYOIP.

Evgeny Sevastyanov

Client Support Teamleader