Usa tus propias direcciones IP
Usar tus propias direcciones 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 proporcionadas por 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 Ingeniero de Atención al cliente 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 hace 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 público anunciado, divide el prefijo en prefijos delegados públicos (PDP). 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 migración en vivo, consulta Usa la migración en vivo para obtener pasos adicionales.
Prefijos anunciados públicos
Un prefijo público anunciado (PAP) es un recurso en Compute Engine que representa un prefijo de IP que proporcionas a Google Cloud. Esto te permite asignar direcciones IP de tu propio prefijo a recursos de Google Cloud. El prefijo público anunciado es una sola unidad de anuncio de ruta. La red troncal global de Google anuncia el prefijo público anunciado desde todos sus puntos de presencia. Las direcciones IP en el prefijo público anunciado siempre usan el nivel Premium de los Niveles de servicio de red.
Un prefijo público anunciado se puede usar para crear prefijos delegados públicos globales o prefijos delegados públicos regionales, pero no ambos.
Si el prefijo anunciado público se creó antes del 10 de julio de 2023, consulta Cambios en el comportamiento para BYOIP.
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.
La creación de prefijos delegados públicos globales está restringido. Para obtener más información, consulta Prefijos delegados públicos globales.
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.
Prefijos delegados públicos globales
Para crear un prefijo delegado público global, debes usar un prefijo anunciado público que se use solo para crear prefijos delegados públicos globales. Debes crear el prefijo delegado público en un proyecto al que se le otorgó acceso para crear prefijos globales.
Para solicitar acceso, presenta un caso de asistencia para solicitar que tu proyecto se incluya en la lista de anunciantes permitidos para la creación de prefijos delegados públicos globales.
Direcciones IP
Cuando creas direcciones IP desde un prefijo público delegado, estas solo se pueden usar dentro del proyecto y el permiso al que se asignan. Todas las direcciones IP en el prefijo público delegado o prefijo secundario están disponibles. No hay dirección de red reservada o dirección de transmisión. Por ejemplo, si usas un prefijo o un prefijo secundario delegados /28 para crear direcciones IP, se crean 16 recursos de direcciones IP.
Cualquiera que tenga los permisos de IAM adecuados del proyecto puede usar las direcciones IP:
compute.addresses.*para direcciones IP regionalescompute.globalAddresses.*para direcciones IP globales
Cambios en el comportamiento para BYOIP
Los siguientes cambios de comportamiento entrarán en vigor el 10 de julio de 2023:
- Un prefijo público anunciado se puede usar para crear prefijos delegados públicos globales o prefijos delegados públicos regionales, pero no ambos.
- Los prefijos anunciados públicos que se crearon antes del 10 de julio de 2023 se pueden usar solo para crear prefijos delegados regionales.
- Para crear prefijos delegados públicos globales, debes solicitar acceso.
Las opciones de configuración de prefijos delegados públicos globales y existentes no se ven afectadas.
Puertos abiertos en direcciones BYOIP
Ejecutar un análisis de puerto en una dirección de BYOIP puede mostrar resultados inesperados. Las direcciones globales de BYOIP se implementan mediante un servicio de infraestructura llamado Google Front End (GFE). Una dirección de BYOIP, incluso si no se usa, puede tener puertos abiertos, ya que otros servicios de Google que también comparten el GFE usan estos puertos. El tráfico a estos puertos se descarta y no se registra.
Solo los balanceadores de cargas admitidos pueden usar direcciones IP globales. Para obtener más información sobre los puertos abiertos en balanceadores de cargas, consulta los siguientes vínculos:
- Puertos abiertos en balanceadores de cargas de aplicaciones externos
- Puertos abiertos en balanceadores de cargas de red de proxy externos
Rol 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 hacer 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 con anterioridad 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. Para obtener más información sobre el cronograma de aprovisionamiento y los tamaños de prefijo permitidos, consulta Limitaciones.
Estas son algunas decisiones que debes tener en cuenta cuando planificas tu implementación:
¿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 para 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, si necesitas algunas direcciones IP en
us-central1y algunas direcciones IP para los balanceadores de cargas globales, y deseas reservar algunas direcciones IP para el futuro, debes crear el siguiente plan.Tipo de prefijo Prefijo Permiso Prefijo anunciado publicado 203.0.113.0/24 Prefijo anunciado público para balanceadores de cargas globales 192.0.2.0/24 Prefijo delegado público 203.0.113.0/28 us-central1 Prefijo delegado público 203.0.113.16/28 us-east-4 Prefijo delegado público 192.0.2.0/28 global Las direcciones IP restantes están 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 provocar un enrutamiento inesperado y una pérdida de paquetes.
La migración en vivo tiene disponibilidad limitada. Comunícate con tu Ingeniero de Atención al cliente 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.
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 Ingeniero de Atención al cliente 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 Ingeniero de Atención al cliente.
Limitaciones de la migración en vivo
Cuando planificas una migración en vivo, es importante que comprendas los siguientes requisitos y limitaciones:
La creación de un prefijo público delegado con la migración en vivo habilitada no es compatible si el alcance está configurado como global. Consulta Recomendaciones para la migración en vivo para 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
/24porque/24es 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
/23que se enruta de forma activa desde su ubicación local. El cliente planea dividir/23en dos prefijos/24y 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/23para 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
/24má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/23agregado.El cliente migra un solo
/24a Google y retira el prefijo local, pero deja el otro/24activo 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/24má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
/23debe estar desagregado en dos prefijos/24y 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 Ingeniero de Atención al cliente de Google Cloud para administrar la migración en vivo de los recursos globales.
Arquitectura del proyecto
Recomendamos que uses organizaciones para aprovechar 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.
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.
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.
Cuotas y límites
Hay cuotas y límites para los prefijos delegados públicos (PDP) y los prefijos anunciados públicos (PAP). Para obtener más información, consulta Cuotas y límites de VPC.