Emparejamiento entre redes VPC

Google Cloud El emparejamiento de redes de VPC conecta dos redes de nube privada virtual (VPC) para que los recursos de cada red puedan comunicarse entre sí. Las redes de VPC emparejadas pueden estar en el mismo proyecto, en proyectos diferentes de la misma organización o en proyectos diferentes de organizaciones distintas.

Especificaciones

El emparejamiento entre redes de VPC te permite hacer lo siguiente:

• Publicar ofertas de software como servicio (SaaS) entre redes de VPCs.
• El peering de redes de VPC funciona con Compute Engine, GKE y el entorno flexible de App Engine.
  • El emparejamiento entre redes de VPC admite clústeres de GKE nativos de VPC mediante el intercambio de rutas de subred.
  • El emparejamiento entre redes de VPC admite clústeres de GKE basados en rutas cuando se configura para intercambiar rutas estáticas.

Conectividad

• El emparejamiento entre redes de VPC permite conectar redes de VPC, no redes antiguas.
• El emparejamiento entre redes de VPC proporciona conectividad IPv4 e IPv6 interna entre pares de redes de VPC. El tráfico de emparejamiento (el tráfico que fluye entre redes emparejadas) tiene la misma latencia, el mismo rendimiento y la misma disponibilidad que el tráfico de la misma red de VPC.
  • El emparejamiento entre redes de VPC no proporciona enrutamiento transitivo. Por ejemplo, si las redes de VPC net-a y net-b están conectadas mediante emparejamiento entre redes de VPC, y las redes de VPC net-a y net-c también están conectadas mediante emparejamiento entre redes de VPC, este último no proporciona conectividad entre net-b y net-c.
  • No puedes conectar dos redes de VPC en modo automático mediante el emparejamiento entre redes de VPC. Esto se debe a que las redes de VPC emparejadas siempre intercambian rutas de subred que usan direcciones IPv4 internas privadas, y cada subred de una red de VPC en modo automático usa un intervalo de direcciones IP de subred que se ajusta al bloque 10.128.0.0/9 CIDR.
  • Puedes conectar una red VPC en modo personalizado a una red VPC en modo automático siempre que la red VPC en modo personalizado no tenga ningún intervalo de direcciones IP de subred que se ajuste a 10.128.0.0/9.
• El emparejamiento entre redes de VPC también proporciona cierta conectividad IPv6 externa a los intervalos de direcciones IPv6 externas de destino de los siguientes recursos cuando se intercambian las rutas a esas direcciones IPv6 externas de destino mediante el emparejamiento entre redes de VPC:
  • Interfaces de red de instancias de máquina virtual (VM) de doble pila y solo IPv6
  • Reglas de reenvío para el reenvío de protocolos externo
  • Reglas de reenvío para balanceadores de carga de red de paso a través externos
• El emparejamiento entre redes de VPC admite la conectividad IPv4 e IPv6. Puedes configurar el emparejamiento entre redes de VPC en una red de VPC que contenga subredes con intervalos de direcciones IPv6.

Administración

• Las redes de VPC emparejadas siguen siendo independientes desde el punto de vista administrativo. Solo se intercambian rutas, según la configuración del emparejamiento.
• Para establecer la conectividad de peering, un administrador de red de cada red de VPC debe crear una conexión de peering con la otra red de VPC. De forma predeterminada, un administrador de red de una red de VPC puede desconectar una conexión de emparejamiento. Puedes cambiar este comportamiento al crear o actualizar la conexión.
• Cada lado de una asociación de peering se configura de forma independiente. El peer solo está activo cuando la configuración de ambos lados coincide. Cualquiera de las partes puede eliminar la asociación de emparejamiento en cualquier momento. Puedes cambiar este comportamiento al crear o actualizar la conexión.
• Crear una conexión de peering no te concede ningún rol de Gestión de Identidades y Accesos (IAM) en la otra red de VPC. Por ejemplo, si tienes el rol Administrador de red de Compute o Administrador de seguridad de Compute en una red, no obtendrás el rol Administrador de red ni Administrador de seguridad en otra red.

Permisos de gestión de identidades y accesos

• Los permisos de gestión de identidades y accesos para crear y eliminar el emparejamiento de redes de VPC se incluyen en el rol Administrador de redes de Compute (roles/compute.networkAdmin).
• Puedes usar un rol personalizado si incluye los siguientes permisos:
  • compute.networks.addPeering
  • compute.networks.updatePeering
  • compute.networks.removePeering
  • compute.networks.listPeeringRoutes

