Rutas estáticas

En esta página se ofrece una descripción general de cómo funcionan las rutas estáticas en Google Cloud.

Para obtener una visión general de las rutas en Google Cloud, consulta el artículo Descripción general de las rutas.

Consideraciones para crear rutas estáticas

Puede crear rutas estáticas de dos formas:

• Puedes crear rutas estáticas manualmente mediante la consolaGoogle Cloud , gcloud compute routes create o la API routes.insert.

• Si usas la Google Cloud consola para crear un túnel de VPN clásica que no use el enrutamiento dinámico, Cloud VPN podría crear rutas estáticas correspondientes automáticamente. Para obtener más información, consulta Redes y enrutamiento de túneles de Cloud VPN.

Puedes intercambiar rutas estáticas con una red de VPC emparejada tal como se describe en Opciones para intercambiar rutas estáticas personalizadas en la documentación sobre el emparejamiento entre redes de VPC.

Parámetros de ruta

Las rutas estáticas admiten los siguientes atributos:

• Nombre y Descripción. Estos campos identifican la ruta. Es obligatorio indicar un nombre, pero la descripción es opcional. Cada ruta de tu proyecto debe tener un nombre único.

• Red Cada ruta debe estar asociada exactamente a una red de VPC.

• Siguiente salto. El siguiente salto identifica el recurso de red al que se envían los paquetes. Todos los tipos de siguiente salto admiten destinos IPv4 y algunos tipos de siguiente salto admiten destinos IPv6. Para obtener más información, consulta Saltos siguientes y funciones.

• Intervalo de destino. El intervalo de destino es una sola notación CIDR IPv4 o IPv6.

  Los destinos de las rutas estáticas deben seguir las reglas descritas en Interacciones entre rutas de subred y rutas estáticas y en Interacciones entre subredes y rutas estáticas de Emparejamiento entre redes de VPC. El destino más amplio posible para una ruta estática IPv4 es 0.0.0.0/0. El destino más amplio posible para una ruta estática IPv6 es ::/0.

• Prioridad Los números más bajos indican prioridades más altas. La prioridad más alta posible es 0 y la más baja, 65,535.

• Etiquetas de red Puedes hacer que una ruta estática se aplique solo a determinadas instancias de VM de la red de VPC, identificadas por una etiqueta de red:

  • Una ruta estática sin etiqueta de red se aplica a todos los recursos de la red de VPC, incluidas todas las instancias de VM, los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect, los dispositivos de router y los proxies de Envoy en subredes solo de proxy.

  • Una ruta estática con una etiqueta de red solo se aplica a las instancias de VM que tienen esa etiqueta de red. No se aplica a ningún otro recurso.

  • Las rutas estáticas con etiquetas nunca se intercambian cuando se usa el emparejamiento entre redes de VPC.

Siguientes saltos y funciones

En la siguiente tabla se resume la compatibilidad de las funciones de ruta estática por tipo de siguiente salto:

Proyecto y red del siguiente salto

Un siguiente salto de una ruta estática se asocia tanto a una red de VPC como a un proyecto:

• Red: salvo que se indique lo contrario en la siguiente tabla, la red de VPC del siguiente salto debe coincidir con la red de VPC de la ruta.

• Proyecto: salvo que se indique lo contrario en la siguiente tabla, el salto siguiente debe estar ubicado en el proyecto que contiene la red de VPC del salto siguiente (un proyecto independiente o un proyecto de host de VPC compartida). Algunos saltos siguientes pueden estar ubicados en proyectos de servicio de VPC compartida.

Consideraciones comunes a los siguientes saltos de balanceadores de carga de red de paso a través internos y de instancias

El enrutamiento basado en instancias hace referencia a una ruta estática con un siguiente salto que es una instancia de VM (next-hop-instance o next-hop-address).

Balanceador de carga de red de paso a través interno como siguiente salto hace referencia a una ruta estática con un siguiente salto que es un balanceador de carga de red de paso a través interno (next-hop-ilb).

Cuando configures el enrutamiento basado en instancias o un balanceador de carga de red de paso a través interno como siguiente salto, ten en cuenta las siguientes directrices:

• Debes configurar las VMs de backend o la instancia del siguiente salto para que reenvíen paquetes desde cualquier dirección IP de origen. Para configurar el reenvío, habilita el reenvío de IP (can-ip-forward) en cada VM al crearla. En el caso de las VMs creadas automáticamente como parte de un grupo de instancias gestionado, habilita el reenvío de IP en la plantilla de instancias que usa el grupo de instancias. Debes hacer este cambio de configuración además de cualquier configuración del sistema operativo que sea necesaria para enrutar paquetes.

• El software que se ejecuta en la VM de backend o en la instancia de siguiente salto debe estar configurado correctamente. Por ejemplo, las máquinas virtuales de dispositivos de terceros que actúan como routers o cortafuegos deben configurarse de acuerdo con las instrucciones del fabricante.

• Las VMs de backend o la instancia de siguiente salto deben tener las reglas de firewall adecuadas. Debe configurar reglas de cortafuegos que se apliquen a los paquetes que se enrutan. Ten en cuenta lo siguiente:

  • Las reglas de cortafuegos de entrada aplicables a las instancias que realizan funciones de enrutamiento deben incluir las direcciones IP de las fuentes de paquetes enrutados. La regla de denegación implícita de entrada bloquea todos los paquetes entrantes, por lo que debe crear al menos reglas de cortafuegos de entrada personalizadas.
  • Las reglas de cortafuegos de salida aplicables a las instancias que realizan funciones de enrutamiento deben incluir las direcciones IP de los destinos de los paquetes enrutados. La regla de salida implícita permite esto, a menos que hayas creado una regla de denegación de salida específica para anularla.
  • Ten en cuenta si la máquina virtual backend o la instancia de salto siguiente realizan la traducción de direcciones de red (NAT) al crear tus reglas de firewall.

  Para obtener más información, consulta las reglas de cortafuegos implícitas.

• La región de origen de un paquete enviado por una VM de backend o una instancia de siguiente salto es la región en la que se encuentra la VM de backend o la instancia de siguiente salto. Por ejemplo, los paquetes procesados por las VMs de backend o las instancias de salto siguiente en us-west1 se pueden enviar a destinos que solo sean accesibles en us-west1, aunque la VM de backend o la instancia de salto siguiente hayan recibido originalmente el paquete de un recurso de una región distinta a us-west1. Estos son algunos ejemplos de recursos a los que solo se puede acceder en la misma región que una VM que envía un paquete:

  • Balanceadores de carga de red de paso a través internos, balanceadores de carga de aplicación internos y balanceadores de carga de red con proxy internos regionales con el acceso global desactivado
  • Túneles de Cloud VPN, vinculaciones de VLAN de Cloud Interconnect y VMs de dispositivo Network Connectivity Router si la red de VPC usa el enrutamiento dinámico regional

Consideraciones sobre las instancias del siguiente salto

• Siguiente salto por nombre de instancia y zona (next-hop-instance): cuando creas una ruta estática que tiene una instancia de siguiente salto especificada por el nombre y la zona de la instancia, Google Cloud requiere que exista una instancia con ese nombre en la zona especificada y que cumpla lo siguiente:

  • La instancia se encuentra en el mismo proyecto que la ruta.
  • La instancia tiene una interfaz de red en la red de VPC de la ruta (no en una red de VPC emparejada).

  Mientras exista la ruta estática, se aplicará lo siguiente:

  • Google Cloud actualiza automáticamente la programación del siguiente salto en cualquiera de los siguientes casos:

    • Cambia la dirección IPv4 interna principal de la instancia del siguiente salto.
    • Sustituyes la instancia de siguiente salto y la instancia de sustitución tiene el mismo nombre, está en la misma zona y proyecto, y tiene una interfaz de red en la red de VPC de la ruta.

  • Google Cloud no actualiza la programación del siguiente salto en los siguientes casos:

    • Cuando se elimina la instancia.
    • Cambia el intervalo de direcciones IPv6 asignado a la NIC de la instancia.
    • Cuando se desasigna la dirección IPv4 o IPv6 de la instancia.

