Descripción general de las rutas

Las rutas de Google Cloud definen las rutas de acceso que recorre el tráfico de red de una instancia de máquina virtual (VM) a otros destinos. Estos destinos pueden estar dentro de tu red de nube privada virtual (VPC) de Google Cloud (por ejemplo, en otra VM) o fuera de ella.

En una red de VPC, una ruta consta de un único prefijo de destino en formato CIDR y un solo siguiente salto. Cuando una instancia en una red de VPC envía un paquete, Google Cloud entrega el paquete al siguiente salto de la ruta si la dirección de destino del paquete se encuentra dentro del rango de destino de la ruta.

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

Enrutamiento en Google Cloud

Cada red de VPC usa un mecanismo de enrutamiento virtual, distribuido y escalable. No hay ningún dispositivo físico asignado a la red. Algunas rutas se pueden aplicar de forma selectiva, pero la tabla de enrutamiento para una red de VPC se define a nivel de la red de VPC.

Cada instancia de VM tiene un controlador que se mantiene informado sobre todas las rutas aplicables desde la tabla de enrutamiento de la red. Cada paquete que sale de una VM se entrega al siguiente salto apropiado de una ruta aplicable en función de un orden de enrutamiento. Cuando agregas o borras una ruta, el conjunto de cambios se propaga a los controladores de VM mediante un diseño de coherencia eventual.

Tipos de ruta

En las siguientes tablas, se resume la forma en que Google Cloud clasifica las rutas en las redes de VPC.

Tipo y destino Siguiente salto Notas
Rutas generadas por el sistema
Ruta predeterminada generada por el sistema
0.0.0.0/0
default-internet-gateway Se aplica a toda la red de VPC

Se puede quitar o reemplazar
Ruta de subred
Se crea de forma automática para cada rango de direcciones IP de la subred
Red de VPC
Reenvía paquetes a VM y balanceadores de cargas internos
Se aplica a toda la red de VPC

Google Cloud la crea, actualiza y quita de forma automática cuando creas, modificas o borras una subred o un rango de direcciones IP secundario de una subred.
Rutas personalizadas
Ruta estática
Admite varios destinos
Siguiente salto de ruta estática válido Para los balanceadores de cargas de TCP/UDP internos de siguiente salto, solo se aplica al tráfico de TCP y UDP en la misma región que el balanceador de cargas, a menos que esté habilitado el acceso global.

Para otros siguientes saltos estáticos: La ruta puede aplicarse a VM específicas si especificas etiquetas de red en la ruta. Si no especificas ninguna etiqueta de red, la ruta se aplica a todas las VM de la red de VPC.
Ruta dinámica
Los destinos que no entran en conflicto con las rutas de las subredes ni las rutas estáticas
Par de una sesión de BGP en un Cloud Router Los Cloud Routers agregan y quitan las rutas en la red de VPC de forma automática.

Las rutas se aplican a las VM según el modo de enrutamiento dinámico de la red de VPC.
Rutas de intercambio de tráfico
Ruta de subred de intercambio de tráfico
Representa un rango de direcciones IP de subred en una red conectada mediante el intercambio de tráfico entre redes de VPC.
Red de VPC de intercambio de tráfico
Reenvía paquetes a VM y balanceadores de cargas internos en la red de intercambio de tráfico.
Se aplica a toda la red de VPC

Google Cloud la crea, actualiza y quita de forma automática cuando se crean, modifican o borran subredes en la red de intercambio de tráfico.
Ruta personalizada de intercambio de tráfico
Ruta dinámica o estática personalizada en una red conectada mediante el intercambio de tráfico entre redes de VPC
Siguiente salto en la red de VPC de intercambio de tráfico Las rutas personalizadas de intercambio de tráfico respaldadas por rutas estáticas en la red de intercambio de tráfico se aplican de la siguiente manera:
  • Si la ruta personalizada de intercambio de tráfico está respaldada por una ruta estática personalizada cuyo siguiente salto es un balanceador de cargas de TCP/UDP interno, la ruta se aplica al tráfico de TCP y UDP en la misma región que el balanceador de cargas, a menos que el acceso global esté habilitado en la regla de reenvío del balanceador de cargas.
  • Si la ruta personalizada de intercambio de tráfico está respaldada por una ruta estática personalizada cuyo siguiente salto no es un balanceador de cargas de TCP/UDP interno, y esa ruta estática personalizada no tiene una etiqueta asociada, la ruta se aplica a todas las VM en la red de VPC que importa la ruta.
  • Las rutas estáticas en una red de intercambio de tráfico que usan etiquetas de red o cuyos siguientes saltos son la puerta de enlace de Internet predeterminada nunca se exportan en una relación de intercambio de tráfico.
