Orden de las rutas

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

Para obtener información general sobre las rutas de Google Cloud, incluida la aplicabilidad de las rutas, los parámetros de orden y ruta estáticas, 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 de VPN clásica que usa el 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 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; que 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. En el modo de enrutamiento dinámico de la red de VPC, se 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 la consola de Google Cloud para crear uno de estos túneles, Google Cloud crea rutas estáticas de forma automática según los rangos de IP remota que especifiques en Cloud VPN. Si usas Google Cloud CLI 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. Los rangos locales son 10.2.0.0/16 para IPv4 y fd20:a:b:c::/64 para IPv6.

El tráfico IPv6 solo es compatible con las puertas de enlace de VPN con alta disponibilidad configuradas con un tipo de pila doble de IPv4 y de IPv6.

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 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.
fd20:a:b:c::/64
Igual que el rango de IP local		 La VPN clásica no es compatible con IPv6. El Cloud Router asociado del túnel ignora toda ruta anunciada con un destino de fd20:a:b:c::/64. El tráfico destinado a fd20:a:b:c::/64 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 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.
fd20:a:b::/48
Mayor que el rango de IP local
(máscara de subred más pequeña)		 La VPN clásica no es compatible con IPv6. El Cloud Router asociado al túnel ignora toda ruta anunciada cuyos destinos coincidan con fd20:a:b::/48, incluido fd20:a:b:c::/64. El tráfico destinado a fd20:a:b::/48 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 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.
fd20:a:b:c::/80
Más limitado que el rango de IP local
(máscara de subred más larga)		 La VPN clásica no es compatible con IPv6. El Cloud Router asociado del túnel acepta una ruta anunciada cuyo destino es fd20:a:b:c::/64. Sin embargo, el tráfico a direcciones IP en fd20:a:b:c::/80 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 aprendidas. El tiempo que tarda detectar la falla varía según si la detección de reenvío bidireccional (BFD) está habilitada. Si la BFD está habilitada, la detección ocurre cuando vence el temporizador de retención de la BGP. De lo contrario, la detección ocurrirá en menos de 60 segundos. Las rutas aprendidas se pueden volver a agregar cuando se restablece 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 siguiente salto válido que no estableció una asociación de seguridad (SA) de IKE. Si un túnel de Cloud VPN estableció una SA de IKE, Google Cloud la considera operativa. 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 para el mismo destino, cada una con un túnel de Cloud VPN de salto siguiente diferente, Google Cloud solo considera los túneles que establecieron SA de IKE (Fase 1). Los túneles que están inactivos, es decir, que no tienen SA de IKE válidas, se ignoran antes de considerar la prioridad de la ruta.

    Por ejemplo, supongamos que tienes tres rutas estáticas para el destino 192.168.168.0/24: una con prioridad 10 cuyo túnel de Cloud VPN de salto siguiente está inactivo y un segundo con prioridad 20 cuyo 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 siguiente salto válido y, en su lugar, 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 con el mismo destino, están inactivos. El tráfico se interrumpe incluso si hay una ruta estática para un destino más amplio con un túnel de salto siguiente operacional.

    Por ejemplo, supongamos que tienes una ruta estática para 192.168.168.0/24 cuyo túnel de Cloud VPN de salto siguiente está inactivo (no hay una SA 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.

Para probar el comportamiento de ECMP, usa iperf3 a fin de enviar varias transmisiones de TCP simultáneas. Lo ideal sería hacerlo desde varias instancias de máquina virtual (VM) de Google Cloud mediante túneles de Cloud VPN. Si necesitas validar el comportamiento de ECMP, no uses ICMP (ping) para realizar pruebas. Una prueba de 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, ya que 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?