Seguridad de la red

Las redes de VPC conectadas mediante el emparejamiento entre redes de VPC solo intercambian rutas en función de las opciones de intercambio de rutas configuradas por un administrador de red de cada red de VPC.

El emparejamiento de redes VPC no intercambia reglas de cortafuegos de VPC ni políticas de cortafuegos.

En el caso de las reglas de cortafuegos de VPC:

• Las reglas de cortafuegos cuyos destinos se definen mediante etiquetas de red solo se resuelven en instancias de la red de VPC de la regla de cortafuegos. Aunque un administrador de seguridad de una red de VPC emparejada puede usar la misma etiqueta de red para definir los destinos de las reglas de cortafuegos en una red de VPC emparejada, los destinos de las reglas de cortafuegos en la red de VPC emparejada no incluyen instancias de tu red de VPC. Del mismo modo, las reglas de cortafuegos de entrada cuyas fuentes se definen mediante etiquetas de red solo se resuelven en instancias de la red de VPC de la regla de cortafuegos.

• Las reglas de cortafuegos cuyos destinos se definen mediante cuentas de servicio solo se resuelven en instancias de la red de VPC de la regla de cortafuegos. En función de los permisos de gestión de identidades y accesos, un administrador de seguridad de una red de VPC emparejada puede usar la misma cuenta de servicio para definir los destinos de las reglas de cortafuegos en una red de VPC emparejada, pero los destinos de las reglas de cortafuegos en la red de VPC emparejada no incluyen instancias de tu red de VPC. Del mismo modo, las reglas de cortafuegos de entrada cuyas fuentes se definen mediante cuentas de servicio solo se resuelven en instancias de la red de VPC de la regla de cortafuegos.

Las reglas de las políticas de cortafuegos de red pueden usar etiquetas seguras, que son diferentes de las etiquetas de red, para identificar destinos y fuentes:

• Cuando se usa para especificar un destino de una regla de entrada o salida en una política de cortafuegos de red, una etiqueta solo puede identificar destinos en la red VPC a la que se ha asignado la etiqueta.

• Cuando se usa para especificar un origen de una regla de entrada en una política de cortafuegos de red, una etiqueta puede identificar orígenes tanto en la red de VPC a la que se limita la etiqueta como en cualquier red de VPC emparejada que esté conectada a la red de VPC a la que se limita la etiqueta. Para obtener más información, consulta Etiquetas para firewalls.

Todas las redes de VPC contienen reglas de cortafuegos implícitas. Debido a las reglas de cortafuegos de denegación implícita de entrada, los administradores de seguridad de cada red de VPC deben crear reglas de cortafuegos de permiso de entrada o reglas en las políticas de cortafuegos. Las fuentes de esas reglas pueden incluir intervalos de direcciones IP de una red de VPC emparejada.

Debido a las reglas de cortafuegos de salida implícitas, no es necesario que crees reglas de cortafuegos de salida ni reglas en las políticas de cortafuegos para permitir que los paquetes lleguen a los destinos de la red de VPC emparejada, a menos que tus redes incluyan reglas de denegación de salida.

Compatibilidad con DNS

Los recursos de una red de VPC emparejada no pueden usar los nombres DNS internos de Compute Engine creados por una red de VPC local.

Una red de VPC emparejada no puede usar zonas privadas gestionadas de Cloud DNS que solo estén autorizadas para una red de VPC local. Para que los nombres de DNS estén disponibles para los recursos de una red de VPC emparejada, utiliza una de las siguientes técnicas:

• Usa zonas de emparejamiento de Cloud DNS.
• Autoriza (haz visible) la misma zona privada gestionada en todas las redes de VPC emparejadas.

Compatibilidad con balanceadores de carga internos

Los clientes de una red de VPC local pueden acceder a los balanceadores de carga internos de una red de VPC emparejada. Para obtener más información, consulta las secciones Usar el emparejamiento entre redes de VPC de la siguiente documentación sobre balanceadores de carga:

• Balanceadores de carga de red de paso a través internos y redes conectadas
• Balanceadores de carga de red de proxy internos y redes conectadas
• Balanceadores de carga de aplicación internos y redes conectadas