• Dirección IP de la instancia del siguiente salto (next-hop-address): las direcciones IP de VM válidas del siguiente salto son las siguientes:
  • Dirección IPv4 interna principal de una interfaz de red de una máquina virtual.
  • Cualquier dirección IPv6 interna o externa del /96 intervalo de direcciones IPv6 asignado a una interfaz de red de una VM.

  Cuando creas una ruta estática con una instancia de siguiente salto especificada por una dirección IP, Google Cloud acepta cualquier dirección IP asignada a una VM que se ajuste a un intervalo de subred de una subred de la misma red VPC que la ruta. Sin embargo, Google Cloud solo programa la ruta si la dirección del siguiente salto es una dirección IP de máquina virtual siguiente salto válida. Por ejemplo, si creas una ruta y especificas el siguiente salto como una dirección IP que procede de un intervalo de direcciones IP de alias, se creará la ruta. Sin embargo, como las direcciones IP de alias no son direcciones IP de máquinas virtuales de siguiente salto válidas, la ruta no se programa.

  Google Cloud actualiza automáticamente la programación del siguiente salto si la dirección IP del siguiente salto se mueve a otra máquina virtual, siempre que la dirección IP siga siendo una dirección IP válida de la máquina virtual del siguiente salto.

  Cuando especificas una instancia de siguiente salto por dirección IP, los paquetes se enrutan a la interfaz de red de la instancia, no a la dirección IP específica.

• Instancias de salto siguiente en proyectos de servicio de VPC compartida: cuando especificas una VM de salto siguiente por dirección IP, la VM puede estar ubicada en cualquiera de los siguientes proyectos: el mismo proyecto que la ruta (un proyecto independiente o un proyecto host de VPC compartida) o un proyecto de servicio de VPC compartida. Cuando especificas una VM de siguiente salto por nombre de instancia y zona, la VM de siguiente salto debe estar ubicada en el mismo proyecto que la ruta y la red de VPC (un proyecto independiente o un proyecto host de VPC compartida).

• Costes y latencia de región a región: cuando usas una VM como siguiente salto, este se encuentra en una zona de una región. La ruta que usa el siguiente salto está disponible para todas las instancias de la misma red VPC o para las instancias seleccionadas con una etiqueta de red coincidente. Google Cloud no tiene en cuenta la distancia regional de las rutas que usan una instancia como siguiente salto, por lo que es posible crear una ruta que envíe tráfico a una VM de siguiente salto en otra región. El envío de paquetes de una región a otra añade costes de transferencia de datos de salida y provoca latencia de red.

• Sin comprobación del estado ni validación de la configuración: Google Cloud nunca comprueba si una instancia de siguiente salto cumple todos los requisitos que se indican en la sección Consideraciones comunes a las instancias y a los siguientes saltos de los balanceadores de carga de red de pases internos. Si inhabilitas la interfaz de red de la VM configurando el sistema operativo invitado de la instancia, no se ignorará la instancia del siguiente salto. Google Cloud

• No se ofrece hashing simétrico al conectar dos redes de VPC: Google Cloud no ofrece hashing simétrico cuando se usan dos o más VMs de salto siguiente que tienen varias interfaces de red en una configuración que cumple todos los criterios siguientes:

  • Las máquinas virtuales tienen una interfaz de red en una red de VPC y otra interfaz en una segunda red de VPC.
  • En cada red de VPC, hay un conjunto de al menos dos rutas estáticas personalizadas para el mismo destino, con la misma prioridad, donde cada ruta del conjunto hace referencia a una VM de salto siguiente única.

  Si usas dos o más VMs con varias interfaces para conectar redes de VPC y necesitas que la misma VM procese paquetes de una conexión determinada en ambas direcciones, debes usar el hashing simétrico, que solo es compatible con los balanceadores de carga de red internos de pases directos de próximo salto. Para obtener más información, consulta Hashing simétrico.

