Descripción general del intercambio de tráfico entre redes de VPC

El intercambio de tráfico entre redes de VPC de Google Cloud permite la conectividad privada RFC 1918 en dos redes de nube privada virtual (VPC), sin importar si pertenecen al mismo proyecto o a la misma organización.

El intercambio de tráfico entre redes de VPC te permite intercambiar tráfico entre redes de VPC, de forma que las cargas de trabajo en distintas redes de VPC puedan comunicarse en un espacio privado RFC 1918. El tráfico permanece dentro de la red de Google y no se desvía a la Internet pública.

El intercambio de tráfico de redes de VPC sirve para los siguientes casos:

  • Ecosistemas de SaaS (Software como servicio) en Google Cloud. Puedes hacer que los servicios estén disponibles de forma privada en distintas redes de VPC dentro de las organizaciones y entre ellas.
  • Las organizaciones con varios dominios administradores de redes pueden intercambiar tráfico entre sí.

Si tienes varios dominios administradores de redes dentro de tu organización, el intercambio de tráfico entre redes de VPC permite que pongas a disposición los servicios en las redes de VPC en un espacio privado RFC 1918. Si ofreces servicios a otras organizaciones, el intercambio de tráfico entre redes de VPC te permite poner a disposición los servicios en el espacio privado RFC 1918 de esas organizaciones. La posibilidad de ofrecer servicios entre organizaciones resulta útil si deseas ofrecer servicios a otras empresas. También es útil dentro de tu empresa si tienes varios nodos de organización separados debido a la estructura o como resultado de las fusiones o adquisiciones.

El uso del intercambio de tráfico entre redes de VPC tiene más ventajas que el uso de direcciones IP externas o VPN para conectar las redes. Estas son algunas de ellas:

  • Latencia de red: Las herramientas redes de IP pública experimentan una mayor latencia que las privadas. Todo el tráfico de intercambio permanece dentro de la red de Google.
  • Seguridad de red: Los propietarios del servicio no necesitan que se expongan sus servicios a la Internet pública ni lidiar con los riesgos asociados.
  • Costos de red: Google Cloud cobra el precio del ancho de banda de salida en las redes que usan direcciones IP externas para comunicarse, incluso si el tráfico circula dentro de la misma zona. Sin embargo, si las redes tienen intercambio de tráfico, se pueden comunicar a través de IP internas y evitar los costos de salida. El precio regular de la red aún se aplica a todo el tráfico.

Para obtener información sobre cómo crear conexiones de intercambio de tráfico, consulta Usa el intercambio de tráfico entre redes de VPC.

Propiedades principales

Las redes de intercambio de tráfico de red de VPC presentan las siguientes propiedades principales:

  • El intercambio de tráfico entre redes de VPC funciona con Compute Engine, GKE y el entorno flexible de App Engine.
  • La administración de cada red de VPC de intercambio de tráfico se mantiene separada. Las rutas, los firewalls, las VPN y otras herramientas de administración de tráfico se administran y aplican por separado en cada una de las redes de VPC.
  • Cada extremo de la asociación de intercambio de tráfico se configura de forma independiente. El intercambio de tráfico se activará solo cuando la configuración de ambos extremos coincida. Cualquiera de los extremos puede borrar la asociación de intercambio de tráfico en cualquier momento.
  • El intercambio de tráfico y la opción de importar y exportar rutas personalizadas se pueden configurar para una red de VPC, incluso antes de que se cree la otra red de VPC. Sin embargo, el intercambio de rutas solo ocurre después de que se hayan configurado ambos lados.
  • Los intercambios de tráfico de VPC siempre intercambian todas las rutas de la subred. También puedes intercambiar rutas personalizadas (rutas estáticas y dinámicas), en función de si la configuración del intercambio de tráfico se establece para que se importen o exporten. Para obtener más información, consulta Importa y exporta rutas personalizadas.
  • Las rutas estáticas y de subred son globales. Las rutas dinámicas pueden ser regionales o globales, en función del modo de enrutamiento dinámico de la red de VPC.
  • Una determinada red de VPC puede intercambiar tráfico con varias redes de VPC, pero existe un límite.
  • Los permisos de IAM para crear y borrar el intercambio de tráfico entre redes de VPC se incluyen como parte de las funciones de propietario del proyecto, editor del proyecto y administrador de red.
  • El tráfico del intercambio (el tráfico que fluye entre las redes de intercambio de tráfico) tiene la misma latencia, capacidad de procesamiento y disponibilidad que el tráfico privado de la misma red.
  • La política de facturación del tráfico de intercambio es la misma que la política de facturación del tráfico privado en la misma red.
  • Si eres administrador de políticas de la organización, puedes usar una política de la organización para limitar qué redes de VPC pueden intercambiar tráfico con las redes de VPC de tu organización. Puedes rechazar conexiones de intercambio de tráfico de redes específicas de VPC o de redes de VPC en una cierta organización o carpeta. La restricción aplica a las configuraciones nuevas del intercambio de tráfico y no afecta a las conexiones existentes. Una conexión existente de intercambio de tráfico puede seguir funcionando incluso si una política nueva rechaza conexiones nuevas. Para obtener más información, consulta la restricción constraints/compute.restrictVpcPeering.