Las redes emparejadas pueden intercambiar rutas estáticas que usen balanceadores de carga de red de paso a través internos como saltos siguientes. Para obtener más información, consulta las opciones de intercambio de rutas.

Grupo de emparejamiento y cuotas

Las cuotas de emparejamiento de VPC dependen de un concepto llamado grupo de emparejamiento. Cada red de VPC tiene su propio grupo de emparejamiento, que está formado por ella misma y por todas las demás redes de VPC conectadas a ella mediante el emparejamiento entre redes de VPC. En el caso más sencillo, si dos redes de VPC, net-a y net-b, están emparejadas entre sí, hay dos grupos de emparejamiento: uno desde la perspectiva de net-a y otro desde la perspectiva de net-b.

Para obtener más información sobre las cuotas de emparejamiento entre redes de VPC, consulta los siguientes artículos:

• Cuotas por red
• Límites efectivos de las cuotas por grupo de emparejamiento

Limitaciones

El emparejamiento entre redes de VPC tiene las siguientes limitaciones.

Los intervalos de IPs de subred no pueden solaparse entre redes de VPC emparejadas

Ningún intervalo de IPs de subred puede coincidir exactamente, contener o ajustarse a otro intervalo de IPs de subred en una red de VPC emparejada. En el momento del emparejamiento,Google Cloud comprueba si existen subredes con intervalos de IP superpuestos. Si es así, el emparejamiento falla. En el caso de las redes ya emparejadas, si realizas una acción que dé como resultado la creación de una nueva ruta de subred,Google Cloud la nueva ruta de subred debe tener un intervalo de direcciones IP de destino único.

Antes de crear subredes, puedes listar las rutas de las conexiones de peering para asegurarte de que el intervalo de direcciones IPv4 de la nueva subred no se esté usando ya.

Esta limitación y las comprobaciones correspondientes de Google Cloudtambién se aplican a situaciones como las siguientes:

• Tu red de VPC, network-1, está emparejada con una segunda red de VPC, network-2.
• network-2 también está emparejada con una tercera red de VPC, network-3.
• network-3 no está emparejada con network-1.

En este caso, debes coordinarte con un administrador de red para la network-2. Pide al administrador de la red que network-2 liste las rutas de peering en su red de VPC.

Para obtener más información sobre las comprobaciones de superposición, consulta Interacciones de rutas de subred y subred de emparejamiento.

Los nombres de DNS internos no se resuelven en redes emparejadas

Los nombres de DNS interno de Compute Engine creados en una red no son accesibles para las redes emparejadas. Para acceder a las instancias de VM de la red emparejada, usa la dirección IP de la VM.

Las etiquetas y las cuentas de servicio no se pueden usar en redes emparejadas

No puedes hacer referencia a una etiqueta o cuenta de servicio perteneciente a una VM de una red emparejada en una regla de cortafuegos de la otra red emparejada. Por ejemplo, si una regla de entrada de una red emparejada filtra su origen en función de una etiqueta, solo se aplicará al tráfico de las máquinas virtuales que proceda de esa red, no de sus redes emparejadas, aunque una máquina virtual de una red emparejada tenga esa etiqueta. Esta situación se aplica de forma similar a las cuentas de servicio.

Opciones de intercambio de rutas

Cuando una red de VPC comparte rutas locales con una red de VPC emparejada, exporta las rutas. La red de VPC emparejada puede importar las rutas. Las rutas de subred, excepto las rutas de subred IPv4 que usan direcciones IPv4 públicas utilizadas de forma privada, siempre se intercambian.

La configuración de emparejamiento entre redes de VPC te permite controlar lo siguiente:

• Si se intercambian rutas IPv6. Configurar una conexión de emparejamiento de doble pila te permite intercambiar rutas IPv6 de subredes de doble pila y solo IPv6.
• Si se exportan o importan rutas de subredes que usan direcciones IPv4 públicas usadas de forma privada.
• Si se exportan o importan rutas estáticas y dinámicas.

Puede actualizar la configuración antes de que se haya establecido el peer o mientras la conectividad de peer esté activa.

El emparejamiento entre redes de VPC no proporciona lo siguiente:

• Un método granular para controlar el intercambio de rutas de subred, rutas estáticas y rutas dinámicas específicas.
• Se admite el intercambio de rutas basadas en políticas.

