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 destino (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. Aunque algunas rutas se pueden aplicar de forma selectiva, 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

Las redes de VPC pueden incluir rutas generadas por el sistema o rutas personalizadas.

En la siguiente tabla, se resumen las rutas generadas por el sistema, que se agregan o actualizan de forma automática cuando creas una red de VPC, agregas una subred, expandes el rango de IP principal de una subred o editas el rango de IP secundario de una subred. Se aplican a todas las instancias de la red de VPC.

Rutas generadas por el sistema
Tipo Destino Siguiente salto Extraíble
ruta predeterminada 0.0.0.0/0 default-internet-gateway
ruta de subred Rangos de IP de subred principales y secundarios
Red de VPC, que reenvía paquetes a VM en sus subredes Solo cuando se borra la subred o cuando cambias los rangos de IP secundarios de la subred

En la siguiente tabla, se resumen las rutas personalizadas, que creas y mantienes directamente o mediante Cloud Router.

Rutas personalizadas
Tipo Destino Siguiente salto Extraíble Se aplica a
ruta estática • Rango de IP que no se superpone de manera parcial ni exacta con ningún rango de IP de subred
• Rango de IP más amplio que un rango de IP de subred
Uno de estos:
• Instancia por nombre
• Instancia por dirección IP
• Túnel de Cloud VPN
Cualquiera de estos:
• Todas las instancias en la red
• Instancias específicas en la red, que se identifican con la etiqueta de red, si es que se puede especificar el alcance de la ruta mediante una etiqueta de red
ruta dinámica • Rango de IP que no se superpone de manera parcial ni exacta con ningún rango de IP de subred
• Rango de IP más amplio que un rango de IP de subred
Dirección IP del par de BGP de Cloud Router Solo puede hacerlo Cloud Router, si ya no recibe la ruta de su par de BGP • Instancias en la misma región que Cloud Router si la red de VPC está en modo de enrutamiento dinámico regional
• Todas las instancias si la red de VPC está en modo de enrutamiento dinámico global

Ruta predeterminada

Cuando creas una red de VPC, Google Cloud crea una ruta predeterminada que genera el sistema. Esta ruta tiene 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 una ruta con un destino más específico no se aplica 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 rutas.

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 otra instancia o un túnel de Cloud VPN, como un servidor 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 son rutas que genera el sistema y que definen rutas de acceso a cada subred en la 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, Google Cloud crea una ruta de subred con un destino correspondiente para cada rango secundario. 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 que el destino de la ruta de subred. Puedes crear una ruta personalizada con un rango de destino más amplio que contenga el rango de destino de la ruta de subred.

En casos de superposición de rango de IP, debido a que Google Cloud usa la especificidad de destino como primer criterio a fin de establecer el orden de enrutamiento, la ruta de subred siempre es el siguiente salto preferido para paquetes cuyos destinos se ajustan a su rango de destino. Esto es cierto incluso si otra ruta cuyo destino contiene el destino de la ruta de subred tiene una prioridad de ruta más alta.

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

  • Cuando se crea una subred, también se crea una ruta de subred correspondiente para el rango de IP principal de la subred.

    • Si agregas un rango de IP secundario a una subred, se crea una ruta de subred correspondiente para ese rango.
  • 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 principales y secundarios se borran de forma automática. No puedes quitar la ruta de subred para el rango principal de la subred de ninguna otra manera.

  • Cuando las redes se conectan mediante el intercambio de tráfico de red de VPC, las rutas de subred de una red se importan a la otra red y viceversa. Por lo tanto, todos los rangos de IP de subred principales y secundarios deben ser únicos.

    • Las rutas de subred para las subredes en redes de intercambio de tráfico no pueden quitarse, a menos que rompas la relación de intercambio de tráfico. Cuando la rompes, todas las rutas de subred importadas de la otra red se quitan de forma automática.

Las reglas de firewall pueden bloquear la comunicación entre instancias. Para obtener información sobre la comunicación de instancia a instancia, consulta Comunicación dentro de la red.

Rutas personalizadas

Las rutas personalizadas son rutas estáticas que puedes crear de forma manual o rutas dinámicas que uno o más de tus Cloud Routers mantienen automáticamente.

Los destinos de las rutas personalizadas no pueden coincidir o ser más específicos que cualquier ruta de subred en la red.

Si estás usando una red de VPC de modo automático, no uses destinos que se encuentran en el bloque CIDR 10.128.0.0/9 porque ese bloque define el espacio de las direcciones actuales y futuras para las rutas de subred. Para obtener más información, consulta Rangos de IP del modo automático.

Las rutas estáticas con destinos dentro de 10.128.0.0/9 pueden inhabilitarse en cualquier momento en una red de VPC de modo automático. Esto puede ocurrir si una región nueva de Google Cloud está disponible y se crea una subred nueva de forma automática (junto con su ruta de subred). Para obtener más información, consulta Consideraciones sobre las redes de VPC de modo automático.

Rutas estáticas

Las rutas estáticas pueden usar cualquiera de los siguientes saltos de las rutas estáticas. Puedes crear rutas estáticas de dos maneras:

Para obtener más información, consulta Parámetros de ruta estática.

Rutas dinámicas

Las rutas dinámicas se administran con un Cloud Router o más. Sus destinos siempre representan rangos de IP fuera de su red de VPC, y sus siguientes saltos siempre son direcciones de par de BGP. Un Cloud Router puede administrar rutas dinámicas para lo siguiente:

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 que genera el sistema se aplican a todas las instancias en una red de VPC. El alcance de las instancias a las que se aplican las rutas de subred no se puede modificar; sin embargo, puedes reemplazar la ruta predeterminada.

  • Las rutas estáticas personalizadas se aplican a todas las instancias o instancias específicas. Las rutas estáticas con un atributo de etiqueta se aplican a instancias que tienen una etiqueta de red correspondiente. Si la ruta no tiene una etiqueta de red, la ruta 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 Google Cloud maneja las rutas de los túneles cuando están inactivos, consulta Cuándo 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 VPCP. Si la red de VPC está en el modo de enrutamiento dinámico regional, todos los Cloud Routers aplican las rutas que aprenden dentro de sus respectivas regiones. Si la red está en modo de enrutamiento dinámico global, todos los Cloud Routers aplican rutas que procesan en toda la red.

    • Cloud Router descarta de forma automática las rutas dinámicas, personalizadas y aprendidas que corresponden a siguientes saltos inaccesibles (los túneles de Cloud VPN que usan enrutamiento dinámico o Cloud Interconnect). Según la red, Cloud Router puede tardar hasta 40 segundos en procesarse para quitar una ruta dinámica con un siguiente salto que está inactivo.
  • 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 se consideran primero porque Google Cloud requiere que las rutas de subred tengan los destinos más específicos que coincidan con los rangos de direcciones IP de sus respectivas subredes. Las rutas de subred son rutas para los rangos de direcciones IP de subred principales y secundarios de cada subred en tu red de VPC y para los rangos de direcciones IP de subred principales y secundarios de subredes en redes de intercambio de tráfico. Si el destino de un paquete cabe dentro del destino de una ruta de subred, se entrega a esa subred de Google Cloud. No puedes anular una ruta de subred con ningún otro tipo de ruta.

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

    • En los casos en los que una ruta estática tiene la misma longitud de prefijo que una ruta dinámica, la ruta estática tiene una prioridad más alta que la ruta dinámica de Cloud Router. Una ruta estática con el mismo prefijo y la misma métrica de ruta que una ruta dinámica siempre tiene una prioridad mayor que la dinámica, de modo que se ignoran las rutas dinámicas en conflicto.

    • Para rutas dinámicas personalizadas, Cloud Router ignora cualquier ruta a otras redes recibidas por un Cloud Router si la ruta recibida tiene un destino igual o más específico que cualquier ruta de subred.

    • Cuando conectas redes de VPC mediante el intercambio de tráfico entre redes de VPC, las redes comparten todas las rutas de subred. Google Cloud prioriza las rutas de subred en redes de intercambio de tráfico similares a las propias rutas de subred de la red local: las rutas de subred en redes de intercambio de tráfico deben tener los destinos más específicos.

  2. Si el paquete no cabe en el destino de una ruta de subred, Google Cloud busca una ruta personalizada con el destino más específico.

    • Supongamos que el destino de un paquete que sale de una VM es 10.240.1.4 y hay dos rutas con destinos diferentes: 10.240.1.0/24 y 10.240.0.0/16. Debido a que el destino más específico para 10.240.1.4 es 10.240.1.0/24, la ruta cuyo destino es 10.240.1.0/24 define el siguiente salto del paquete.
  3. Si más de una ruta personalizada 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 personalizadas (rutas estáticas o dinámicas) que tienen el mismo destino más específico.

    1. Si tu red de VPC está conectada a otras redes a través del intercambio de tráfico entre redes de VPC, Google Cloud primero limita las opciones de una única red de VPC.

      • Si se define al menos una opción de ruta en tu red de VPC local, Google Cloud ignora todas las opciones de rutas de redes de intercambio de tráfico y usa la opción local.

      • Si las opciones de ruta provienen de varias redes de intercambio de tráfico, Google Cloud selecciona una de las redes donde se define al menos una opción de ruta y descarta las opciones de ruta de otras redes. Google Cloud usa un método no determinista para seleccionar esa red de intercambio de tráfico, sin importar la prioridad de cada ruta. Si agregas o quitas redes del grupo de intercambio de tráfico, Google Cloud podría elegir opciones de ruta de una red de intercambio de tráfico diferente.

      Google Cloud busca seleccionar una ruta de las opciones de ruta de una sola red.

    2. Si hay una ruta con la prioridad más alta disponible, Google Cloud envía el paquete al siguiente salto.

    3. Si hay varias rutas con la prioridad más alta, Google Cloud selecciona una ruta según si es una ruta estática o dinámica y el valor de su siguiente salto. Google Cloud usa el siguiente orden (del más al menos preferido):

      1. Google Cloud selecciona una ruta estática personalizada cuyo siguiente salto es la instancia de siguiente salto, la IP de siguiente salto o el túnel VPN de siguiente salto.

      2. Google Cloud selecciona una ruta dinámica personalizada que anuncia un Cloud Router.

      3. Google Cloud selecciona una ruta estática personalizada cuyo siguiente salto es el balanceador de cargas TCP/UDP interno de siguiente salto.

      4. Google Cloud selecciona una ruta estática personalizada mediante la puerta de enlace predeterminada de Internet de siguiente salto.

    4. Si no se puede seleccionar ninguna ruta, Google Cloud distribuye el tráfico entre los siguientes saltos de las opciones de ruta mediante un hash quíntuple para tener afinidad en la implementación de un diseño de enrutamiento ECMP. El hash se calcula a partir del protocolo, las direcciones IP de origen y destino, y los puertos de origen y destino del paquete que se envía. Este cálculo se realiza para cada paquete enviado en función de la cantidad de opciones de ruta disponibles. Si cambia la cantidad de opciones de ruta disponibles, el hash podría dirigir el paquete a un siguiente salto diferente.

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

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

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

Para estos tipos de balanceadores de cargas, los sistemas de frontend de Google (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, 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 las fuentes descritas 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 entrada que permitan el tráfico desde estos sistemas.

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. Google Cloud no admite rangos de destino de IPv6. Los destinos se deben expresar en notación CIDR y 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 Próximos 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.

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 del siguiente salto (next-hop-gateway). Puedes especificar una puerta de enlace de Internet predeterminada para definir una ruta de acceso a las direcciones IP públicas.

  • 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 donde 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 quita la VM pero no se la reemplaza, se sigue aplicando la ruta fija, 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. Para las rutas estáticas personalizadas que usan este siguiente salto, no se puede especificar el alcance a instancias específicas mediante una etiqueta de red.

  • IP de siguiente salto (next-hop-address). Puedes proporcionar una dirección IP como siguiente salto si esa dirección se ajusta al rango de IP principal o secundario de una subred existente en tu red de VPC. No puedes usar una dirección IP pública ni una dirección IP interna en una red local.

    • 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 primario 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 aplica la ruta fija, lo que puede dar como resultado paquetes descartados. A fin de obtener más información, consulta Consideraciones para instancias y siguientes saltos del balanceador de cargas.

  • 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 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 debes al menos 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 Normas 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 primario 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.

Próximos pasos