Rutas estáticas

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

Para obtener una descripción general de las rutas en Google Cloud, consulta la descripción general de las rutas.

Consideraciones para crear rutas estáticas

Puedes crear rutas estáticas de las siguientes dos maneras:

• Puedes crear rutas estáticas de forma manual mediante la consola de Google Cloud, gcloud compute routes create o la API de routes.insert.

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

Puedes intercambiar rutas estáticas con una red de VPC con intercambio de tráfico, como se describe en Opciones para intercambiar rutas estáticas personalizadas en la documentación de intercambio de tráfico entre redes de VPC.

Nota: Para las redes de VPC en modo automático, no crees rutas estáticas personalizadas cuyos destinos se ajusten al rango 10.128.0.0/9. Ese rango contiene subredes creadas automáticamente. Las rutas estáticas con destinos dentro de 10.128.0.0/9 que existen en una red de VCP de modo automático pueden inhabilitarse de forma inesperada cuando una región de GoogleCloud nueva esté disponible. Esto sucede porque se crea una ruta de subred nueva para el rango de direcciones IPv4 principal de la subred creada de forma automática en la región nueva. Para obtener más información, consulta los rangos de IP de modo automático y las consideraciones para las redes de VPC en modo automático.

Parámetros de ruta

Las rutas estáticas admiten los siguientes atributos:

• Nombre y descripción. Estos campos identifican la ruta. El nombre es obligatorio, pero la descripción es opcional. Cada ruta en el proyecto debe tener un nombre único.

• Red. Cada ruta debe estar asociada con solo una red de VPC.

• Próximo salto. El próximo salto identifica el recurso de red al que se envían los paquetes. Todos los tipos de próximo salto admiten destinos de IPv4, mientras que algunos tipos de próximo salto admiten destinos de IPv6. Para obtener más información, consulta Próximos saltos y características.

• Rango de destino. El rango 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 con rutas estáticas personalizadas y en Interacciones con rutas estáticas y de subred. 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.

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

• Etiquetas de red. Puedes hacer que una ruta estática se aplique solo a instancias de VM seleccionadas en la red de VPC, identificadas por una etiqueta de red. Si no especificas una etiqueta de red, Google Cloud hace que la ruta estática se aplique a todas las instancias de la red. Las rutas estáticas con etiquetas nunca se intercambian cuando se usa el intercambio de tráfico entre redes de VPC.

Próximos saltos y características

En la siguiente tabla, se resume la compatibilidad de características de ruta estática por tipo de próximo salto:

Tipo de salto siguiente	IPv4	IPv6	ECMP^1
Puerta de enlace de próximo salto (next-hop-gateway) Especifica una puerta de enlace de Internet predeterminada para definir una ruta de acceso a direcciones IP externas.
Instancia de próximo salto por nombre y zona (next-hop-instance) Envía paquetes a una VM de próximo salto que se identifica por nombre y zona y se encuentra en el mismo proyecto como la ruta. A fin de obtener más información, consulta Consideraciones para instancias de próximo salto.
Instancia de próximo salto por dirección (next-hop-address) Envía paquetes a una VM de próximo salto que identifica la dirección IPv4 interna principal o una dirección IPv6 interna o externa de su interfaz de red. Para obtener más información, consulta Consideraciones para instancias de próximo salto.		(Vista previa)
Balanceador de cargas de red de transferencia interna de próximo salto por nombre (next-hop-ilb) y región (next-hop-ilb-region) de la regla de reenvío Envía paquetes a backends de un balanceador de cargas de red de transferencia interna que se identifica por el nombre, la región y, de manera opcional, el proyecto de la regla de reenvío. Para obtener más información, consulta Consideraciones para próximos saltos de balanceador de cargas de red de transferencia interna.		(Vista previa)
Balanceador de cargas de red de transferencia interna de próximo salto por dirección (next-hop-ilb). Envía paquetes a backends de un balanceador de cargas de red de paso interno que se identifica mediante la dirección IP de la regla de reenvío del balanceador de cargas. Para obtener más información, consulta Consideraciones para próximos saltos de balanceador de cargas de red de transferencia interna.		(Vista previa)
Túnel de VPN clásica de próximo salto (next-hop-vpn-tunnel) Envía paquetes a un túnel de VPN clásica de próximo salto mediante el enrutamiento basado en políticas o VPN basadas en rutas. A fin de obtener más información, consulta Consideraciones para próximos saltos de túnel de VPN clásica.