Opciones para intercambiar rutas de subred

En la siguiente tabla se describen las opciones de intercambio de rutas de subredes:

Tipo de ruta	Condiciones de exportación de rutas	Condiciones para importar rutas
Rutas de subred IPv4 (intervalos de subred IPv4 principales y secundarios) que usan intervalos de direcciones IPv4 privadas	Siempre exportado No se puede inhabilitar	Siempre importado No se puede inhabilitar
Rutas de subred IPv4 (intervalos de subred IPv4 principales y secundarios) que usan intervalos de direcciones IPv4 públicas usadas de forma privada	Exportado de forma predeterminada La exportación se controla mediante la marca --export-subnet-routes-with-public-ip.	No se importa de forma predeterminada La importación se controla mediante la marca --import-subnet-routes-with-public-ip.
Intervalos de subredes IPv6 internas (ipv6-access-type=INTERNAL)	No se exporta de forma predeterminada La exportación se habilita definiendo --stack-type=IPV4_IPV6	No se importa de forma predeterminada La importación se habilita al definir --stack-type=IPV4_IPV6
Intervalos de subred IPv6 externos (ipv6-access-type=EXTERNAL)	No se exporta de forma predeterminada La exportación se habilita definiendo --stack-type=IPV4_IPV6	No se importa de forma predeterminada La importación se habilita al definir --stack-type=IPV4_IPV6

Opciones para intercambiar rutas estáticas

En la siguiente tabla se describen las opciones de intercambio de rutas para las rutas estáticas.

Tipo de ruta	Condiciones de exportación de rutas	Condiciones para importar rutas
Rutas estáticas con etiquetas de red (todos los tipos de siguiente salto)	No se puede exportar	No se pueden importar
Rutas estáticas que usan el siguiente salto de la pasarela de Internet predeterminada	No se puede exportar	No se pueden importar
Rutas estáticas IPv4 (sin etiquetas de red) que usan un siguiente salto distinto de la pasarela de Internet predeterminada	No se exporta de forma predeterminada La exportación se controla mediante la marca --export-custom-routes.	No se importa de forma predeterminada La importación se controla mediante la marca --import-custom-routes.
Rutas estáticas IPv6 (sin etiquetas de red) que usan una instancia de VM como siguiente salto	No se exporta de forma predeterminada La exportación se controla mediante la marca --export-custom-routes cuando el tipo de pila del peering se define como --stack-type=IPV4_IPV6	No se importa de forma predeterminada La importación se controla mediante la marca --import-custom-routes cuando el tipo de pila del peering se define como --stack-type=IPV4_IPV6.

Opciones para intercambiar rutas dinámicas

En la siguiente tabla se describen las opciones de intercambio de rutas para las rutas dinámicas.

Tipo de ruta	Condiciones de exportación de rutas	Condiciones para importar rutas
Rutas IPv4 dinámicas	No se exporta de forma predeterminada La exportación se controla mediante la marca --export-custom-routes.	No se importa de forma predeterminada La importación se controla mediante la marca --import-custom-routes.
Rutas IPv6 dinámicas	No se exporta de forma predeterminada La exportación se controla mediante la marca --export-custom-routes cuando el tipo de pila del peering se define como --stack-type=IPV4_IPV6	No se importa de forma predeterminada La importación se controla mediante la marca --import-custom-routes cuando el tipo de pila del peering se define como --stack-type=IPV4_IPV6.

Ventajas de intercambiar rutas estáticas y dinámicas

Cuando una red de VPC exporta rutas estáticas y dinámicas, y la otra red de VPC importa esas rutas, la red importadora puede enviar paquetes directamente al siguiente salto de cada ruta estática o dinámica importada cuyo siguiente salto esté en la red de VPC emparejada.

Un administrador de red de una red de VPC local controla la exportación de las rutas estáticas y dinámicas de esa red (ambas a la vez) mediante la marca --export-custom-routes. Un administrador de red de la red de VPC emparejada correspondiente controla la importación de esas rutas estáticas y dinámicas mediante la marca --import-custom-routes. Para obtener más información, consulta los artículos Rutas ignoradas, Interacciones entre rutas de subred y de subred de peering e Interacciones entre rutas de subred y estáticas.

Importar rutas estáticas y dinámicas de una red de VPC emparejada puede ser útil en los siguientes casos:

