Usa tu propia IP

Usa tu propia IP (BYOIP) te permite aprovisionar y usar tus propias direcciones IPv4 públicas para los recursos de Google Cloud. Después de importar las direcciones IP, Google Cloud las administra de la misma manera que las direcciones IP que proporciona Google, con las siguientes excepciones:

  • Las direcciones IP solo están disponibles para el cliente que las trajo.

  • No se aplican cargos por direcciones IP inactivas o en uso.

La migración en vivo te permite controlar cuándo Google comienza a anunciar rutas para tu prefijo. La migración en vivo no está disponible de forma predeterminada. Para solicitar acceso, comunícate con tu representante de Google Cloud.

Descripción general

Para usar tu propia IP en Google, debes crear un prefijo público anunciado (PAP). La verificación de propiedad se realiza para este prefijo público anunciado mediante ROA y la validación inversa de DNS. Una vez que se complete la verificación, configuramos el anuncio de este prefijo en Internet, pero el prefijo no se anunciará hasta que se aprovisione. El prefijo público anunciado tarda hasta cuatro semanas en aprovisionarse.

Mientras esperas a que se aprovisione el prefijo anunciado de forma pública, divide el prefijo en prefijos delegados públicos (PDP), que configuras para tener alcance regional o global. Puedes dividir el prefijo público delegado aún más o usarlo para crear direcciones IP asignables. El prefijo público delegado tarda hasta cuatro semanas en aprovisionarse.

Una vez que se completa el aprovisionamiento del prefijo público delegado, el prefijo público anunciado se anuncia a Internet. Si usas la migración en vivo, consulta Usa la migración en vivo a fin de obtener pasos adicionales.

Figura 1. Flujo de trabajo para crear prefijos públicos anunciados y prefijos delegados públicos.

Prefijos anunciados públicos

Un prefijo público anunciado (PAP) es un recurso en Compute Engine que representa un prefijo de IP agregado que proporcionas a Google Cloud. Esto te permite asignar direcciones IP de tu propio prefijo a recursos de Google Cloud. Este prefijo de IP es una unidad única de anuncio de ruta y se anuncia a nivel global en Internet. El prefijo de IP solo puede pertenecer al nivel Premium de los Niveles de servicio de red y tiene un alcance global.

Cuando se crea un nuevo prefijo anunciado público, debe tener un rango de IP IPv4 con un rango de CIDR mínimo de tamaño /24. No se puede crear un rango CIDR más pequeño, por ejemplo /25, como un nuevo prefijo anunciado público. Sin embargo, una vez creado, puedes dividir un prefijo anunciado público, como /24 o /23, en prefijos delegados públicos más pequeños.

Prefijos delegados públicos

Un prefijo delegado público (PDP) es un bloque IP dentro de tu prefijo anunciado público que se configura dentro de un permiso único (una región específica o global). Los bloques de IP deben estar delegados y asignados a un permiso antes de que puedas asignar direcciones IP a tu organización o proyecto.

Puedes dividir un prefijo anunciado público en varios prefijos delegados públicos y configurar cada uno de ellos con el permiso que desees en tus proyectos de Google Cloud. Puedes dividir un prefijo delegado público único en varios bloques más pequeños, pero estos bloques deben tener el mismo permiso que el bloque superior. Puedes configurar varios prefijos delegados públicos no contiguos en un permiso determinado. Estos bloques más pequeños son prefijos delegados públicos, pero también se denominan prefijos secundarios.

Direcciones IP

Cuando creas direcciones IP a partir de un prefijo público delegado, las direcciones IP solo se pueden usar dentro del proyecto y el alcance a los que se asignan. Cualquiera que tenga los permisos de IAM adecuados del proyecto puede usar las direcciones IP:

  • compute.addresses.* para direcciones IP regionales

  • compute.globalAddresses.* para direcciones IP globales

Función de administrador de IP públicas

Puedes designar un administrador para tus prefijos y direcciones de BYOIP mediante la función de administrador de IP públicas de Compute (roles/compute.publicIpAdmin). Esta función les permite administrar las IP que se pueden enrutar de forma pública en tu organización.