Restricciones

Cuando intercambias tráfico con redes de VPC, debes tener en cuenta las siguientes restricciones:

  • Un rango de CIDR de la subred en una red de VPC con intercambio de tráfico no se puede superponer con una ruta estática en otra red con intercambio de tráfico. Esta regla abarca las rutas de la subred y las estáticas. Google Cloud comprueba la presencia de superposiciones en las siguientes circunstancias y genera un error cuando se produce una:
    • Cuando realizas un intercambio de tráfico de red de VPC por primera vez
    • Cuando creas una ruta estática en una red de VPC de intercambio de tráfico
    • Cuando creas una subred nueva en una red de VPC con intercambio de tráfico
  • Una ruta dinámica se puede superponer con una ruta de la subred en una red de intercambio de tráfico. En el caso de las rutas dinámicas, los rangos de destino que se superponen con una ruta de la subred de la red de intercambio de tráfico se quitan de forma silenciosa. Google Cloud usa la ruta de la subred.
  • En el intercambio de tráfico entre redes de VPC, solo se admiten las redes de VPC. El intercambio de tráfico NO se admite en las redes heredadas.
  • No se puede inhabilitar el intercambio de rutas de la subred ni seleccionar las rutas de la subred que se intercambian. Una vez establecido el intercambio de tráfico, se puede acceder a todos los recursos dentro de las direcciones IP de la subred en las redes con intercambio de tráfico directo. El intercambio de tráfico entre redes de VPC no proporciona controles detallados de rutas para filtrar los rangos CIDR de la subred a los que se puede acceder en las redes con intercambio de tráfico. De ser necesario, debes usar reglas de firewall para filtrar el tráfico. Se puede acceder a los siguientes tipos de extremos y recursos a través de cualquier red con intercambio de tráfico directo:
    • Las direcciones IP internas de las máquinas virtuales (VM) en todas las subredes
    • Las direcciones IP del balanceo de cargas en todas las subredes
  • Solo las redes de intercambio de tráfico directo pueden comunicarse. No se admite el intercambio de tráfico transitivo. En otras palabras, si la red de VPC N1 intercambia tráfico con N2 y N3, pero estas no están conectadas de forma directa, la red de VPC N2 no se podrá comunicar con la red de VPC N3 mediante el intercambio de tráfico entre redes de VPC.
  • No se puede usar una etiqueta ni una cuenta de servicio de una red con intercambio de tráfico en la otra red con intercambio de tráfico.
  • Las redes con intercambio de tráfico no pueden acceder a los nombres de DNS internos de Compute Engine creados en una red. Use la dirección IP para acceder a las instancias de VM en la red con intercambio de tráfico.
  • De forma predeterminada, el intercambio de tráfico entre redes de VPC con GKE es compatible cuando se usa con alias de IP. Si no se usan alias de IP, puede exportar rutas personalizadas para que se pueda acceder a los contenedores de GKE desde redes con intercambio de tráfico.

Orden de enrutamiento

Después de intercambiar rutas con otra red y de intercambiar rutas, es posible que la red de VPC tenga rutas con destinos que compiten. Para obtener información sobre cómo Google Cloud determina el orden del enrutamiento, consulta Orden de enrutamiento.

Importar y exporta rutas personalizadas

De forma predeterminada, las rutas de la subred siempre se intercambian entre las redes con intercambio de tráfico. También puedes intercambiar rutas personalizadas, que incluyen rutas estáticas y dinámicas, si los administradores de ambas redes tienen la configuración apropiada de intercambio de tráfico.

