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 de las direcciones IP internas entre 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 conectar redes de VPC para que las cargas de trabajo que se encuentran en redes de VPC diferentes puedan comunicarse de forma interna. 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 entre redes de VPC es útil 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 te permite hacer que los servicios estén disponibles en las redes de VPC mediante el uso de direcciones IP internas. Si ofreces servicios a otras organizaciones, el intercambio de tráfico entre redes de VPC te permite hacer que los servicios estén disponibles mediante el uso de direcciones IP internas para esas organizaciones. La posibilidad de ofrecer servicios entre organizaciones resulta útil si deseas ofrecerlos a otras empresas. También es útil si eres propietario o tienes el control de más de una organización.

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: una conectividad que usa solo direcciones internas proporciona una latencia más baja que una que usa direcciones externas.
  • 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 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 activa 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. Sin embargo, el intercambio de rutas solo ocurre después de que se hayan configurado ambos lados.
  • En los intercambios de tráfico de VPC, siempre se intercambian rutas de subredes que no usan direcciones IP públicas reutilizadas de forma privada. Las redes deben importar de forma explícita rutas de subredes que usen direcciones IP públicas reutilizadas de forma privada para recibirlas.
  • Puedes intercambiar rutas personalizadas (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 que fluye entre las redes con 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 de 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 se aplica a las opciones de configuración 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 las 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 descartan en silencio. 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 en 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 las redes N2 y N3, pero estas no están conectadas directamente, la red de VPC N2 no se podrá comunicar con la 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.
  • Los nombres de DNS internos de Compute Engine creados en una red no son accesibles para las redes de intercambio de tráfico. Usa la dirección IP para acceder a las instancias de VM en una 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

Revisa con cuidado el orden de enrutamiento para saber cómo Google Cloud resuelve conflictos de rutas entre redes en un grupo de intercambio de tráfico.

Importa y exporta rutas personalizadas

Las rutas de subred que no usan direcciones IP públicas reutilizadas de forma privada 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, y rutas para subredes que usan direcciones IP públicas reutilizadas de forma privada si los administradores de red en ambas redes tienen las configuraciones de intercambio de tráfico adecuadas.

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 desde una red con intercambio de tráfico no se exportan a las otras redes con intercambio de tráfico.

Cuando creas o modificas una configuración de intercambio de tráfico, puedes elegir importar rutas, exportarlas o ambas. El administrador de red de intercambio de tráfico debe establecer una configuración similar 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 las rutas personalizadas antes de que estas 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 la 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 a 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:

  • En el momento de configurar el intercambio de tráfico, Google Cloud comprueba si hay rangos de IP de subred que se superpongan con los rangos de IP de la subred en la otra red. Si hay superposiciones, el intercambio de tráfico no se establece. Esta verificación de superposición es solo para los rangos de subredes de VPC. Las rutas estáticas y dinámicas no se verifican. Si el intercambio de tráfico continúa, se exportan tal como están.
  • 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 tales 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 de las redes de VPC con intercambio de tráfico no pueden tener rangos de IP que se superpongan, pues esto generaría problemas de enrutamiento.

Rangos de IP de subredes superpuestos entre dos redes de intercambio de tráfico (haz clic para ampliar)
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 superpuestos entre redes de intercambio de tráfico en una red de VPC determinada, 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 N2 y, luego, la red de VPC N3 intenta intercambiar tráfico con la N2. Este intercambio de tráfico no es válido porque la N3 tiene una subred Subnet_5, cuyo rango de IP se superpone con Subnet_1 en la red N1.

Subredes con rangos de IP superpuestos en tres redes de intercambio de tráfico (haz clic para ampliar)
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 rango de subredes nuevo 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 nueva, subnet_3, en la red N2 en la siguiente figura, los rangos de IP no pueden superponerse con los rangos de IP definidos en la red N1 con intercambio de tráfico directo.

Prueba de creación de subred (haz clic para ampliar)
Prueba de creación de 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 con la red N1, debido a que N1 ya intercambia tráfico con N2.

Prueba de creación de subredes con tres redes de intercambio de tráfico (haz clic para ampliar)
Prueba de creación de subredes 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 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.

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 la red local, a pesar de que vm-a2 se encuentra 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 con 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 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 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 TCP/UDP interno.
  • Las reglas de firewall de entrada que se 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 denegación de 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 TCP/UDP interno, crea reglas de firewall de entrada que se 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 que quieres permitir o bloquear desde las redes de intercambio de tráfico.

Si tienes un intercambio de tráfico entre tu red de VPC y otra red de VPC, deberías bloquear el tráfico a un conjunto específico de instancias de VM o de extremos de balanceo de cargas interno. Para hacerlo, debes utilizar reglas de firewall, ya que no hay forma de excluir determinadas instancias de VM o balanceadores de cargas internos del intercambio de tráfico. Si quieres rechazar la comunicación con determinada instancia de VM o balanceador de cargas interno, puedes instalar reglas de firewall de entrada en la red para la que quieres bloquear la comunicación.

  • Instancias de VM: en este caso, puedes instalar un firewall de entrada que permita el tráfico solo desde determinadas IP de origen. Estas direcciones IP de origen se pueden asignar a la subred de CIDR 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)
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 basado en la fuente para que vm1 y vm2 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 en la que 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 las redes con intercambio de tráfico y no entre otras redes en las que las instancias contengan interfaces de red. Para garantizar que funcione la comunicación entre vm1 y vm2, 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 intercambia las rutas de la subred que no usan direcciones IP públicas reutilizadas de forma privada 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 las 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 principales y secundarios de una subred no se superpongan con otros rangos en las redes con intercambio de tráfico.

Próximos pasos