¹Multiruta de igual costo (ECMP) significa que dos o más rutas estáticas pueden compartir el mismo rango de destino y prioridad. Aunque puedes crear dos o más rutas estáticas en una red de VPC con el mismo destino, la misma prioridad y el próximo salto de puerta de enlace de Internet predeterminado, el efecto es el mismo que tener una sola ruta estática que use el próximo salto de puerta de enlace de Internet predeterminado para ese destino y prioridad.

Proyecto y red de próximo salto

Un próximo salto de ruta estática está asociado a una red de VPC y a un proyecto:

• Red: excepto según se indica en la tabla que aparece a continuación, la red de VPC del próximo salto debe coincidir con la red de VPC de la ruta.

• Proyecto: Excepto por lo que se indica en la tabla a continuación, el próximo salto debe estar ubicado en el proyecto que contiene la red de VPC del próximo salto (un proyecto independiente o un proyecto host de VPC compartida). Algunos próximos saltos se pueden ubicar en los proyectos de servicio de VPC compartida.

Tipo de salto siguiente	Puede estar en una red de VPC con intercambio de tráfico	Puede estar en un proyecto de servicio de VPC compartida
Puerta de enlace del próximo salto: (next-hop-gateway)
Instancia de próximo salto por nombre (next-hop-instance)
Instancia de próximo salto por dirección (next-hop-address)
Balanceador de cargas de red de transferencia interna de próximo salto por nombre y región de la regla de reenvío (next-hop-ilb)
Balanceador de cargas de red interno de próximo salto por dirección (next-hop-ilb)
Túnel de VPN clásica de próximo salto (next-hop-vpn-tunnel)

Consideraciones comunes de próximos saltos de balanceadores de cargas de red de transferencia interno 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).

El balanceador de cargas de red de transferencia interno como próximo salto hace referencia a una ruta estática con un próximo salto que es un balanceador de cargas de red de transferencia interno (next-hop-ilb).

Si configuras el enrutamiento basado en instancias o un balanceador de cargas de red de transferencia interno como un próximo salto, ten en cuenta los siguientes lineamientos:

• Debes configurar las VMs de backend o la instancia de siguiente salto para reenviar paquetes desde cualquier dirección IP de origen. Para configurar el reenvío, habilita el reenvío de IP (can-ip-forward) por VM cuando crees la VM. Para las VMs creadas de forma automática como parte de un grupo de instancias administrado, habilita el reenvío de IP en la plantilla de instancias que usa el grupo de instancias. Debes hacer que esta configuración cambie además de realizar cualquier otro ajuste de la configuración del sistema operativo que sea necesario para enrutar paquetes.

• El software que se ejecuta en la VM de backend o en la instancia de siguiente salto debe configurarse de forma correcta. Por ejemplo, las VM de dispositivos de terceros que funcionan como routers o firewalls se deben configurar de acuerdo con las instrucciones del fabricante.

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

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

  Para obtener más información, consulta Reglas de firewall implícitas.

• La región de origen de un paquete enviado por una VM de backend o una instancia de próximo salto es la región en la que se encuentra la VM de backend o la instancia de próximo salto. Por ejemplo, los paquetes procesados por VMs de backend o instancias de próximo salto en us-west1 se pueden enviar a destinos a los que solo se puede acceder en us-west1, incluso si la VM de backend o la instancia de próximo salto originalmente recibió el paquete de un recurso en una región diferente de us-west1. Los siguientes 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 cargas de red de paso interno, balanceadores de cargas de aplicaciones internos y balanceadores de cargas de red de proxy interno regional con el acceso global desactivado
  • Túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect y VMs del dispositivo de router de conectividad de red si la red de VPC usa enrutamiento dinámico regional

Consideraciones para instancias de siguiente salto

• Próximo salto por nombre y zona de instancia (next-hop-instance): Cuando creas una ruta estática que tiene una instancia de próximo salto especificada por nombre de instancia y zona, Google Cloud requiere lo siguiente: existe una instancia con ese nombre en la zona especificada y cumple con lo siguiente:

  • La instancia se encuentra en el mismo proyecto que la ruta.
  • La instancia tiene una interfaz de red (NIC) en la red de VPC de la ruta (no una red de VPC con intercambio de tráfico).

  Siempre que exista la ruta estática, se aplica lo siguiente:

  • Google Cloud actualiza de forma automática la programación para el próximo salto en cualquiera de los siguientes casos:

    • Cambia la dirección IPv4 interna principal de la instancia de próximo salto.
    • Reemplazas la instancia de próximo salto, y la instancia de reemplazo 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 próximo salto en los siguientes casos:

    • Cuando se borra la instancia.
    • El rango de direcciones IPv6 asignado a los cambios de NIC de la instancia.
    • Cuando se anula la asignación de la dirección IPv4 o IPv6 de la instancia.

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

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

  Google Cloud actualiza automáticamente la programación para el próximo salto si la dirección IP del próximo salto se mueve a una VM diferente, siempre que la dirección IP siga siendo una dirección IP de VM de próximo salto válida.

  Cuando especificas una instancia de próximo 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 próximo salto en proyectos de servicio de VPC compartida: Cuando especificas una VM de próximo salto por dirección IP, la VM puede estar ubicada ya sea en el mismo proyecto que la ruta (un proyecto independiente o un proyecto host de VPC compartida) o la VM se puede encontrar en un proyecto de servicio de VPC compartida. Cuando especificas una VM de próximo salto por zona y nombre de instancia, la VM de próximo 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).