• Si la red de VPC emparejada contiene clústeres de GKE basados en rutas y necesitas enviar paquetes a los pods de esos clústeres. Las direcciones IP de los pods se implementan como intervalos de destino de las rutas estáticas ubicadas en la red de VPC emparejada.

• Si necesitas proporcionar conectividad entre una red on-premise y una red de VPC emparejada. Supongamos que una red de VPC local contiene rutas dinámicas con un túnel de Cloud VPN, una vinculación de Cloud Interconnect (VLAN) o un dispositivo router de salto siguiente que se conecta a una red on-premise. Para proporcionar una ruta desde la red VPC emparejada a la red on‐premise, un administrador de red de la red VPC local habilita la exportación de rutas personalizadas y un administrador de red de la red VPC emparejada habilita la importación de rutas personalizadas. Para proporcionar una ruta desde la red on-premise a la red de VPC emparejada, un administrador de red de la red de VPC local debe configurar el modo de anuncio personalizado de Cloud Router en el router de Cloud Router que gestiona la sesión de BGP de la vinculación de Cloud VPN, Cloud Interconnect (VLAN) o el dispositivo de router que se conecta a la red on-premise. El contenido de esas rutas anunciadas personalizadas debe incluir los intervalos de direcciones IP de subred de la red de VPC emparejada.

Rutas ignoradas

Aunque una red de VPC importe una ruta, puede ignorarla en situaciones como las siguientes:

• Cuando la red de VPC local tiene una ruta con un destino idéntico o más específico (máscara de subred más larga), la red de VPC local siempre usa su ruta local.

• Cuando la red de VPC local no contiene la ruta más específica al destino de un paquete, pero dos o más redes de VPC emparejadas contienen el mismo destino más específico para el paquete,Google Cloud usa un algoritmo interno para seleccionar un siguiente salto de solo una de las redes de VPC emparejadas. Esta selección se lleva a cabo antes de que se tenga en cuenta la prioridad de la ruta y no puedes configurar el comportamiento. Como práctica recomendada, evite esta configuración, ya que añadir o quitar redes VPC emparejadas puede provocar cambios no deseados en el orden de enrutamiento.

Para obtener más información sobre las situaciones anteriores, consulta Orden de enrutamiento.

En el caso de los emparejamientos de doble pila, si una red de VPC local que importa rutas IPv6 no tiene ninguna subred de doble pila o solo IPv6, no se podrá usar ninguna de las rutas IPv6 que reciba de las redes de VPC emparejadas. Además, si se ha definido la restricción de la política de la organización constraints/compute.disableAllIpv6, es posible que un administrador de red no pueda crear subredes con intervalos de direcciones IPv6.

Interacciones de rutas de subred y de subred de emparejamiento

Las rutas de subred IPv4 de las redes de VPC emparejadas no pueden solaparse:

• El peering prohíbe las rutas de subred IPv4 idénticas. Por ejemplo, dos redes de VPC emparejadas no pueden tener ambas una ruta de subred IPv4 cuyo destino sea 100.64.0.0/10.
• El emparejamiento impide que una ruta de subred se incluya en otra ruta de subred de emparejamiento. Por ejemplo, si la red de VPC local tiene una ruta de subred cuyo destino es 100.64.0.0/24, ninguna de las redes de VPC emparejadas puede tener una ruta de subred cuyo destino sea 100.64.0.0/10.

Google Cloud aplica las condiciones anteriores a las rutas de subred IPv4 en los siguientes casos:

• Cuando conectas redes de VPC por primera vez mediante el emparejamiento entre redes de VPC.
• Mientras las redes estén emparejadas.
• Cuando haces un cambio en la configuración del emparejamiento, por ejemplo, habilitar la importación de rutas IPv4 de subred con direcciones IP públicas utilizadas de forma privada.

Mientras se conectan las redes entre sí, Google Cloud devuelve un error si alguna de las siguientes operaciones da como resultado una superposición:

• Añadir una subred.

• Añadir un intervalo de direcciones IPv4 secundarias de una subred.

• Ampliar el intervalo de direcciones IPv4 principales de la subred.

