Orden de las rutas

En esta página, se describe cómo funcionan las rutas personalizadas con los saltos siguientes de los túneles de Cloud VPN en Google Cloud.

Para obtener información general sobre las rutas de Google Cloud, incluidas la aplicabilidad de rutas y los parámetros de orden y ruta estática, consulta la descripción general de las rutas de la nube privada virtual (VPC).

Tipos de ruta

Un túnel de Cloud VPN puede ser un salto siguiente para una ruta personalizada en tu red de VPC. En cada ruta personalizada con un túnel de Cloud VPN de salto siguiente, se define una ruta de salida para los paquetes que salen de la red de VPC:

  • Un Cloud Router siempre administra un túnel VPN clásico que usa enrutamiento dinámico o un túnel VPN con alta disponibilidad. Cloud Router recibe anuncios de BGP y envía mensajes de BGP a una puerta de enlace de VPN de intercambio de tráfico. Cloud Router crea y quita de forma automática rutas dinámicas personalizadas en tu red de VPC; estas son las rutas con destinos en una red de intercambio de tráfico. También anuncia rutas a una red de intercambio de tráfico; estas son rutas a los rangos de IP de subredes en tu red de VPC o a destinos personalizados que especifiques en una configuración de Cloud Router. El modo de enrutamiento dinámico de tu red de VPC controla el conjunto de rutas que Cloud Router importa y exporta.

  • Un túnel de VPN clásica basado en una política o en una ruta usa el enrutamiento estático. Si usas Google Cloud Console para crear uno de estos túneles, Google Cloud crea rutas estáticas personalizadas de forma automática según los rangos de IP remotos que especifiques en Cloud VPN. configuración. Si usas la herramienta de línea de comandos de gcloud para crear uno de estos túneles, debes crear de forma manual las rutas estáticas que usan el túnel como un salto siguiente.

Situaciones de ejemplo

Google Cloud sigue una aplicabilidad y un orden bien definidos cuando selecciona el salto siguiente al que se debe enviar un paquete. En los siguientes ejemplos, se demuestran interacciones comunes entre rutas y Cloud VPN.

Interacción con rutas de subredes

En la siguiente tabla, se muestra cómo interactúan las rutas de subredes y las rutas personalizadas. Cada fila representa un posible rango de IP de una subred en una red de VPC. El rango de IP local es 10.2.0.0/16.

Red de VPC Enrutamiento del túnel de Cloud VPN
Rango de IP de la subred de Google Cloud Estático (basado en políticas, basado en rutas)
Solo VPN clásica
Dinámico (BGP)
VPN clásica o VPN con alta disponibilidad
10.2.0.0/16
Igual que el rango de IP local
Google Cloud no permite crear una ruta estática personalizada cuyo destino sea 10.2.0.0/16 y cuyo salto siguiente sea un túnel de Cloud VPN. El Cloud Router asociado del túnel ignora toda ruta anunciada con un destino de 10.2.0.0/16. El tráfico destinado a 10.2.0.0/16 permanece en tu red de VPC.
10.0.0.0/8
Mayor que el rango de IP local
(máscara de subred más pequeña)
Google Cloud no permite crear una ruta estática personalizada cuyo destino sea 10.2.0.0/16 y cuyo salto siguiente sea un túnel de Cloud VPN. El Cloud Router asociado al túnel ignora toda ruta anunciada cuyos destinos coincidan con 10.0.0.0/8, incluido 10.2.0.0/16. El tráfico destinado a 10.0.0.0/8 permanece en tu red de VPC.
10.2.99.0/24
Más limitado que el rango de IP local
(máscara de subred más larga)
Google Cloud te permite crear una ruta estática personalizada con el destino 10.2.0.0/16 y el túnel de Cloud VPN del salto siguiente. Sin embargo, el tráfico a direcciones IP en 10.2.99.0/24 permanece dentro de tu red de VPC. El Cloud Router asociado del túnel acepta una ruta anunciada cuyo destino es 10.2.0.0/16. Sin embargo, el tráfico a direcciones IP en 10.2.99.0/24 permanece dentro de tu red de VPC.

Cuando los túneles están inactivos

Enrutamiento dinámico (BGP)