• Latencia y costos de región a región: Cuando usas una VM como un siguiente salto, el siguiente salto se encuentra en una zona de una región. La ruta que usa el siguiente salto está disponible para todas las instancias en la misma red de VPC o para seleccionar instancias con una etiqueta de red coincidente. Google Cloud no tiene en cuenta la distancia regional para 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 una región diferente. Enviar paquetes de una región a otra agrega costos de transferencia de datos salientes y agrega latencia a la red.

• No hay verificación de estado ni validación de configuración: Google Cloud nunca verifica si una instancia de próximo salto cumple con todos los requisitos descritos en la sección Consideraciones comunes de próximos saltos de balanceadores de cargas de red de transferencia internos y de instancias. Inhabilitar la interfaz de red de la VM mediante la configuración del sistema operativo invitado de la instancia no hace que Google Cloud ignore la instancia del siguiente salto.

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

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

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

• Comportamiento cuando se detienen o borran instancias: Google Cloud no te impide detener ni borrar una VM de próximo salto de ruta estática (especificada por nombre y zona o por la dirección interna). Cuando una VM de próximo salto no está en ejecución, el enrutamiento depende de si existen otras rutas para el mismo destino y si esas otras rutas tienen próximos saltos. Para ilustrar este comportamiento, considera los siguientes ejemplos:

  • Tienes las siguientes rutas y estados de VM:

    • route-a, destino 192.168.168.0/24, prioridad 10, se detiene la VM de próximo salto vm-a
    • route-b, destino 192.168.168.0/24, prioridad 20, se ejecuta la VM de próximo salto vm-b
    • route-c, destino 192.168.168.0/24, prioridad 30, la VM de próximo salto vm-c se está ejecutando

    En este ejemplo, los paquetes cuyos destinos se ajustan a 192.168.168.0/24 se envían al próximo salto vm-b porque no se ejecuta el próximo salto vm-a del route-a de mayor prioridad. Esto sucede porque el paso de ignorar las rutas estáticas y dinámicas con próximos saltos inutilizables precede al paso de ignorar las rutas de prioridad baja en el orden de enrutamiento de Google Cloud.

  • Tienes las siguientes rutas y estados de VM:

    • route-x, destino 192.168.168.0/24, prioridad 10, se detiene la VM de próximo salto vm-x
    • route-y, destino 192.168.168.0/24, prioridad 20, se detiene la VM de próximo salto vm-y
    • route-z, destino 192.168.0.0/16, prioridad 0, se ejecuta la VM de próximo salto vm-z

    En este ejemplo, se descartan los paquetes cuyos destinos se ajustan a 192.168.168.0/24 porque las VMs de próximo salto para las dos rutas 192.168.168.0/24 (route-x y route-y) no se ejecutan, aunque existe una ruta para el destino 192.168.0.0/16 más amplio (route-z) con una VM de próximo salto en ejecución. Esto sucede porque el paso de destino más específico precede al paso de ignorar rutas estáticas y dinámicas con próximos saltos inutilizables en el orden de enrutamiento de Google Cloud.

Consideraciones para próximos saltos de balanceadores de cargas de red de transferencia internos

• Reglas de reenvío compatibles. Google Cloud solo admite reglas de reenvío del balanceador de cargas de red de traspaso interno del próximo salto. Google Cloud no admite reglas de reenvío de próximo salto que usan otros balanceadores de cargas, reenvío de protocolos o extremos de Private Service Connect.