El Administrador de IP públicas puede realizar las siguientes tareas:

  • Configurar prefijos anunciados públicos en un proyecto propio.
  • Configurar los prefijos anunciados públicos en prefijos delegados públicos en un proyecto propio.
  • Delegar prefijos secundarios de los prefijos delegados públicos a proyectos específicos de la organización.
  • Revocar prefijos secundarios que se delegaron previamente de los prefijos delegados públicos a un proyecto específico en la organización.
  • Borrar los prefijos delegados públicos.

Planifica la implementación

Es importante planificar la implementación, ya que los procesos de aprovisionamiento y eliminación requieren varias semanas para completarse. Estas son algunas decisiones que deben considerarse:

  • ¿Quién es responsable de administrar las direcciones de BYOIP? Por lo general, este es un administrador o un grupo, pero no suelen ser los mismos usuarios que administran proyectos individuales. Usa permisos y funciones de IAM a fin de distinguir quién tiene privilegios para los prefijos públicos anunciados y los prefijos delegados públicos que planeas aprovisionar.

  • ¿Cómo se administran los prefijos? Es probable que desees usar tus direcciones de BYOIP en diferentes proyectos. Puedes administrar prefijos de forma centralizada en un proyecto distinto de los destinos finales de las direcciones IP. Recomendamos aislar la administración de prefijos en un proyecto propio, incluidos sus propios usuarios y grupos con permisos de administrador de IP públicas. Este aislamiento ayuda a evitar confusiones sobre la administración de los prefijos y el uso involuntario o no autorizado de los mismos. Para obtener más información, consulta Arquitectura del proyecto.

  • ¿Cómo se denominan los prefijos? Cada recurso de BYOIP (prefijo público anunciado, prefijo delegado público, prefijo secundario) requiere un nombre. El nombre se usa para administrar cada recurso. Debes asignar el nombre durante la creación del recurso, y este no se puede cambiar sin borrar y volver a crear el recurso. Por este motivo, te recomendamos que crees nombres que sean fáciles de administrar. Por ejemplo, pap-203-0-113-0-24, pdp-203-0-113-0-25, sub-203-0-113-0-28, en los que las letras indican el tipo de recurso y los números indican el prefijo específico y la longitud del prefijo.

  • ¿Dónde se aprovisionan las direcciones IP? Es útil pensar en el proceso de aprovisionamiento como "almacenar" IP en regiones (o en el alcance global). El proceso de aprovisionamiento para almacenar direcciones IP tarda varias semanas en completarse, por lo que es útil planificar y, también, implementar prefijos públicos delegados durante mucho tiempo antes de que sean necesarios.

    No es necesario que uses todas las direcciones IP en un prefijo público delegado de inmediato. Si no estás seguro de dónde los necesitas, aprovisiona solo los prefijos delegados públicos que estés seguro que necesitarás usar. Mover un prefijo delegado público requiere la eliminación completa y, luego, la recreación, lo que puede tardar hasta ocho semanas.

    Una vez que se complete el aprovisionamiento de prefijos delegados públicos, puedes delegar prefijos secundarios a proyectos y crear direcciones para usarlos con recursos. Si prevés que necesitas direcciones BYOIP en una región, completa el proceso de aprovisionamiento del prefijo delegado de forma anticipada para que puedas satisfacer las necesidades a pedido.

    Por ejemplo, supongamos que tienes un prefijo anunciado público de /24. Sabes que necesitas algunas direcciones IP en us-central1y algunas direcciones IP para los balanceadores de cargas globales, y que deseas reservar algunas para uso futuro. Puedes crear el siguiente plan:

    Tipo de prefijo Prefijo Permiso
    Prefijo anunciado publicado 203.0.113.0/24
    Prefijo delegado público 203.0.113.0/28 us-central1
    Prefijo delegado público 203.0.113.16/28 global
    Direcciones IP restantes reservadas para uso futuro

Migración en vivo

La migración en vivo es una función potente que requiere una planificación y una ejecución detalladas.

Usa la migración en vivo para importar un prefijo BYOIP cuando alguna parte del prefijo ya se anuncia de forma pública. La importación de un prefijo anunciado sin usar la migración en vivo puede generar enrutamientos inesperados y pérdida de paquetes.

La migración en vivo tiene disponibilidad limitada. Comunícate con tu representante de Google Cloud para obtener acceso antes de crear un prefijo público delegado con la migración en vivo habilitada.