Las rutas personalizadas de intercambio de tráfico respaldadas por rutas dinámicas en la red de intercambio de tráfico se aplican de acuerdo con el modo de enrutamiento dinámico de la red de VPC que importa las rutas.

Ruta predeterminada generada por el sistema

Cuando creas una red de VPC, se incluye una ruta predeterminada generada por el sistema. Esta ruta predeterminada tiene los siguientes dos propósitos:

  • Define la ruta de acceso fuera de la red de VPC, incluida la ruta de acceso a Internet. Además de tener esta ruta, las instancias deben cumplir con requisitos adicionales si necesitan acceso a Internet.

  • Brinda la ruta de acceso estándar para el Acceso privado a Google.

La ruta predeterminada que genera el sistema tiene una prioridad de 1000. Dado que su destino es el más amplio posible (0.0.0.0/0), Google Cloud solo lo usa si no se aplica una ruta con un destino más específico a un paquete. A fin de obtener información sobre cómo se usan la especificidad de destino y la prioridad de ruta para seleccionar una ruta, consulta Orden de enrutamiento.

Si deseas aislar por completo tu red de Internet o si necesitas reemplazar la ruta predeterminada por una personalizada, puedes borrar la ruta predeterminada:

  • Si deseas enrutar el tráfico de Internet a un siguiente salto diferente, puedes reemplazar la ruta predeterminada por una ruta estática o dinámica personalizada. Por ejemplo, podrías reemplazarla por una ruta estática personalizada cuyo siguiente salto sea una VM de proxy.

  • Si quitas la ruta predeterminada y no la reemplazas, se descartan los paquetes destinados a rangos de IP que no están cubiertos por otras rutas.

Rutas de subred

Las rutas de subred definen las rutas de acceso a recursos como VM y balanceadores de cargas internos en una red de VPC.

Cada subred tiene al menos una ruta de subred cuyo destino coincide con el rango de IP principal de la subred. Si la subred tiene rangos de IP secundarios, hay una ruta de subred correspondiente para cada uno de los rangos de direcciones IP secundarios. Para obtener más información sobre los rangos de IP de subred, consulta Redes y subredes.

Ninguna otra ruta puede tener un destino que coincida o sea más específico (con una máscara de subred más larga) que el destino de una ruta de subred.

Las rutas de subred siempre tienen los destinos más específicos. Las otras rutas no pueden anularlos, incluso aunque otra ruta tenga mayor prioridad. Esto se debe a que Google Cloud considera la especificidad del destino antes que la prioridad cuando se selecciona una ruta. Google Cloud usa 0 como prioridad para todas las rutas de subred.

En los siguientes puntos, se describe cómo se crean y quitan las rutas de subred:

  • Cuando agregas una subred, Google Cloud crea una ruta de subred correspondiente para el rango de direcciones IP principal de la subred.

  • Las redes de VPC en modo automático crean una ruta de subred para los rangos de IP principales de cada una de sus subredes creadas de forma automática. Puedes borrar estas subredes solo si conviertes la red de VPC de modo automático a modo personalizado.

  • No puedes borrar una ruta de subred a menos que modifiques o borres la subred:

    • Cuando quitas un rango secundario de una subred, la ruta de subred para ese rango secundario se quita de forma automática.

    • Cuando quitas una subred, todas las rutas de subred para los rangos principal y secundario se borran automáticamente. No puedes borrar la ruta de subred para el rango principal de la subred de ninguna otra manera.

La cantidad de rutas de subred en una red de VPC está limitada por la cantidad máxima de rangos de IP de subred (principales y secundarios).

Rutas estáticas

Las rutas estáticas se definen mediante los parámetros de ruta estática y admiten los siguientes saltos de las rutas estáticas. Puedes crear rutas estáticas de las siguientes dos maneras:

Rutas dinámicas

Los Cloud Routers administran las rutas dinámicas en la red de VPC. Los destinos siempre representan rangos de direcciones IP fuera de la red de VPC, recibidos de un par de BGP. Las rutas dinámicas se usan de la siguiente manera:

Las redes de VPC ignoran los destinos que reciben los Cloud Routers cuando los destinos coinciden con cualquiera de estos criterios:

  • El destino coincide de forma exacta con un rango de direcciones IP de subred.

  • El destino se ajusta dentro de un rango de direcciones IP de subred (tiene una máscara de subred más larga).

Es aceptable que el destino de una ruta dinámica contenga un rango de direcciones IP de subred (tenga una máscara de subred más corta). En ese caso, los paquetes solo se envían al siguiente salto de la ruta dinámica si no se ajustan al destino de la ruta de subred. El destino más amplio posible es 0.0.0.0/0.

Rutas de subred de intercambio de tráfico

Las rutas de subred de intercambio de tráfico definen rutas de acceso a los recursos mediante subredes en otra red de VPC conectada a través del intercambio de tráfico entre redes de VPC. La otra red se llama red de VPC de intercambio de tráfico.

Las redes de intercambio de tráfico comparten rutas de subred de la siguiente manera:

  • Las redes de intercambio de tráfico siempre exportan las rutas de subred para todos los rangos de direcciones IP principales y secundarios.

  • Las redes de intercambio de tráfico importan de forma automática las rutas de subred, siempre que el destino de la ruta (rango de direcciones IP de la subred) no sea una dirección IP pública reutilizada de forma privada. Puedes configurar un par para importar las rutas de subred que usan direcciones IP públicas reutilizadas de forma privada, si es necesario.

  • Las rutas de subred de intercambio de tráfico importadas no se pueden quitar, a menos que inhabilites el intercambio de tráfico. Cuando inhabilitas el intercambio de tráfico, todas las rutas de subred de intercambio de tráfico importadas se quitan de forma automática.

  • Google Cloud evita los conflictos de rangos de direcciones IP de subred entre redes con intercambio de tráfico.

La cantidad combinada de rutas de subred en una red de VPC y rutas de subred de intercambio de tráfico importadas de todas las redes de intercambio de tráfico está limitada por la cantidad máxima de rangos de IP de subred (principales y secundarios).

Rutas personalizadas de intercambio de tráfico

Puedes configurar redes de intercambio de tráfico para exportar o importar rutas personalizadas. En este contexto, el término rutas personalizadas hace referencia a rutas estáticas y dinámicas en una red de VPC.

Incluso cuando una red de VPC está configurada para exportar las rutas personalizadas, omite los siguientes tipos de rutas:

La cantidad combinada de rutas estáticas y dinámicas en una red de VPC más las rutas personalizadas de intercambio de tráfico importadas de todas las redes de intercambio de tráfico está limitada por lo siguiente:

  • Cantidad máxima de rutas estáticas de un grupo de intercambio de tráfico
  • Cantidad máxima de rutas dinámicas de un grupo de intercambio de tráfico

Aplicabilidad y orden

Rutas aplicables

Cada instancia tiene un conjunto de rutas aplicables, que son un subconjunto de todas las rutas en la red de VPC. Las rutas aplicables son las posibles rutas de acceso de salida que un paquete puede tomar cuando se envía desde la instancia.

  • Las rutas de subred y las rutas de subred de intercambio de tráfico se aplican a todas las instancias. Las rutas de subred y las rutas de subred de intercambio de tráfico corresponden a subredes en la red de VPC y a las importadas de redes de intercambio de tráfico.

  • La ruta predeterminada generada por el sistema se aplica a todas las instancias. Puedes reemplazar la ruta predeterminada generada por el sistema con una ruta estática personalizada si lo prefieres.

  • Las rutas estáticas personalizadas se pueden aplicar a todas las instancias o a instancias específicas. Las rutas estáticas con un atributo de etiqueta se aplican a instancias que tienen esa misma etiqueta de red. Si la ruta no tiene una etiqueta de red, se aplica a todas las instancias de la red.

    • Cuando una ruta estática personalizada tiene un siguiente salto de instancia de VM, la ruta siempre es válida, incluso si la VM del siguiente salto se borra, se apaga o funciona mal. Para obtener más información, consulta Instancias como siguientes saltos.

    • Cuando una ruta estática personalizada tiene un siguiente salto de túnel de Cloud VPN, la ruta siempre es válida si el túnel está activo. Para obtener información sobre cómo controla Google Cloud las rutas de los túneles cuando están inactivos, consulta Cuando los túneles están inactivos en la documentación de Cloud VPN.

  • Las rutas dinámicas se aplican a las instancias según el modo de enrutamiento dinámico de la red de VPC. Si una red de VPC usa el modo de enrutamiento dinámico regional, todos los Cloud Routers solo crean rutas dinámicas para los prefijos aprendidos en la región local. Si una red de VPC usa el modo de enrutamiento dinámico global, todos los Cloud Routers crean rutas dinámicas para los prefijos aprendidos en todas las regiones.

    • Los Cloud Routers descartan de forma automática los prefijos aprendidos que corresponden a los siguientes saltos inaccesibles (túneles de Cloud VPN o adjuntos de Cloud Interconnect). Según la red, el tiempo de procesamiento de los Cloud Routers para quitar una ruta dinámica con un siguiente salto inactivo puede ser de hasta 40 segundos.
  • Para un poco de tráfico con balanceo de cargas, las rutas aplicables se originan fuera de tu red de VPC. Para obtener más información, consulta Rutas de acceso de retorno del balanceador de cargas.