Cuando importas rutas personalizadas, tu red de VPC puede recibir rutas personalizadas de la red de intercambio de tráfico solo si esa red las exporta. Del mismo modo, si exportas rutas personalizadas, la red de intercambio de tráfico puede recibir rutas personalizadas solo si esa red las importa.

Cuando importas o exportas rutas personalizadas, las redes solo intercambian rutas personalizadas con redes de intercambio de tráfico directo. Por ejemplo, si tu red de VPC intercambia tráfico con varias redes, las rutas que importa la red desde una red de intercambio de tráfico no se exportan a las otras redes de intercambio de tráfico.

Cuando creas o modificas una configuración de intercambio de tráfico, puedes elegir importar, exportar rutas o ambas. El administrador de red de intercambio de tráfico debe establecer de forma similar la configuración de intercambio de tráfico antes de que se intercambien rutas. Este proceso garantiza que ambos administradores de red acuerden de forma explícita intercambiar rutas personalizadas antes de que se intercambien.

Beneficios de intercambiar rutas personalizadas

Compartir rutas personalizadas con redes de VPC con intercambio de tráfico permite que las redes aprendan rutas directamente desde sus redes con intercambio de tráfico. Por ejemplo, si se actualiza una ruta personalizada en una red con intercambio de tráfico, la red de VPC aprende de forma automática y la usa sin que debas intervenir.

El intercambio de rutas personalizadas puede ser útil en los siguientes casos:

  • Si tienes clústeres de GKE sin un direccionamiento nativo de VPC, es posible que tengas varias rutas estáticas para dirigir el tráfico a las instancias de VM que alojan tus contenedores. Puedes exportar estas rutas estáticas para que se pueda acceder a los contenedores desde redes con intercambio de tráfico.
  • Si tienes un túnel VPN o una interconexión, puedes compartir rutas personalizadas para que las redes de intercambio de tráfico puedan acceder a tu red local. En el caso de las rutas dinámicas, debes agregar anuncios de ruta personalizados de Cloud Router en la red de VPC para anunciar subredes de la red con intercambio de tráfico en tu red local.

Consideraciones

Cuando configures la importación o exportación de rutas personalizadas, considera los siguientes comportamientos:

  • Tanto las rutas estáticas como las dinámicas se exportan o importan. No puedes elegir importar o exportar un solo tipo de ruta.
  • Las rutas personalizadas importadas desde una red de VPC no se pueden exportar a otra red de VPC con intercambio de tráfico de forma transitiva.
  • Las siguientes rutas quedan excluidas de la importación y exportación:
    • Las rutas etiquetadas nunca se intercambian entre redes con intercambio de tráfico. Las rutas etiquetadas son rutas estáticas personalizadas que abarcan instancias de VM específicas mediante el uso de etiquetas de red. Las etiquetas de red solo se pueden resolver en la red de VPC en la que se crearon.
    • Las rutas estáticas con un próximo salto a la puerta de enlace predeterminada de Internet nunca se intercambian. Por ejemplo, la ruta predeterminada (0.0.0.0/0) con un próximo salto a la puerta de enlace predeterminada de Internet no se intercambia entre las redes con intercambio de tráfico.
  • Las rutas importadas podrían generar cambios no deseados en el flujo de tráfico, como cambios en el orden de enrutamiento. Para obtener más información, consulta Orden de enrutamiento.
  • Cuando una red de VPC importa rutas personalizadas desde una red de intercambio de tráfico, los rangos de destino se importan tal como están. Sin embargo, el próximo salto de las rutas importadas se establece con el nombre de la conexión de intercambio de tráfico. El tráfico se dirige a la red con intercambio de tráfico en la que se define el verdadero próximo salto.

Funciones de las Herramientas de redes en situaciones de intercambio de tráfico de red de VPC

En las siguientes secciones, se muestra cómo se comporta el intercambio de tráfico entre redes de VPC en determinadas situaciones.

Subredes que se superponen al momento del intercambio de tráfico

Al momento del intercambio de tráfico, Google Cloud comprueba si hay subredes con rangos de IP que se superpongan entre las dos redes de VPC o entre cualquiera de sus redes con intercambio de tráfico. Si existe una superposición, no se establece el intercambio de tráfico. Debido a que se crea una conectividad de red en malla completa entre instancias de VM, las subredes en las redes de VPC con intercambio de tráfico no pueden tener rangos de IP que se superpongan, ya que esto generaría problemas de enrutamiento.

