Orden de rutas

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

Para obtener información general sobre las Google Cloud rutas, incluida la aplicabilidad y el orden de las rutas, así como los parámetros de las rutas estáticas, consulta la información general sobre las rutas de la nube privada virtual (VPC).

Tipos de ruta

Un túnel VPN de Cloud puede ser el siguiente salto de una ruta personalizada de tu red VPC. Cada ruta personalizada con un túnel VPN de Cloud de siguiente salto define una ruta de salida para los paquetes que salen de tu red VPC:

  • Un Cloud Router siempre gestiona un túnel de VPN clásica que usa el enrutamiento dinámico o un túnel de VPN de alta disponibilidad. Cloud Router recibe anuncios BGP y envía mensajes BGP a una pasarela de VPN de peer. Cloud Router crea y elimina automáticamente rutas dinámicas en tu red VPC, es decir, las rutas con destinos en una red peer. También anuncia rutas a una red de aplicación similar, es decir, rutas a los intervalos de IP de las subredes de 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 rutas o políticas usa el enrutamiento estático. Si usas la Google Cloud consola para crear uno de estos túneles,Google Cloud se crearán automáticamente rutas estáticas basadas en los intervalos de IP remotos que especifiques en la configuración de Cloud VPN. Si usas la CLI de Google Cloud para crear uno de estos túneles, debes crear manualmente las rutas estáticas que usen el túnel como salto siguiente.

Casos de ejemplo

Google Cloud sigue un orden y una aplicabilidad bien definidos al seleccionar el siguiente salto al que se debe enviar un paquete. En los siguientes ejemplos se muestran interacciones habituales entre rutas y Cloud VPN.

Interacción con rutas de subred

En la siguiente tabla se muestra cómo interactúan las rutas de subred y las rutas personalizadas. Cada fila representa un intervalo de IP posible de una subred en una red VPC. Los intervalos 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 pasarelas de VPN de alta disponibilidad configuradas con un tipo de pila dual IPv4 e IPv6.

Red VPC Enrutamiento de túneles de Cloud VPN
Intervalo de IP de la Google Cloud subred Estático (basado en rutas o políticas)
Solo VPN clásica		 Dinámico (BGP)
VPN clásica o VPN de alta disponibilidad
10.2.0.0/16
Igual que el intervalo de IPs locales		 Google Cloud no te permite crear una ruta estática cuyo destino sea 10.2.0.0/16 y cuyo siguiente salto sea un túnel de Cloud VPN. El router de Cloud Router asociado al túnel ignora las rutas anunciadas con el destino 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 intervalo de IPs locales		 La VPN clásica no admite IPv6. El router de Cloud Router asociado al túnel ignora las rutas anunciadas con el destino 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
Más amplio que el intervalo de IPs locales
(máscara de subred más pequeña)		 Google Cloud no te permite crear una ruta estática cuyo destino sea 10.2.0.0/16 y cuyo siguiente salto sea un túnel de Cloud VPN. El router de Cloud asociado al túnel ignora las rutas anunciadas cuyo destino coincida con 10.0.0.0/8 o se ajuste a él, 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
Más amplio que el intervalo de IPs locales
(máscara de subred más pequeña)		 La VPN clásica no admite IPv6. El router de Cloud asociado al túnel ignora las rutas anunciadas cuyo destino coincida con fd20:a:b::/48 o se ajuste a él, 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 estrecho que el intervalo 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 siguiente salto. Sin embargo, el tráfico a las direcciones IP de 10.2.99.0/24 permanece en tu red de VPC. El Cloud Router asociado al túnel acepta una ruta anunciada cuyo destino es 10.2.0.0/16. Sin embargo, el tráfico a las direcciones IP de 10.2.99.0/24 permanece en tu red de VPC.
fd20:a:b:c::/80
Más estrecho que el intervalo de IP local
(máscara de subred más larga)		 La VPN clásica no admite IPv6. El Cloud Router asociado al túnel acepta una ruta anunciada cuyo destino es fd20:a:b:c::/64. Sin embargo, el tráfico a las direcciones IP de fd20:a:b:c::/80 permanece en tu red de VPC.

Cuando los túneles no funcionan

Enrutamiento dinámico (BGP)