Orden de enrutamiento

Cuando una instancia envía un paquete, Google Cloud intenta seleccionar una ruta del conjunto de rutas aplicables de acuerdo con el siguiente orden de enrutamiento.

  1. Las rutas de subred y las rutas de subred de intercambio de tráfico se consideran primero, porque estas rutas tienen los destinos más específicos. Google Cloud considera las rutas de subred de intercambio de tráfico de la misma manera que considera las rutas de subred locales.

    • Si la dirección IP de destino de un paquete se ajusta al destino de una subred o una ruta de subred de intercambio de tráfico, sucede lo siguiente:

      • Los paquetes se entregan a la dirección IP interna de una instancia de VM en ejecución o al balanceador de cargas interno configurado.

      • Los paquetes destinados a una instancia de VM detenida se descartan.

      • Los paquetes destinados a una dirección IP interna se descartan si no se configuró ningún recurso de Google Cloud para usar la dirección IP.

    • Google Cloud no te permite crear una ruta estática personalizada que tenga un destino igual o más específico que cualquier ruta de subred o ruta de subred de intercambio de tráfico.

    • Los Cloud Routers ignoran los prefijos aprendidos que coinciden de manera exacta con el destino de una ruta de subred o una ruta de subred de intercambio de tráfico.

    • Los Cloud Routers ignoran los prefijos aprendidos que se ajustan a una ruta de subred o una ruta de subred de intercambio de tráfico (tienen una máscara de subred más larga).

  2. Si el paquete no se puede enrutar con una ruta de subred o una ruta de subred de intercambio de tráfico, Google Cloud busca una ruta dinámica, estática o de intercambio de tráfico personalizada que tenga el destino más específico. Por ejemplo, 10.240.1.0/24 es un destino más específico que 10.240.0.0/16 para paquetes con el destino 10.240.1.4.

  3. Si más de una ruta tiene el mismo destino más específico, Google Cloud usa el siguiente proceso para seleccionar una ruta de las opciones de ruta. Las opciones de ruta son rutas estáticas, dinámicas y de intercambio de tráfico personalizadas con el mismo destino más específico.

    1. Si la red de VPC está conectada a redes de intercambio de tráfico, Google Cloud borra todas las opciones de ruta, excepto las de una única red de VPC.

      • Si hay una o más opciones de ruta en la red de VPC local, Google Cloud ignora todas las opciones de ruta de las redes de intercambio de tráfico.

      • Si ninguna de las opciones de ruta existe en la red de VPC local, pero existe en varias redes de intercambio de tráfico, Google Cloud ignora todas las opciones de ruta excepto las que se definen en una de las redes de intercambio de tráfico. Google Cloud usa un algoritmo interno para seleccionar la red de intercambio de tráfico única, y este algoritmo no tiene en cuenta la prioridad de ruta en este punto del proceso. Si realizas un intercambio de tráfico con una red nueva o te desconectas de una red de intercambio de tráfico existente, esto podría cambiar la red de VPC que Google Cloud elija.

    2. Google Cloud elimina todos los candidatos de ruta, excepto los que tienen la prioridad más alta. Si esto da como resultado una ruta única, Google Cloud envía el paquete al siguiente salto.

    3. Si varias opciones de ruta tienen la misma prioridad más alta, Google Cloud continúa el proceso de eliminación mediante el siguiente salto de la ruta y el tipo de la ruta. Si esto da como resultado una ruta única, Google Cloud envía el paquete al siguiente salto.

      1. Se prefieren las rutas estáticas personalizadas con instancia de siguiente salto, IP de siguiente salto o túnel VPN de siguiente salto. Todas las demás opciones de ruta se borran si existe una opción de ruta que usa este tipo de siguiente salto.

      2. Las rutas dinámicas personalizadas son las segundas más preferibles.

      3. Las rutas estáticas personalizadas con los balanceadores de cargas de TCP/UDP internos de siguiente salto son la tercera opción más preferible.

      4. Las rutas estáticas personalizadas que usan el siguiente salto de puerta de enlace de Internet predeterminado son las menos preferibles.

    4. Si aún permanecen más de una ruta entre las opciones de ruta, todas estas rutas se encuentran dentro de la misma red de VPC y tienen la misma prioridad más alta. Google Cloud distribuye el tráfico entre los siguientes saltos de las opciones de ruta mediante un hash quíntuple para lograr afinidad, con la implementación de rutas múltiples de igual costo (ECMP). Los cálculos de hash se realizan para cada paquete en el momento en que se envía, en función de la cantidad de opciones de ruta que determina el algoritmo de selección de ruta. Si cambia la cantidad de opciones de ruta, el hash puede dirigir un paquete con el mismo hash quíntuple a un siguiente salto diferente.

  4. Si no se encuentra un destino aplicable, Google Cloud descarta el paquete y responde con un error de destino de ICMP o red inaccesible.