Rangos de IP de subredes superpuestos entre dos redes de intercambio de tráfico (haz clic para agrandar)
Rangos de IP de subredes superpuestos entre dos redes con intercambio de tráfico (haz clic para ampliar)

Si hubiera subredes con rangos de IP que se superpongan entre las redes con intercambio de tráfico de una determinada red de VPC, esto causaría un conflicto de enrutamiento. Por ejemplo, supongamos que ya se estableció el intercambio de tráfico de la red de VPC N1 a la red de VPC N2 y, luego, la red de VPC N3 intenta intercambiar tráfico con N2. Este intercambio de tráfico no es válido debido a que N3 tiene una subred Subnet_5, cuyo rango de IP se superpone con Subnet_1 en la red N1.

Rangos de IP de subredes superpuestos con tres redes con intercambio de tráfico (haz clic para agrandar).
Rangos de IP de subredes superpuestos con tres redes con intercambio de tráfico (haz clic para ampliar)

Subredes que se superponen durante la creación o expansión de subredes

Cuando se crea una subred de VPC o se expande un rango de IP de la subred, Google Cloud realiza una verificación para asegurarse de que el nuevo rango de subredes no se superponga con los rangos de IP de las subredes en la misma red de VPC o en redes de VPC con intercambio de tráfico directo. Si existe una superposición, la acción de creación o expansión fallará. Por ejemplo, cuando se crea una subred subnet_3 nueva en la red N2 de la siguiente ilustración, los rangos de IP no se deben superponer con los rangos de IP definidos en la red N1 con intercambio de tráfico directo.

Verificación de la creación de subred (haz clic para agrandar)
Verificación de la creación de la subred (haz clic para ampliar)

Google Cloud también garantiza que no se permita la superposición de rangos de IP de la subred en las redes de VPC que tengan una red con intercambio de tráfico en común. Si existe una superposición, la acción de creación o expansión fallará. Por ejemplo, cuando se crea una subred subnet_5 nueva en la red N3 de la siguiente ilustración, los rangos de IP no se deben superponer con los rangos de IP definidos en la red N2 con intercambio de tráfico directo o en la red N1, debido a que N1 ya intercambia tráfico con N2.

Verificación de la creación de subredes con tres redes de intercambio de tráfico (haz clic para agrandar)
Verificación de creación de la subred con tres redes de intercambio de tráfico (haz clic para ampliar)

Acceso local desde la red de intercambio de tráfico

Puedes usar Cloud VPN o Cloud Interconnect para conectar la red local a la red de VPC de forma segura. Si exportas rutas personalizadas, las redes de VPC con intercambio de tráfico también se pueden conectar a la red local. En el extremo local, debes crear rutas para que el tráfico que se dirige a las redes de VPC se dirija al túnel VPN.

Cloud VPN es compatible con el enrutamiento dinámico y estático, pero Cloud Interconnect solo es compatible con el enrutamiento dinámico. En el caso del enrutamiento dinámico, debes usar Cloud Router para actualizar las rutas entre la red de VPC y la red local de forma dinámica mediante el Protocolo de puerta de enlace fronteriza (BGP). Los Cloud Routers pueden aprender rutas y propagarlas dentro de su región o en todas las regiones dentro de una red de VPC. Este comportamiento depende del modo de enrutamiento dinámico de la red de VPC, que puede ser regional o global.

En los siguientes casos prácticos, se muestra cómo se puede acceder a los recursos en las redes de VPC con intercambio de tráfico después de que hayan importado y exportado rutas personalizadas. En cada ejemplo, se muestran dos redes (network-a y network-b) que intercambian tráfico entre sí. En un ejemplo, el modo de enrutamiento dinámico de network-b es regional y, en el otro ejemplo, global.

Enrutamiento dinámico regional

Si usas el enrutamiento dinámico regional, solo los recursos en la misma región que Cloud Router pueden acceder a la red local. Esta restricción se aplica a la red de VPC de Cloud Router y a cualquier red de VPC con intercambio de tráfico, sin importar el modo de enrutamiento dinámico de la red de VPC con intercambio de tráfico. En el siguiente ejemplo, network-b contiene un túnel VPN (que también podría ser una interconexión) y un Cloud Router. El modo de enrutamiento dinámico de network-b se configuró como regional. En la red con intercambio de tráfico, subnet-a se encuentra en la misma región que Cloud Router en network-b.