Habilita la migración en vivo cuando creas un prefijo delegado público. Para evitar que Google anuncie el prefijo anunciado público a sus pares, debes asegurarte de lo siguiente:

  • Todos los prefijos delegados públicos dentro del prefijo público anunciado se configuran con un alcance regional, no con un alcance global. Consulta las recomendaciones de la migración en vivo para obtener más información.

  • No se asignan direcciones IP en el rango del prefijo anunciado público a los recursos.

En la Figura 2, se muestra el mismo proyecto con diferentes configuraciones, una de las cuales evita que se anuncie el prefijo, y otras dos que hacen que se anuncie el prefijo anunciado público.

Figura 2. Anuncio del prefijo público anunciado durante la migración en vivo (haz clic para ampliar).

En la figura 2, se ilustran las siguientes situaciones:

  • En el primer ejemplo de proyecto, todos los prefijos delegados públicos del prefijo público anunciado se configuran con la migración en vivo habilitada. No se configuró ninguna VM con direcciones IP de este prefijo.

    Resultado: El prefijo público anunciado no se anunció.

  • En el segundo ejemplo de proyecto, todos los prefijos delegados públicos del prefijo público anunciado se configuran con la migración en vivo habilitada. Una VM se configuró con una dirección IP de este prefijo.

    Resultado: El prefijo público anunciado se anunció.

  • En el tercer ejemplo de proyecto, un prefijo delegado público dentro del prefijo público anunciado no se configuró con la migración en vivo habilitada. No se configuró ninguna VM con direcciones IP de este prefijo.

    Resultado: El prefijo público anunciado se anunció.

Puedes controlar cuándo comienza el anuncio si asignas direcciones IP del prefijo delegado público a los recursos de Google Cloud. Para obtener más información, consulta Usa la migración en vivo.

Después de completar la migración en vivo, comunícate con tu representante de Google Cloud para que pueda inhabilitar la migración en vivo para tu prefijo. De forma predeterminada, la migración en vivo se inhabilita 30 días después de que comiences a anunciar el prefijo anunciado público.. Si necesitas que la opción de migración en vivo esté disponible durante más de 30 días, comunícate con tu representante de Google Cloud.

Limitaciones de la migración en vivo

Cuando planificas una migración en vivo, es importante que comprendas los siguientes requisitos y limitaciones:

  • No se puede crear un prefijo delegado público con la migración en vivo habilitada si el alcance está configurado como global. Consulta Recomendaciones para la migración en vivo a fin de obtener información sobre cómo administrar la migración en vivo para recursos globales.

  • El prefijo más largo que se puede migrar es un /24 porque /24 es la longitud máxima del prefijo enrutable en Internet.

  • No supongas que todos los intercambios de tráfico de Google respetan el prefijo más largo entre dos sitios. Es posible que algunos intercambios de tráfico no tengan tablas de enrutamiento completo. Como resultado, un prefijo más corto que Google anuncia en estos intercambios de tráfico es el único prefijo (y, por lo tanto, el más largo) que el intercambio de tráfico considera. Como resultado, la existencia de cualquier prefijo de Google tiene prioridad, incluso si anuncias una ruta más específica desde tu ubicación local.

    Por ejemplo:

    Un cliente tiene un /23 que se enruta de forma activa desde su ubicación local. El cliente planea desagregar /23 en dos prefijos /24 y anunciar las rutas más específicas desde su ubicación local. Después de la separación, planean configurar un prefijo público anunciado /23 para BYOIP. Suponemos que las rutas más específicas de su ubicación local tienen prioridad sobre el prefijo BYOIP más corto y que el tráfico continúa enrutando a los prefijos locales más específicos.

    Lamentablemente, este plan funciona solo de forma parcial:

    • Los intercambios de tráfico de Google que tienen tablas de enrutamiento completas prefieren los prefijos locales /24 más específicos.

    • Los pares de Google que no tienen tablas de enrutamiento completas prefieren el prefijo anunciado público, anunciado desde Google, ya que sus tablas de enrutamiento no incluyen los prefijos más específicos.

  • Tu tráfico no se entrega si Google recibe tráfico para un prefijo anunciado público para el que no aprovisionaste servicios, incluso si hay un anuncio local activo para el prefijo.

    Por ejemplo:

    Un cliente tiene una red local que consta de dos prefijos /24. Su prefijo público anunciado es el /23 agregado.

    El cliente migra un solo /24 a Google y retira el prefijo local, pero deja el otro /24 activo en la ubicación local.

    Esta configuración da como resultado que parte del tráfico se enrute a Google para todo el prefijo /23, aunque aún haya un prefijo /24 más específico anunciado desde la ubicación local. Esta situación es difícil de diagnosticar, ya que varios sistemas autónomos usan el tráfico hacia tu ubicación local, pero otros entregan a Google, en cuyo caso el tráfico se descarta.