Rutas de acceso de retorno especiales

Las redes de VPC tienen rutas especiales para ciertos servicios. Estas rutas se definen fuera de tu red de VPC, en la red de producción de Google. No aparecen en la tabla de enrutamiento de tu red de VPC. No puedes quitarlas ni anularlas, incluso si borras o reemplazas una ruta predeterminada en tu red de VPC. Sin embargo, puedes controlar el tráfico desde y hacia estos servicios mediante reglas de firewall.

Rutas de acceso de retorno del balanceador de cargas

Si usas uno de los siguientes balanceadores de cargas de Google Cloud, Google Cloud tiene rutas especiales para los balanceadores de cargas y sus verificaciones de estado asociadas, que se describen con más detalle en las siguientes secciones.

Rutas de acceso de retorno para los balanceadores de cargas de HTTP(S), y de proxies SSL y TCP

Para estos tipos de balanceadores de cargas, los sistemas de Google Front End (GFE) funcionan como proxies. Cuando un cliente envía una solicitud al balanceador de cargas, un proxy interrumpe la sesión TCP y abre una nueva sesión TCP con tu VM de backend. Las rutas definidas fuera de la red de VPC facilitan la comunicación de los proxies de GFE a las VM de backend y de las VM de backend a los proxies de GFE.

Si deseas obtener más información, consulta las páginas siguientes:

Rutas de acceso de retorno para los balanceadores de cargas de red

Cuando un cliente en Internet envía una solicitud TCP o UDP a una VM de backend a través de un balanceador de cargas de red, Google Cloud usa rutas definidas fuera de tu red de VPC para facilitar la comunicación del cliente a la VM de backend y de la VM de backend al cliente.

Para obtener más información, consulta Balanceo de cargas de red.

Verificaciones de estado para todos los tipos de balanceadores de cargas

Los paquetes enviados desde los sistemas de sondeo de verificación de estado de Google Cloud tienen los orígenes descritos en Rangos de IP del sondeo y reglas de firewall. Las rutas que facilitan la comunicación entre los sistemas de sondeo de verificación de estado de Google Cloud y las VM de backend existen fuera de tu red de VPC y no se pueden quitar. Sin embargo, la red de VPC debe tener reglas de firewall de permiso de entrada que permitan el tráfico desde estos sistemas.

IAP

Se incluye una ruta para 35.235.240.0/20 a fin de admitir el reenvío de TCP mediante IAP. La red de producción de Google no acepta rutas para 35.235.240.0/20 de otras fuentes en Internet.

Cloud DNS