Después de que se haya establecido una conexión de intercambio de tráfico, network-a puede acceder al túnel VPN en network-b. Este acceso se limita a las subredes que se encuentran en la misma región que Cloud Router. Por ejemplo, la instancia de VM vm-a puede acceder al túnel VPN porque se encuentra en la misma región que Cloud Router. Las instancias de VM en otras regiones no pueden acceder al túnel.

Cloud Router no aprende ni propaga rutas desde redes de VPC con intercambio de tráfico. Como resultado, debes tener un anuncio de ruta personalizado en Cloud Router que propague el rango 10.8.1.0/24 a la red local en la sesión de BGP.

En la siguiente tabla, se resumen las rutas resultantes de network-a y network-b si ambas importan y exportan rutas personalizadas:

Red Destino Siguiente salto Origen
network-a 0.0.0.0/0 Puerta de enlace de Internet local
10.8.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-to-b red con intercambio de tráfico
10.10.0.0/16
(ruta dinámica limitada a us-west1)
peering-a-to-b red con intercambio de tráfico
network-b 0.0.0.0/0 Puerta de enlace de Internet local
10.8.2.0/24 network-b local
10.10.0.0/16
(ruta dinámica limitada a us-west1)
vpn-b local
10.8.1.0/24 peering-b-to-a red con intercambio de tráfico
10.30.0.0/16 peering-b-to-a red con intercambio de tráfico

Enrutamiento dinámico global

Si network-b habilita el enrutamiento dinámico global, los recursos de todas las regiones pueden acceder a la red local. Esto aplica a la red de VPC de Cloud Router y a cualquier red de VPC con intercambio de tráfico, sin importar el modo de enrutamiento dinámico de la red de VPC.

En el siguiente ejemplo, los recursos en network-a pueden acceder al túnel VPN en network-b, sin importar su región. Por ejemplo, las instancias de VM vm-a1 y vm-a2 pueden acceder a la red local, a pesar de que vm-a2 se encuentre en una región distinta que el túnel VPN.

Cloud Router también debe incluir un anuncio de ruta personalizado para anunciar los rangos 10.8.1.0/2410.9.1.0/24 a la red local en la sesión de BGP.

En la siguiente tabla, se resumen las rutas resultantes de network-a y network-b si ambas importan y exportan rutas personalizadas:

Red Destino Siguiente salto Origen
network-a 0.0.0.0/0 Puerta de enlace de Internet local
10.8.1.0/24 network-a local
10.9.1.0/24 network-a local
10.30.0.0/16 vm-a1 local
10.8.2.0/24 peering-a-to-b red con intercambio de tráfico
10.10.0.0/16
(ruta dinámica global)
peering-a-to-b red con intercambio de tráfico
network-b 0.0.0.0/0 Puerta de enlace de Internet local
10.8.2.0/24 network-b local
10.10.0.0/16
(ruta dinámica global)
vpn-b local
10.8.1.0/24 peering-b-to-a red con intercambio de tráfico
10.9.1.0/24 peering-b-to-a red con intercambio de tráfico
10.30.0.0/16 peering-b-to-a red con intercambio de tráfico

Red de VPC como una red de tránsito

Imagina que tienes una sola conexión local, como un túnel VPN o una interconexión, entre la red de VPC y la red local. Deseas compartir esta conexión con otras redes de VPC con el fin de que no tengas que volver a crear una conexión local para todas las demás redes de VPC.

Puedes hacer que otras redes de VPC intercambien tráfico con tu red de VPC (también conocida como red de tránsito) para que las otras redes puedan usar la conexión local. Todas las redes con intercambio de tráfico pueden aprovechar la conexión local, pero no podrán enrutar el tráfico a otra red de intercambio de tráfico a través de la red de tránsito.

En el siguiente ejemplo, hay tres redes de VPC. network-b intercambia tráfico con network-a y network-c. Todas las redes importan y exportan rutas personalizadas. network-b actúa como la red de tránsito, en la que se encuentra el túnel VPN.

  • network-b tiene las rutas estáticas de VPN relevantes para el enrutamiento del tráfico a la red local conectada. Las redes de VPC con intercambio de tráfico exportan y, luego, importan la ruta estática. Si usas Cloud Router para el enrutamiento dinámico, debes anunciar las direcciones IP de la subred de las redes de intercambio de tráfico. Cloud Router no anuncia rutas de forma automática desde el intercambio de tráfico entre redes de VPC.

  • Los hosts en la red local pueden enviar y recibir tráfico desde y hacia los hosts en cada una de las redes de VPC. La red local debe contener rutas que tengan un próximo salto a la puerta de enlace de VPN si el tráfico se dirige a una red de VPC.

  • Los hosts en network-c pueden acceder a los hosts en network-b y a la red local, pero no a los hosts en network-a. Del mismo modo, los hosts en network-a pueden acceder a network-b y a la red local, pero no a network-c. Esto se debe a que las rutas de intercambio de tráfico no son transitivas.