Cuando un túnel de VPN clásica que usa enrutamiento dinámico o un túnel de VPN de alta disponibilidad deja de funcionar, el Cloud Router que lo gestiona elimina automáticamente las rutas aprendidas. El tiempo que se tarda en detectar la interrupción varía en función de si la detección de reenvío bidireccional (BFD) está habilitada. Si el BFD está habilitado, la detección se produce cuando caduca el temporizador de retención de BGP. De lo contrario, la detección se produce en menos de 60 segundos. Las rutas aprendidas se pueden volver a añadir cuando se restablezca el túnel.

Este proceso es totalmente automático, pero puede provocar cierta pérdida de paquetes durante el tiempo que tarda Cloud Router en eliminar las rutas afectadas.

Enrutamiento estático

Google Cloud nunca considera un túnel de Cloud VPN como un salto siguiente válido que no haya establecido una asociación de seguridad (SA) de IKE. Si un túnel VPN de Cloud ha establecido una SA de IKE, Google Cloud se considera que está operativo. Un túnel de Cloud VPN operativo solo transfiere tráfico si se selecciona como siguiente salto según el orden de enrutamiento. En su lugar, se podría usar el siguiente salto de una ruta diferente, con un destino más específico o con una prioridad más alta.

En los siguientes casos se muestra el comportamiento esperado:

  • Si tienes varias rutas estáticas para el mismo destino, cada una con un túnel de VPN de Cloud de siguiente salto diferente, Google Cloud solo se tienen en cuenta los túneles que han establecido asociaciones de seguridad IKE (fase 1). Los túneles que no funcionan (es decir, que no tienen asociaciones de seguridad IKE válidas) se ignoran antes de tener en cuenta la prioridad de la ruta.

    Por ejemplo, supongamos que tiene 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, una segunda con prioridad 20 cuyo túnel de salto siguiente está activo y una tercera con prioridad 30 cuyo túnel de salto siguiente también está activo. Google Cloud envía tráfico al segundo salto siguiente, aunque su ruta tenga una prioridad inferior a la ruta cuyo salto siguiente está inactivo. Si se vuelve a establecer el primer túnel, Google Cloud lo considera un siguiente salto válido y usa esa ruta.

  • El tráfico se descarta si todos los túneles de Cloud VPN que actúan como siguientes saltos de las rutas estáticas con el mismo destino están inactivos. El tráfico se descarta incluso si hay una ruta estática para un destino más amplio con un túnel de siguiente salto operativo.

    Por ejemplo, supongamos que tiene una ruta estática para 192.168.168.0/24 cuyo túnel de Cloud VPN de siguiente salto está inactivo (no hay ninguna SA IKE válida). Aunque tengas una ruta para 192.168.0.0/16 cuyo siguiente salto sea un túnel de Cloud VPN operativo, se descartará el tráfico a 192.168.168.0/24. Esto se debe a que Google Cloud siempre selecciona las rutas con los destinos más específicos.

Cuando el tráfico cambia de un túnel VPN de Cloud de siguiente salto a otro, es normal que se pierdan paquetes. Es posible que se pierdan paquetes en tránsito y que sea necesario volver a enviarlos.

ECMP a través de túneles

Tanto en el enrutamiento dinámico como en el estático, si hay más de una ruta personalizada para el mismo destino y tienen la misma prioridad y un túnel de salto siguiente activo (se ha establecido una SA IKE), Google Cloud utiliza el enrutamiento de multipath de igual coste (ECMP) para distribuir los paquetes entre los túneles.

Este método de equilibrio se basa en un hash, por lo que todos los paquetes del mismo flujo usan el mismo túnel mientras esté activo.

Para probar el comportamiento de ECMP, usa iperf3 para enviar varias secuencias TCP simultáneas, preferiblemente desde varias instancias de máquina virtual (VM)Google Cloud a través de túneles de Cloud VPN. Si necesitas validar el comportamiento de ECMP, no uses ICMP (ping) para hacer pruebas. Una prueba ping desde 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 un origen y un destino fijos. ICMP no tiene ningún concepto de puertos y es un protocolo fijo, por lo que el hash solo se calcula a partir de dos datos: las direcciones de origen y de destino (un hash de dos tuplas).

Siguientes pasos