Una ruta a 35.199.192.0/19 admite la conectividad a destinos de reenvío que usan enrutamiento privado o servidores de nombres alternativos que usan enrutamiento privado. La red de producción de Google no acepta rutas para 35.199.192.0/19 de otras fuentes en Internet.

Parámetros de ruta estática

Cada ruta estática consta de los siguientes componentes:

  • 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.

  • Rango de destino. El rango de destino es un solo bloque CIDR IPv4 que contiene las direcciones IP de los sistemas que reciben paquetes entrantes. Los destinos se deben expresar en notación CIDR. Los destinos no pueden coincidir de manera exacta con un rango de direcciones IP de subred ni pueden adaptarse a un rango de direcciones IP de subred (no pueden tener una máscara de subred más larga). Es aceptable que el destino de una ruta estática contenga un rango de direcciones IP de subred (una máscara de subred más corta). En ese caso, los paquetes solo se envían al siguiente salto de la ruta estática si no se ajustan al destino de la ruta de subred. El destino más amplio posible es 0.0.0.0/0.

  • Prioridad. Si varias rutas tienen destinos idénticos, se usa la prioridad para determinar qué ruta se debe usar. Los números más bajos indican prioridades mayores; por ejemplo, una ruta con un valor de prioridad de 100 tiene una prioridad mayor que una con un valor de prioridad de 200. La prioridad de ruta más alta es el número entero no negativo más pequeño posible. Dado que cero es el número entero no negativo más pequeño posible, tiene la prioridad más alta.

  • Siguiente salto. Las rutas estáticas pueden tener siguientes saltos que dirijan a la puerta de enlace de Internet predeterminada, a una instancia de Google Cloud o a un túnel de Cloud VPN. Para obtener más información, consulta Siguientes saltos de ruta estática.

  • Etiquetas. Puedes especificar una lista de etiquetas de red para que la ruta solo se aplique a las instancias que tengan al menos una de las etiquetas enumeradas. Si no especificas etiquetas, Google Cloud aplica la ruta a todas las instancias de la red. Los balanceadores de cargas de TCP/UDP internos de siguiente salto no admiten etiquetas de red.

Siguientes saltos de rutas estáticas

Estos son los siguientes saltos válidos para rutas estáticas. Para obtener más información sobre cada tipo, consulta la documentación de referencia de gcloud.

  • Puerta de enlace de siguiente salto (next-hop-gateway). Puedes especificar una puerta de enlace de Internet predeterminada para definir una ruta de acceso a direcciones IP externas.

  • Instancia del siguiente salto (next-hop-instance). Puedes dirigir el tráfico a una instancia existente en Google Cloud si especificas su nombre y zona. El tráfico se dirige a la dirección IP interna principal de la interfaz de red de la VM en la red de VPC en la que se define la ruta.

    • Si se cambia la dirección IP interna principal de la interfaz de red de la instancia de VM en la red de VPC, Google Cloud actualiza de forma automática la tabla de enrutamiento de la red de VPC para que el tráfico se envíe a la VM en su nueva dirección IP.

    • Si la VM se reemplaza por una VM nueva con el mismo nombre en la misma zona, Google Cloud actualiza la tabla de enrutamiento de la red de VPC de forma automática para dirigir el tráfico a la VM de reemplazo.

    • Google Cloud solo valida la existencia de una VM de siguiente salto cuando creas la ruta. No valida que la VM pueda procesar o reenviar paquetes. Si se borra la VM, pero no se la reemplaza, se sigue aplicando la ruta, lo que puede dar como resultado que se descarten paquetes. Para obtener más información, consulta Instancias como siguientes saltos.

  • Balanceador de cargas TCP/UDP interno de siguiente salto (next-hop-ilb). Para el balanceo de cargas de TCP/UDP interno, puedes usar la dirección IP del balanceador de cargas como un siguiente salto que distribuye el tráfico entre instancias de backend en buen estado. Por ejemplo, puedes usar una ruta estática personalizada cuyo siguiente salto es un balanceador de cargas TCP/UDP interno para distribuir el tráfico entre las VM de backend. No se puede especificar el alcance a instancias específicas de las rutas estáticas personalizadas que usan este siguiente salto mediante una etiqueta de red.

  • IP del siguiente salto (next-hop-address). Puedes proporcionar una dirección IP interna asignada a una VM de Google Cloud como siguiente salto.

    • Cuando usas next-hop-address, Google Cloud pasa el tráfico a cualquier instancia de VM asignada a esa dirección IP. Si reemplazas una instancia de VM por otra que usa la misma dirección IP, el tráfico se dirige al reemplazo, incluso si tiene un nombre diferente. Para definir un siguiente salto por nombre de VM, usa la instancia de siguiente salto.

    • Google Cloud solo verifica que la dirección IP sea un miembro válido del rango de IP principal o secundario de una subred cuando creas la ruta. No valida que exista una instancia en la dirección IP del siguiente salto. Si la dirección IP del siguiente salto no está asignada a ninguna instancia, se sigue aplicando la ruta, lo que puede dar como resultado que se descarten paquetes. A fin de obtener más información, consulta Consideraciones para instancias y siguientes saltos del balanceador de cargas.

    • No puedes especificar el siguiente salto de una dirección IP arbitraria: no se permiten direcciones fuera del rango de direcciones IP de una subred en tu red de VPC.

  • Túnel VPN de siguiente salto (next-hop-vpn-tunnel). Para los túneles de Cloud VPN que usan enrutamiento basado en políticas y VPN basadas en rutas, puedes dirigir el tráfico al túnel VPN mediante la creación de rutas cuyos siguientes saltos hacen referencia al túnel por su nombre y región. Google Cloud ignora las rutas cuyos siguientes saltos son túneles de Cloud VPN que están inactivos. Para obtener más ejemplos sobre cómo interactúan las rutas y los túneles de Cloud VPN, consulta los ejemplos de enrutamiento de Cloud VPN.