Balanceo de cargas de TCP/UDP interno

Las instancias de VM en las redes de intercambio de tráfico pueden acceder a las direcciones IP internas de los balanceadores de cargas de TCP o UDP internos en tu red de VPC si se cumplen las siguientes condiciones:

  • Las VM se encuentran en la misma región que el balanceador de cargas de TCP o UDP interno.
  • Las reglas de firewall de entrada que aplican a las VM del backend del balanceador de cargas permiten el tráfico desde las fuentes en las redes de intercambio de tráfico. Las reglas de firewall de entrada se deben crear en la red de VPC que contiene el balanceador de cargas.

Para obtener más información, consulta Usa el intercambio de tráfico entre redes de VPC.

Reglas de firewall

Cuando conectas redes mediante el intercambio de tráfico entre redes de VPC, las reglas de firewall no se intercambian entre ellas. Para permitir tráfico de entrada desde instancias de VM en una red de intercambio de tráfico, debes crear reglas de firewall que permitan la entrada. De forma predeterminada, la regla implícita de rechazo de la entrada bloquea el tráfico de entrada a las VM.

Si necesitas restringir el acceso a las VM de forma que solo las otras VM en tu red de VPC tengan acceso, asegúrate de que las fuentes de las reglas de firewall que permiten la entrada solo identifiquen las VM en tu red de VPC, no las de las redes de intercambio de tráfico. Por ejemplo, puedes especificar rangos de IP de la fuente solo para las subredes en tu red de VPC.

Para restringir el acceso a un balanceador de cargas de TCP o UDP interno, crea reglas de firewall de entrada que apliquen a las VM del backend del balanceador de cargas.

Firewall

Las reglas de firewall no se importan a las redes de intercambio de tráfico. Puedes configurar reglas de firewall en cada red por separado para controlar el tráfico desde las redes de intercambio de tráfico que quieres permitir o bloquear.

Si hay intercambio de tráfico entre tu red de VPC y otra red de VPC, puede que quieras bloquear el tráfico hacia un conjunto específico de instancias de VM o de extremos de balanceo de cargas interno. Para hacerlo, debes usar reglas de firewall, ya que no hay forma de excluir determinadas instancias de VM ni balanceadores de cargas internos del intercambio de tráfico. Si quieres bloquear la comunicación con determinadas instancias de VM o balanceadores de cargas internos, puedes instalar reglas de firewall de entrada en la red para la que deseas bloquear la comunicación.

  • Instancias de VM: En este caso, puedes instalar un firewall de entrada que solo permita el tráfico desde determinadas IP de origen. Estas IP de origen se pueden asignar a los CIDR de la subred en tu red de VPC. Esto bloqueará el tráfico que se origine en las redes de VPC con intercambio de tráfico.
Firewall con intercambio de tráfico entre redes de VPC (haz clic para ampliar)
Firewall con intercambio de tráfico entre redes de VPC (haz clic para ampliar)
  • Balanceadores de cargas internos: En este caso, puedes instalar reglas de firewall de entrada en la red de VPC con el balanceador de cargas interno. Estas IP de origen se pueden asignar a todos o a algunos de los CIDR de la subred en tu red. Si se implementan reglas de firewall de entrada en todos los rangos del CIDR de la subred en la red con intercambio de tráfico, ninguna instancia de esa red podrá acceder a las VM del backend del balanceador de cargas interno.

VPC compartida

El intercambio de tráfico entre redes de VPC permite el intercambio de tráfico con una VPC compartida. Un proyecto host de VPC compartida es un proyecto que permite que otros proyectos usen una de sus redes. En el siguiente diagrama, se muestra esta configuración.

VPC compartida con intercambio de tráfico entre redes (haz clic para ampliar la imagen)
VPC compartida con intercambio de tráfico entre redes (haz clic para ampliar)