Las rutas de subred IPv6 (tanto internas como externas) son únicas por definición. No pueden usar los mismos intervalos de subredes IPv6 internas o externas. Por ejemplo, si una red de VPC usa fc:1000:1000:1000::/64 como intervalo de subred IPv6, ninguna otra red de VPC de Google Cloud puede usar fc:1000:1000:1000::/64, independientemente de si las redes de VPC están conectadas mediante el emparejamiento entre redes de VPC.

Interacciones de subredes y rutas estáticas

Google Cloud requiere que las rutas de subred y las rutas de subred de emparejamiento tengan los intervalos de destino IPv4 o IPv6 más específicos. En cualquier red de VPC, una ruta estática local no puede tener un destino que coincida exactamente o que se ajuste a una ruta de subred local. Para obtener más información sobre este caso, consulta Interacciones con rutas estáticas.

Este concepto se extiende al emparejamiento entre redes de VPC mediante las dos reglas siguientes:

• Una ruta estática local no puede tener un destino que coincida exactamente con una ruta de subred de emparejamiento o que se ajuste a ella. Si existe una ruta estática local,Google Cloud aplica lo siguiente:

  • No puedes establecer una nueva conexión de peering con una red VPC que ya contenga una ruta de subred que coincida exactamente con el destino de la ruta estática local o que lo contenga si la configuración del peering da como resultado la importación de la ruta de subred en conflicto. Por ejemplo:

    • Si existe una ruta estática local con el destino 10.0.0.0/24, no puedes establecer una nueva conexión de peering con una red VPC que contenga una ruta de subred IPv4 cuyo destino coincida exactamente con 10.0.0.0/24 o contenga 10.0.0.0/24 (por ejemplo, 10.0.0.0/8).

    • Cuando el tipo de pila de emparejamiento previsto es IPV4_IPV6, si existe una ruta estática local con el destino 2001:0db8:0a0b:0c0d::/96, no puedes establecer una nueva conexión de emparejamiento con una red de VPC que contenga una ruta de subred IPv6 cuyo destino coincida exactamente con 2001:0db8:0a0b:0c0d::/96 o lo contenga. En esta situación, el único intervalo de direcciones IPv6 de subred posible es 2001:0db8:0a0b:0c0d::/64, ya que los intervalos de direcciones IPv6 de subred en Google Cloud deben usar longitudes de máscara de subred de 64 bits.

  • No puedes actualizar una conexión de peering si la configuración de peering actualizada provoca que se importe la ruta de subred en conflicto. Por ejemplo:

    • Supongamos que dos redes de VPC ya están emparejadas, pero no exportan ni importan rutas de subred IPv4 mediante intervalos de direcciones IPv4 públicas utilizadas de forma privada. En la primera red de VPC, hay una ruta estática local con el destino 11.0.0.0/24, y en la red de VPC emparejada, hay una ruta de subred con el destino 11.0.0.0/8. No puedes configurar simultáneamente la red de VPC emparejada para exportar rutas de subred mediante direcciones IPv4 públicas usadas de forma privada y configurar la primera red de VPC para importar rutas de subred mediante direcciones IPv4 públicas usadas de forma privada.

    • Supongamos que dos redes de VPC ya están emparejadas y que el tipo de pila de emparejamiento es solo IPv4. En la primera red de VPC, hay una ruta estática local con el destino 2001:0db8:0a0b:0c0d::/96, y en la red de VPC emparejada, hay una ruta de subred IPv6 con el destino 2001:0db8:0a0b:0c0d::/64. No puedes cambiar el tipo de pila de emparejamiento a IPV4_IPV6.

  • Por el contrario, si las redes de VPC ya están conectadas mediante el emparejamiento entre redes de VPC, no puedes realizar las siguientes operaciones:

    • Crea una ruta estática local cuya ruta de destino coincida exactamente con una ruta de subred de peering importada o se ajuste a ella.

    • Crea un intervalo de direcciones de subred en la red de VPC emparejada si ese intervalo coincide exactamente con una ruta estática local o la contiene.