Consideraciones para el siguiente salto de instancias y balanceadores de cargas

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 TCP/UDP interno como siguiente salto hace referencia a una ruta estática con un siguiente salto que es un balanceador de cargas TCP/UDP interno (next-hop-ilb).

Si configuras el enrutamiento basado en instancias o un balanceador de cargas TCP/UDP interno como un siguiente salto, ten en cuenta los siguientes lineamientos:

  • Debes configurar las VM de backend o la instancia de siguiente salto para reenviar paquetes de otras fuentes (can-ip-forward). Puedes habilitar el reenvío de IP por VM cuando creas la VM. A fin de habilitar el reenvío de IP para VM que se crean de forma automática como parte de un grupo de instancias administrado, debes habilitar 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 VM 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.

Consideraciones específicas para instancias de siguiente salto

  • Cuando usas una instancia como siguiente salto (next-hop-instance o next-hop-address), recuerda que la instancia es un recurso zonal. Si seleccionas una zona, significa que seleccionaste una región. Google Cloud no tiene en cuenta la distancia regional para las rutas que usan una instancia de siguiente salto, por lo que es posible crear una ruta que envíe tráfico a un siguiente salto en una región diferente. Esto agrega costos de salida y aumenta la latencia de la red.

  • Google Cloud realiza una de las siguientes validaciones básicas solo cuando creas la ruta:

    • Si especificas next-hop-instance, la instancia ya debe existir.
    • Si especificas next-hop-address, la dirección IP debe estar en el rango de IP principal o secundario de una subred existente.
  • Si, por ejemplo, quitas una instancia o borras una subred más adelante, Google Cloud considera cualquier ruta que use esa instancia como un siguiente salto cuando evalúe las rutas aplicables. Esto puede provocar que algunos o todos los paquetes de un destino determinado se descarten, según las otras rutas de la red.

  • Si falla el software de una instancia de VM (como el sistema operativo de la VM o el proceso de la VM que enruta paquetes), los paquetes destinados a esa instancia se descartan. Para mejorar la confiabilidad, considera usar un balanceador de cargas TCP/UDP interno como un siguiente salto. Un balanceador de cargas TCP/UDP interno requiere una verificación de estado configurada, y esta verificación de estado determina cómo se enrutan las conexiones nuevas.

  • Si se inhabilita una interfaz de red mediante la configuración del sistema operativo invitado de la instancia, Google Cloud no deja de considerar la interfaz como el siguiente salto de una ruta.

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

Google Cloud no tiene en cuenta la distancia regional para 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 salida y aumenta la latencia de la red. Como práctica recomendada, usa túneles de VPN con alta disponibilidad o túneles de VPN clásica que usen enrutamiento dinámico en su lugar.

Próximos pasos