Network-SVPC es una red de VPC compartida en el proyecto host P1. Los proyectos de servicio P3 y P4 pueden conectar instancias de VM a Network-SVPC. Network-SVPC intercambia tráfico con Network-A. Como resultado, se dan las siguientes condiciones:

  • Las instancias de VM en proyectos de servicio de VPC compartida que usan Network-SVPC (VM3 y VM4) tienen una conectividad de IP interna privada con cualquier extremo asociado a Network-A.
  • Las instancias de VM asociadas a network-A tendrán una conectividad de IP interna privada con cualquier extremo asociado a Network-SVPC, sin importar si estos extremos se encuentran en el proyecto host o en un proyecto de servicio.

Es posible configurar el intercambio de tráfico entre redes de VPC entre dos redes de VPC compartida.

Varias interfaces de red por instancia de VM

Una instancia de VM puede tener varias interfaces de red, una por cada red de VPC. En esas instancias, Google Cloud asigna rutas de IP basadas en el destino, en las que cada interfaz obtiene una ruta de la subred en la que se encuentra. Además, Google Cloud proporciona una ruta predeterminada a la interfaz de red principal. Con el enrutamiento basado en el destino, cualquier tráfico que no se dirija a alguna de las subredes de la instancia sale de la interfaz de red principal. Para obtener más información, consulta Comportamiento de DHCP con varias interfaces de red.

Si tienes redes de intercambio de tráfico que incluyen instancias de VM con varias interfaces de red, es posible que debas cambiar la política predeterminada de enrutamiento basado en el destino por una política de enrutamiento basado en la fuente. Para obtener más información, consulta Configura el enrutamiento de políticas.

En los siguientes casos, se demuestra en qué momentos una instancia de VM puede requerir una política de enrutamiento basado en la fuente.

Se requiere una política de enrutamiento

En el siguiente ejemplo, vm1 requiere una política de enrutamiento basada en la fuente para que vm1vm2 se puedan comunicar con éxito. Si no hay una política de enrutamiento, todo el tráfico saldrá de vm1-nic0 a network-a, a menos que el tráfico se dirija a subnet-b, donde se encuentra nic1. Esto significa que el tráfico de vm1 que se dirige a network-c se descarta o se envía al destino incorrecto, ya que la instancia de VM siempre envía el tráfico por fuera de su interfaz principal.

El requisito de la política de enrutamiento depende de los rangos de IP de la subred

En el siguiente ejemplo, la interfaz de red principal de vm1 se encuentra en una red que intercambia tráfico con otra red. No es necesario configurar el enrutamiento de políticas en vm1.

En el siguiente ejemplo, vm1-nic1 y vm2-nic0 se encuentran en subredes que se superponen. Cuando se haya establecido el intercambio de tráfico, Google Cloud verificará la presencia de rangos de IP que se superpongan solo entre redes con intercambio de tráfico y no entre otras redes en las que las instancias contengan interfaces de red. Para garantizar que la comunicación entre vm1vm2 funcione, debes agregar una política de enrutamiento basado en la fuente en vm1-nic0.

Intercambio de tráfico entre interfaces

En el siguiente ejemplo, se muestra una instancia de VM con varias interfaces de red, en la que cada una se encuentra en redes que intercambian tráfico entre sí. En este caso, vm1 no requiere una política de enrutamiento basado en la fuente. El tráfico que sale desde la instancia de VM hacia cada subred usa la interfaz de red correspondiente.

Si vm1 envía tráfico a la dirección IP de vm2-nic1, el tráfico se dirige a nic1, pero sale de nic0. De forma similar, si vm3 envía tráfico a la dirección IP de vm2-nic0, el tráfico se dirige a nic0, pero sale de nic1.

Rangos secundarios de la subred

Una subred tiene un solo rango de direcciones IP principal y, de forma opcional, uno o más rangos de direcciones IP secundarios. En cada rango de direcciones IP de la subred, Google Cloud crea una ruta de la subred. Cuando usas el intercambio de tráfico entre redes de VPC, Google Cloud siempre intercambiará las rutas de la subred entre las dos redes con intercambio de tráfico. Si las reglas de firewall en cada red permiten la comunicación, las instancias de VM en una red se podrán comunicar con instancias en la red con intercambio de tráfico.

Cuando estableces una relación de intercambio de tráfico, Google Cloud comprueba que los rangos principal y secundario de una subred no se superpongan con otros rangos en las redes con intercambio de tráfico.

Próximos pasos