• Comportamiento cuando se detienen o eliminan instancias: Google Cloud no impide que detengas o elimines una VM de salto siguiente de una ruta estática (especificada por el nombre y la zona, o por la dirección interna). Cuando una VM de siguiente salto no está en ejecución, el enrutamiento depende de si existen otras rutas para el mismo destino y de si esas otras rutas tienen siguientes saltos que están en ejecución. Para ilustrar este comportamiento, veamos los siguientes ejemplos:

  • Tienes las siguientes rutas y estados de la VM:

    • route-a, destino 192.168.168.0/24, prioridad 10, la VM del siguiente salto vm-a está detenida
    • route-b, destino 192.168.168.0/24, prioridad 20, la VM del siguiente salto vm-b está en ejecución
    • route-c, destino 192.168.168.0/24, prioridad 30, la VM del siguiente salto vm-c está en ejecución

    En este ejemplo, los paquetes cuyo destino se ajusta a 192.168.168.0/24 se envían al siguiente salto vm-b porque el siguiente salto vm-a de la prioridad más alta route-a no está activo. Esto se debe a que el paso Ignorar rutas estáticas y dinámicas con saltos siguientes no utilizables precede al paso Ignorar rutas de baja prioridad en elGoogle Cloud orden de enrutamiento.

  • Tienes las siguientes rutas y estados de la VM:

    • route-x, destino 192.168.168.0/24, prioridad 10, la VM del siguiente salto vm-x está detenida
    • route-y, destino 192.168.168.0/24, prioridad 20, la VM del siguiente salto vm-y está detenida
    • route-z, destino 192.168.0.0/16, prioridad 0, siguiente salto La VM vm-z está en ejecución

    En este ejemplo, los paquetes cuyo destino se ajusta a 192.168.168.0/24 se descartan porque las VMs de siguiente salto de las dos rutas 192.168.168.0/24 (route-x y route-y) no se están ejecutando, aunque exista una ruta para el destino 192.168.0.0/16 más amplio (route-z) con una VM de siguiente salto en ejecución. Esto ocurre porque el paso de destino más específico precede al paso de ignorar las rutas estáticas y dinámicas con los siguientes saltos inutilizables en elGoogle Cloud orden de enrutamiento.

Consideraciones sobre los siguientes saltos de los balanceadores de carga de red de paso a través internos

• Reglas de reenvío admitidas: Google Cloud solo se admiten las reglas de reenvío de balanceadores de carga de red internos de transferencia directa de siguiente salto. Google Cloud No se admiten las reglas de reenvío de siguiente salto que usan otros balanceadores de carga, la redirección de protocolos ni los endpoints de Private Service Connect.

• Métodos de especificación y red y proyecto de la regla de reenvío. Puede especificar una regla de reenvío de salto siguiente mediante uno de los tres métodos siguientes. El método de especificación que utilices determinará si la red de la regla de reenvío debe coincidir con la red de la ruta y en qué proyecto se puede encontrar la regla de reenvío.

  Elige uno de los siguientes métodos y asegúrate de que la versión de IP de tu regla de reenvío coincida con la versión de IP de la ruta estática que crees:

  • Por nombre de regla de reenvío (--next-hop-ilb) y región (--next-hop-ilb-region): cuando especifiques una regla de reenvío de salto siguiente por nombre y región, la red de la regla de reenvío debe coincidir con la red VPC de la ruta. La regla de reenvío debe estar en el mismo proyecto que la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida).

  • Por enlace de recurso de regla de reenvío: el enlace de recurso de una regla de reenvío usa el formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, donde PROJECT_ID es el ID del proyecto que contiene la regla de reenvío, REGION es la región de la regla de reenvío y FORWARDING_RULE_NAME es el nombre de la regla de reenvío. Cuando especifiques una regla de reenvío del siguiente salto por su enlace de recurso, la red de la regla de reenvío debe coincidir con la red VPC de la ruta. La regla de reenvío puede estar en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto del host de VPC compartida) o en un proyecto de servicio de VPC compartida.

  • Por la dirección IP de una regla de reenvío: cuando especifiques una regla de reenvío de próximo salto por su dirección IPv4 o IPv6, la red de la regla de reenvío puede ser la red de VPC de la ruta o una red de VPC conectada a la red de VPC de la ruta mediante el emparejamiento entre redes de VPC o Network Connectivity Center. Network Connectivity Center admite un balanceador de carga de red de paso a través interno de siguiente salto en una VPC de radio sujeta a los requisitos de conectividad de Network Connectivity Center. La regla de reenvío puede estar en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto del host de VPC compartida) o en un proyecto de servicio de VPC compartida.