Cuando un túnel de VPN clásica que usa enrutamiento dinámico o un túnel VPN con alta disponibilidad se interrumpe, el Cloud Router que lo administra quita de forma automática las rutas dinámicas personalizadas aprendidas en alrededor de 40 segundos. Las rutas dinámicas personalizadas se podrán volver a agregar cuando se restablezca el túnel.

Este proceso es automático, pero aún puede provocar la pérdida de algunos paquetes durante el tiempo que le tome a Cloud Router quitar las rutas afectadas.

Enrutamiento estático

Google Cloud nunca considera un túnel de Cloud VPN como un próximo salto válido que no estableció una asociación de seguridad (SA) de IKE. Si un túnel de Cloud VPN establece una SA de IKE, Google Cloud la considera en funcionamiento. Ten en cuenta que un túnel de Cloud VPN que está en funcionamiento solo pasa tráfico si se selecciona como el salto siguiente según el orden de enrutamiento. En su lugar, se puede usar el salto siguiente para una ruta diferente, con un destino más específico o con una prioridad mayor.

En las siguientes situaciones, se demuestran los comportamientos esperados:

  • Si tienes varias rutas estáticas personalizadas para el mismo destino, cada una con un túnel de Cloud VPN de salto siguiente diferente, Google Cloud solo considera esos túneles que establecieron SAB SA (Fase 1). Los túneles que están inactivos, es decir, que no tienen SA de IKE válidos, se ignoran antes de considerar la prioridad de ruta.

    Por ejemplo, supongamos que tienes tres rutas estáticas personalizadas para el destino 192.168.168.0/24: una con prioridad 10 cuyo túnel de Cloud VPN de salto siguiente está inactivo, un segundo con prioridad 20 cuyo tu túnel de salto siguiente está activo y un tercero con prioridad 30 cuyo túnel de salto siguiente también está activo. Google Cloud enviará tráfico al segundo salto siguiente, aunque su ruta tenga una prioridad menor que la ruta cuyo salto siguiente está inactivo. Si se restablece el primer túnel, Google Cloud lo considera un salto siguiente válido y usa esa ruta.

  • El tráfico se interrumpe si todos los túneles de Cloud VPN, que sirven como saltos siguientes para rutas estáticas personalizadas con el mismo destino, están inactivos. El tráfico se descarta, incluso si hay una ruta estática personalizada para un destino más amplio con un túnel de próximo salto operativo.

    Por ejemplo, supongamos que tienes una ruta estática personalizada para 192.168.168.0/24 cuyo túnel de Cloud VPN de salto siguiente está inactivo (no hay AS de IKE válida). Incluso si tienes una ruta para 192.168.0.0/16 cuyo salto siguiente es un túnel de Cloud VPN operacional, el tráfico a 192.168.168.0/24 se interrumpe. Esto se debe a que Google Cloud siempre selecciona rutas con los destinos más específicos.

Cuando el tráfico cambie de un túnel de Cloud VPN de salto siguiente a otro, aún deberías esperar la pérdida de paquetes. Es posible que los paquetes en tránsito se pierdan y deban volver a transmitirse.

ECMP sobre túneles

En cuanto al enrutamiento dinámico y estático, si existe más de una ruta personalizada para el mismo destino y tiene la misma prioridad y un túnel de salto siguiente activo (AS de IKE establecida), Google Cloud usa varias rutas de acceso de igual costo (ECMP) para distribuir paquetes entre los túneles.

Este método de balanceo se basa en un hash, de modo que todos los paquetes del mismo flujo usan el mismo túnel siempre que esté activo.

Si quieres probar el comportamiento ECEC, usa iperf3 para enviar varias transmisiones de TCP simultáneas, idealmente desde varias instancias de máquina virtual (VM) de Google Cloud a través de túneles de Cloud VPN. Si necesitas validar el comportamiento de ECMP, no uses ICMP (ping) para realizar pruebas. Una prueba ping de una instancia de VM no es suficiente para probar la salida basada en ECMP a través de túneles de Cloud VPN porque solo se selecciona un túnel cuando tienes una fuente y un destino fijos. ICMP es un protocolo fijo en el que no hay un concepto de puertos, por lo que el hash solo se calcula a partir de dos datos: las direcciones de origen y las de destino (un hash de dos tuplas).

¿Qué sigue?