• Una ruta estática de emparejamiento no puede tener un destino que coincida exactamente o que se ajuste a una ruta de subred local. Si existe una ruta de subred local, Google Cloud prohíbe lo siguiente:

  • No puedes establecer una nueva conexión de emparejamiento con una red VPC que ya contenga una ruta estática que coincida exactamente con el destino de la ruta de subred de la red VPC local o que se ajuste a él, si la configuración del emparejamiento da como resultado la importación de la ruta estática del par. Por ejemplo:

    • Si existe una ruta de subred local para 10.0.0.0/8, no puedes establecer una conexión de emparejamiento con una red VPC que tenga una ruta estática cuyo destino coincida exactamente con 10.0.0.0/8 o esté dentro de 10.0.0.0/8 (por ejemplo, 10.0.0.0/24).

    • Si el tipo de pila de interconexión previsto es IPV4_IPV6, no podrás establecer una conexión de interconexión con una red de VPC que tenga una ruta estática cuyo destino coincida exactamente con 2001:0db8:0a0b:0c0d::/64 o esté dentro de 2001:0db8:0a0b:0c0d::/64 (por ejemplo, 2001:0db8:0a0b:0c0d::/96) si existe una ruta de subred local para 2001:0db8:0a0b:0c0d::/64.

  • No puedes actualizar una conexión de peering si la configuración de peering actualizada da como resultado la importación de la ruta estática en conflicto.

  • Por el contrario, si las redes de VPC ya están conectadas mediante el emparejamiento entre redes de VPC, no puedes realizar las siguientes operaciones:

    • Crea una ruta de subred local cuya ruta estática de destino coincida exactamente con una ruta estática de peering importada o la contenga.
    • Crea una ruta estática en la red de VPC emparejada cuyo destino coincida exactamente con una ruta de subred local o se ajuste a ella.

Efectos del modo de enrutamiento dinámico

El modo de enrutamiento dinámico de una red de VPC determina las regiones en las que los prefijos aprendidos de los routers de Cloud Router de esa red se aplican como rutas dinámicas locales. Para obtener más información sobre este comportamiento, consulta Efectos del modo de enrutamiento dinámico.

Este concepto se extiende al emparejamiento entre redes de VPC. El modo de enrutamiento dinámico de la red de VPC exportadora (la red que contiene los routers de Cloud Router que han aprendido los prefijos de esas rutas dinámicas) determina las regiones en las que se pueden programar las rutas dinámicas de emparejamiento en las redes de emparejamiento:

• Si el modo de enrutamiento dinámico de la red de VPC de exportación es regional, esa red solo exporta rutas dinámicas en la misma región que sus routers de Cloud que han aprendido los prefijos.

• Si el modo de enrutamiento dinámico de la red de VPC exportadora es global, esa red exporta rutas dinámicas en todas las regiones.

En ambos casos, el modo de enrutamiento dinámico de la red de VPC importadora no es relevante.

Para ver un ejemplo que ilustra este comportamiento, consulta Red de VPC local y red de VPC emparejada con conectividad on-premise.

Interacciones de subred y ruta dinámica

Los conflictos entre las rutas de subred locales o de peering y las rutas dinámicas se resuelven tal como se describe en Interacciones con rutas dinámicas.

Ejemplos de emparejamiento entre redes de VPC

En los siguientes ejemplos se muestran dos situaciones habituales de emparejamiento entre redes de VPC.

Red de VPC local y red de VPC emparejada con conectividad on-premise

En este ejemplo, se ha configurado el siguiente emparejamiento de redes:

• network-a está emparejada con network-b, y network-b con network-a.
• network-a contiene dos subredes, cada una en una región distinta. network-b contiene una sola subred.
• network-b está conectada a una red local con túneles de Cloud VPN mediante el enrutamiento dinámico. (Se aplican los mismos principios si los túneles se sustituyen por vinculaciones de VLAN de Cloud Interconnect).
• La conexión de emparejamiento de network-b se configura con la marca --export-custom-routes, y la conexión de emparejamiento de network-a se configura con la marca --import-custom-routes.

Para proporcionar conectividad desde las instalaciones locales a las subredes de network-a y network-b, el router de Cloud Router de network-b debe configurarse para usar el modo de anuncio personalizado. Por ejemplo, Cloud Router solo anuncia el prefijo personalizado, custom-prefix-1, que incluye los intervalos de subredes de network-b y los intervalos de subredes de network-a.

El router de Cloud Router de us-west1 aprende on-premises-prefix de un router local. on-premises-prefix no crea ningún conflicto porque es más amplia que las rutas de subred y de subred de peering. Es decir, on-premises-prefix no coincide exactamente y no se ajusta a ninguna ruta de subred o de subred de emparejamiento.

En la siguiente tabla se resume la configuración de red especificada en el ejemplo anterior:

Nombre de la red	Componente de redes	Intervalo de IPv4	Intervalo de IPv6	Región
network-a	subnet-a	10.0.0.0/24	fc:1000:1000:1000::/64	us‑west1
network-a	subnet-b	10.0.1.0/24	fc:1000:1000:1001::/64	europe-north 1
network-b	subnet-c	10.0.2.0/23	fc:1000:1000:1002::/64	us‑west1
network-b	Cloud Router	10.0.0.0/22	fc:1000:1000:1000::/64	us‑west1
Red local	Router on-premise	10.0.0.0/8	fc:1000:1000:1000::/56	N/A

Independientemente del modo de enrutamiento dinámico de network-a, se aplican las siguientes características de enrutamiento:

• Cuando el modo de enrutamiento dinámico de network-b es global, las On-premises prefix aprendidas por Cloud Router en network-b se añaden como rutas dinámicas en todas las regiones de network-b y como rutas dinámicas de peer en todas las regiones de network-a. Si las reglas de cortafuegos están configuradas correctamente, vm-a1, vm-a2 y vm-b pueden comunicarse con un recurso local con la dirección IPv4 10.5.6.7 (o la dirección IPv6 fc:1000:1000:10a0:29b::).

• Si el modo de enrutamiento dinámico de network-b cambia a regional, las rutas On-premises prefix aprendidas por el router de Cloud Router de network-b solo se añaden como rutas dinámicas en la región us-west1 de network-b y como rutas dinámicas de emparejamiento en la región us-west1 de network-a. Si las reglas de firewall están configuradas correctamente, solo vm-a1 y vm-b pueden comunicarse con un recurso local con la dirección IPv4 10.5.6.7 (o la dirección IPv6 fc:1000:1000:10a0:29b::), ya que es la única VM de la misma región que el Cloud Router.

Red de tránsito con varios emparejamientos

Imagina una situación en la que network-b está conectada a una red local y actúa como red de tránsito para otras dos redes, network-a y network-c. Para permitir que las máquinas virtuales de ambas redes accedan a network-b y a su red local conectada usando solo direcciones IP internas, se requiere la siguiente configuración:

• network-a está emparejada con network-b, y network-b con network-a.
• network-c está emparejada con network-b, y network-b con network-c.
• network-b está conectada a una red local con túneles de Cloud VPN mediante el enrutamiento dinámico. Se aplican los mismos principios si los túneles se sustituyen por vinculaciones de VLAN de Cloud Interconnect.
  • Para proporcionar conectividad desde las instalaciones locales a las subredes de network-a, network-b y network-c, el router de Cloud Router de network-b se configura para usar el modo de anuncio personalizado. Por ejemplo, el router de Cloud Router anuncia rutas de subred de network-b, además de prefijos personalizados que cubren rutas de subred en network-a y network-c.
  • Sujeto a las interacciones entre subredes y rutas dinámicas, el router de Cloud Router de network-b aprende los prefijos on‐premise y crea rutas dinámicas en network-b.
• Las conexiones de emparejamiento de network-b a network-a y de network-b a network-c se configuran con la marca --export-custom-routes. Las conexiones de emparejamiento de network-a a network-b y de network-c a network-b se configuran con la marca --import-custom-routes.
  • Sujeto a las interacciones entre subredes y rutas dinámicas, el router de Cloud Router de network-b también crea rutas dinámicas de peering en network-a y network-c.

Si los cortafuegos están configurados correctamente, se pueden dar los siguientes casos de conectividad:

• Las instancias de VM de network-a pueden comunicarse con otras VMs de network-b y con sistemas on-premise.
• Las instancias de VM de network-c pueden comunicarse con otras VMs de network-b y con sistemas on-premise.
• Las instancias de VM de network-b pueden comunicarse con otras VMs de network-a y network-c, así como con sistemas de la red local.

Como el emparejamiento entre redes de VPC no es transitivo, las instancias de VM de network-a y network-c no pueden comunicarse entre sí a menos que también conectes las redes network-a y network-c mediante el emparejamiento entre redes de VPC.

Precios

Se aplican los precios de red habituales al emparejamiento entre redes de VPC.

Siguientes pasos

• Para configurar y solucionar problemas del emparejamiento entre redes de VPC, consulta Configurar y gestionar el emparejamiento entre redes de VPC.