Recomendaciones para la migración en vivo

Como práctica recomendada, sigue estas recomendaciones cuando uses la migración en vivo.

  • Desagrega todos los prefijos de migración en vivo en los prefijos más largos que reflejan cómo deseas anunciar estos prefijos durante la migración. En los ejemplos anteriores, el /23 debe estar desagregado en dos prefijos /24 y debe anunciarse como su ubicación local antes de crear el prefijo anunciado público.

  • Crea solicitudes ROA con una longitud exacta del prefijo y no confíes en el parámetro de longitud máxima que se debe respetar.

  • Asegúrate de que existen las solicitudes ROA de RPKI para el ASN de origen local y el ASN de origen de Google. Si no hay ROA para el prefijo local, la creación de un ROA de origen de Google puede provocar que los ISP de terceros filtren esos prefijos locales si usan el filtrado RPKI automático.

  • Crea prefijos anunciados públicos para recursos globales y recursos regionales si necesitas usar la migración en vivo. Cuando habilitas la migración en vivo en un prefijo delegado público, debes especificar una región para el permiso. No se admite la especificación de permiso global para un prefijo delegado público que tenga habilitada la migración en vivo. Si creas un prefijo anunciado público con permiso global y migración en vivo habilitada, el prefijo se anuncia de inmediato.

    Tener prefijos regionales en un prefijo anunciado público y prefijos globales en otro prefijo anunciado público te permite administrarlos por separado. Puedes administrar la migración en vivo de los recursos regionales y comunicarte con tu representante de Google Cloud para administrar la migración en vivo de los recursos globales.

Arquitectura del proyecto

Te recomendamos que uses organizaciones para beneficiarse de las funciones como los permisos de IAM a nivel de organización y la VPC compartida. Consulta Crea y administra organizaciones para obtener más información sobre el uso de una organización.

Administración de direcciones BYOIP en una organización

En este ejemplo de un proyecto que pertenece a una organización, hay un proyecto dedicado, Public IP Project, que se usa para administrar direcciones de BYOIP. El administrador de IP públicas de la organización creó el prefijo público anunciado y los prefijos delegados públicos en Public IP Project.

Cuando el VPC Project necesita direcciones IP públicas, el administrador de IP pública de la organización crea las direcciones IP en el VPC Project.

La organización puede contener varios proyectos, y el administrador de IP públicas puede delegar direcciones IP a todos ellos desde Public IP Project.

Figure 3. Puedes usar organizaciones y proyectos para administrar direcciones de BYOIP.

Administración de direcciones BYOIP con VPC compartida

En este ejemplo de una organización que contiene una VPC compartida, hay un proyecto dedicado, Public IP Project, que se usa para administrar direcciones de BYOIP. El administrador de IP públicas de la organización creó el prefijo público anunciado y los prefijos delegados públicos en Public IP Project

Cuando Shared VPC Host Project o los proyectos de servicio relacionados necesitan direcciones IP públicas, el administrador de IP públicas de la organización crea las direcciones IP en Shared VPC Host Project. El proyecto host y los proyectos de servicio pueden acceder a las direcciones de BYOIP desde el proyecto host.

No se admite la creación de direcciones IP en un proyecto de servicio de VPC compartida.

Figura 4. Puedes delegar direcciones de BYOIP a un proyecto host de VPC compartida, pero no a un proyecto de servicio de VPC compartida. Sin embargo, un proyecto de servicio puede usar direcciones de BYOIP que fueron delegadas al proyecto host.

Administración de direcciones BYOIP sin una organización

Si usas un proyecto que no pertenece a una organización, no puedes crear un proyecto distinto para la administración de direcciones de BYOIP. Crea el prefijo público anunciado y los prefijos delegados públicos en el mismo proyecto que necesita las direcciones de BYOIP.

¿Qué sigue?