• Efecto del acceso global. Las rutas estáticas personalizadas que usan saltos siguientes de balanceadores de carga de red de paso a través internos se programan en todas las regiones. Si el siguiente salto se puede usar o no, depende de la configuración de acceso global del balanceador de carga. Si el acceso global está habilitado, se puede acceder al siguiente salto del balanceador de carga en todas las regiones de la red de VPC. Si el acceso global está inhabilitado, solo se puede acceder al siguiente salto del balanceador de carga en la misma región que el balanceador de carga. Si el acceso global está inhabilitado, los paquetes enviados desde otra región a una ruta que use un balanceador de carga de red con paso a través interno como siguiente salto se descartarán.

• Cuando todos los backends están en mal estado. Cuando todas las backends de un balanceador de carga de red interno de tipo pasarela fallan en las comprobaciones de estado, las rutas que usan el siguiente salto de ese balanceador de carga siguen activas. Los paquetes procesados por la ruta se envían a uno de los backends del balanceador de carga del siguiente salto según la distribución del tráfico.

• No se admiten reglas de reenvío que usen una dirección IP interna común (--purpose=SHARED_LOADBALANCER_VIP). Los balanceadores de carga de red de paso a través internos del siguiente salto y las reglas de reenvío de balanceadores de carga de red de paso a través internos con una dirección IP común son funciones mutuamente exclusivas. Un balanceador de carga de red de pases interno de siguiente salto debe usar una dirección IP única para la regla de reenvío del balanceador de carga, de modo que solo se haga referencia a un servicio de backend (un balanceador de carga) de forma inequívoca. Es posible que las reglas de reenvío que usan una dirección IP interna común hagan referencia a diferentes servicios de backend (diferentes balanceadores de carga de red de transferencia internos).

• Varias rutas con los mismos destinos y prioridades, pero con diferentes balanceadores de carga de red de paso a través internos del siguiente salto. Google Cloud Nunca distribuye el tráfico entre dos o más balanceadores de carga de red de paso a través internos del siguiente salto mediante ECMP. En su lugar,Google Cloud selecciona solo un balanceador de carga de red de paso a través interno del siguiente salto mediante un algoritmo interno determinista. Para evitar esta ambigüedad, puedes usar etiquetas de red únicas para cada ruta.

  

• Varias rutas con los mismos destinos, prioridades y saltos siguientes balanceadores de carga de red de transferencia interna. Sin una etiqueta de red, Google Cloud no Google Cloud te permite crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y siguiente salto del balanceador de carga de red de paso a través interno. Con las etiquetas de red, puedes crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y siguiente salto del balanceador de carga de red de paso a través interno.

Consideraciones sobre los saltos siguientes de los túneles de VPN clásica

• Costes y latencia entre regiones: Google Cloud no tiene en cuenta la distancia regional de las rutas que usan un túnel VPN clásico de salto siguiente. Si envías tráfico a un túnel de VPN clásica de salto siguiente en otra región, se añadirán costes de transferencia de datos salientes y se introducirá latencia de red. Como práctica recomendada, utiliza un túnel de VPN de alta disponibilidad con enrutamiento dinámico en su lugar, ya que esta configuración tiene en cuenta la distancia regional.

• Comportamiento cuando los túneles de VPN clásica no están activos: las rutas estáticas personalizadas cuyas siguientes saltos son túneles de VPN clásica no se eliminan automáticamente cuando los túneles de VPN clásica no están activos. Para obtener información sobre lo que ocurre cuando los túneles no están activos, consulta la sección Cuando los túneles no están activos de la documentación de VPN clásica.

Consideraciones sobre Network Connectivity Center

• Puedes crear rutas estáticas desde tus radios de VPC a balanceadores de carga de red internos de pases que sean accesibles a través del hub de Network Connectivity Center.
• Se aplican limitaciones adicionales a estas rutas estáticas de Network Connectivity Center. Para obtener más información, consulta la descripción general de las rutas estáticas.

Siguientes pasos

• Para crear y gestionar rutas, consulta Usar rutas.
• Para obtener una descripción general de las rutas Google Cloud, consulta Rutas.