• Métodos de especificación y red y proyecto de la regla de reenvío. Puedes especificar una regla de reenvío de próximo salto mediante uno de los siguientes tres métodos. El método de especificación que uses determina si la red de la regla de reenvío debe coincidir con la red de la ruta y en qué proyecto se puede ubicar la regla de reenvío.

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

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

  • Por vínculo de recurso de la regla de reenvío: El vínculo del recurso de una regla de reenvío usa el siguiente 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 especificas una regla de reenvío de próximo salto por su vínculo de recurso, la red de la regla de reenvío debe coincidir con la red de VPC de la ruta. La regla de reenvío se puede ubicar en ya sea en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida) o en un proyecto de servicio de VPC compartida.

  • Por una dirección IP de la regla de reenvío: Cuando especificas una regla de reenvío de próximo salto por su dirección IPv4 o IPv6 (Versión preliminar), la red de la regla de reenvío puede ser tanto la red de VPC de la ruta como una red de VPC con intercambio de tráfico. La regla de reenvío se puede ubicar ya sea en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida) o en un proyecto de servicio de VPC compartida.

• Efecto del acceso global. Las rutas estáticas personalizadas que usan los próximos saltos del balanceador de cargas de red de transferencia interno se programan en todas las regiones. La posibilidad de que el siguiente salto se pueda usar depende del parámetro de configuración de acceso global del balanceador de cargas. Con el acceso global habilitado, se puede acceder al siguiente salto del balanceador de cargas en todas las regiones de la red de VPC. Con el acceso global inhabilitado, solo se puede acceder al siguiente salto del balanceador de cargas en la misma región del balanceador de cargas. Con el acceso global inhabilitado, los paquetes enviados desde otra región a una ruta mediante un próximo salto de balanceador de cargas de red de transferencia interno se descartan.

• Cuando todos los backends están en mal estado. Cuando todos los backends de un balanceador de cargas de red de transferencia interno no aprueban las verificaciones de estado, las rutas que usan ese próximo salto de balanceador de cargas aún están activas. Los paquetes que procesa la ruta se envían a uno de los backends del balanceador de cargas del siguiente salto según la distribución de tráfico.

• No se admiten las reglas de reenvío que usen una dirección IP interna común (--purpose=SHARED_LOADBALANCER_VIP). Los balanceadores de cargas de red de transferencia internos de próximo salto y las reglas de reenvío del balanceador de cargas de red de transferencia interno con una dirección IP común son funciones excluyentes entre sí. Un balanceador de cargas de red de transferencia interno de próximo salto debe usar una dirección IP que sea única para la regla de reenvío del balanceador de cargas para que solo se haga referencia a un servicio de backend (un balanceador de cargas) sin ninguna ambigüedad. 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 cargas de red de transferencia internos).

• Varias rutas con los mismos destinos y prioridades, pero diferentes balanceadores de cargas de red de transferencia interno de próximo salto. Google Cloud nunca distribuye el tráfico entre dos o más balanceadores de cargas de red de transferencia interno de próximo salto mediante ECMP. En su lugar, Google Cloud selecciona solo un balanceador de cargas de red de transferencia interno de próximo salto con un algoritmo interno y determinístico. Para evitar esta ambigüedad, puedes usar etiquetas de red únicas para cada ruta.

  

  Google Cloud selecciona un solo próximo salto cuando las rutas estáticas con diferentes próximos saltos de balanceador de cargas de red de transferencia interno tienen la misma prioridad y el mismo destino.

• Varias rutas con los mismos destinos, prioridades y balanceadores de cargas de red de transferencia interno de próximo salto. Sin una etiqueta de red, Google Cloud no te permite crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y próximo salto de balanceador de cargas de red de transferencia interno. Con las etiquetas de red, puedes crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y próximo salto de balanceador de cargas de red de transferencia interno.

Consideraciones para siguientes saltos de túnel de VPN clásica

• Costos y latencia de región a región: Google Cloud no tiene en cuenta la distancia regional de las rutas que usan un túnel de VPN clásica de siguiente salto. Enviar tráfico a un túnel de VPN clásica de siguiente salto en otra región agrega costos de transferencia de datos salientes y, además, ingresa la latencia de la red. Como práctica recomendada, usa un túnel de VPN con alta disponibilidad con enrutamiento dinámico, ya que esa configuración considera la distancia regional.

• Comportamiento cuando los túneles de VPN clásica no se están ejecutando: Las rutas estáticas personalizadas cuyos próximos saltos son túneles de VPN clásica no se quitan de forma automática cuando los túneles de VPN clásica no están en ejecución. Para obtener detalles sobre lo que sucede cuando los túneles no están en ejecución, consulta Cuando los túneles están inactivos en la documentación de VPN clásica.

¿Qué sigue?

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