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
Rutas predeterminadas que genera el sistema
0.0.0.0/0 para IPv4
::/0 para IPv6
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
Reenvía paquetes a un siguiente salto de ruta estática. Para obtener detalles sobre cada siguiente salto de ruta estática, consulta las consideraciones para lo siguiente:
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:
  • Las rutas estáticas en una red de intercambio de tráfico que usan etiquetas de red nunca se importan como rutas personalizadas de intercambio de tráfico.
  • Las rutas estáticas en una red de intercambio de tráfico que usan el siguiente salto de la puerta de enlace de Internet predeterminada nunca se importan como rutas personalizadas de intercambio de tráfico.
  • Las rutas estáticas en una red de intercambio de tráfico que usan los siguientes saltos del balanceador de cargas TCP/UDP interno se pueden aplicar a una sola región o a todas las regiones, según si el acceso global está habilitado. Para obtener más detalles, consulta Consideraciones para siguientes saltos de balanceadores de cargas TCP/UDP internos.
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.

Rutas predeterminadas generadas por el sistema

Cuando creas una red de VPC, se incluye una ruta predeterminada IPv4 generada por el sistema (0.0.0.0/0). Cuando creas una subred de pila doble con un rango de direcciones IPv6 externo en una red de VPC, se agrega una ruta predeterminada IPv6 generada por el sistema (::/0) a esa red si la ruta aún no existe. Las rutas predeterminadas tienen los siguientes fines:

Google Cloud solo usa una ruta predeterminada si una ruta con un destino más específico no se aplica a un paquete. A fin de obtener información para usar 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:

  • Solo para IPv4: 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.

  • IPv4 e IPv6: si borras 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.

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.

Interacciones con rutas estáticas personalizadas

Las rutas de subred locales y las rutas de subred de intercambio de tráfico importadas interactúan con rutas estáticas personalizadas de las siguientes maneras:

  • Google Cloud no te permite crear una ruta estática personalizada que tenga un destino igual o más estrecho que cualquier ruta de subred o ruta de subred de intercambio de tráfico. Por ejemplo, si existe una ruta de subred local o una ruta de subred de intercambio de tráfico para el destino 10.70.1.0/24, no puedes crear una nueva ruta estática personalizada para 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ni ningún otro destino que se ajuste a 10.70.1.0/24.

  • Por el contrario, Google Cloud no te permite crear una subred o ruta de subred de intercambio de tráfico nueva cuyo destino coincida de manera exacta con una ruta estática personalizada existente o sea más amplia que esta (la contendría). Por ejemplo, si tu red de VPC tiene una ruta estática personalizada para el destino 10.70.1.128/25, Google Cloud prohíbe la creación de cualquier subred o ruta de subred de intercambio de tráfico con un rango de direcciones IP de subred principal o secundario de 10.70.1.128/25, 10.70.1.0/24 o cualquier otro rango que contenga todas las direcciones IP en 10.70.1.128/25.

Interacciones con rutas dinámicas personalizadas

Las rutas de subred locales y las rutas de subred de intercambio de tráfico importadas interactúan con Cloud Routers de las siguientes maneras:

  • Cuando los Cloud Routers aprenden prefijos que coinciden de forma exacta con el destino de una subred o una ruta de subred de intercambio de tráfico, Google Cloud ignora estas rutas dinámicas personalizadas. Por ejemplo, si existe una subred o una ruta de subred de intercambio de tráfico para el destino 10.70.1.0/24 y uno o más Cloud Routers en la red de VPC reciben el prefijo 10.70.1.0/24 a través de BGP, Google Cloud usa la subred o la ruta de subred de intercambio de tráfico e ignora la ruta dinámica personalizada en conflicto.

  • Cuando los Cloud Routers aprenden prefijos que se ajustan al destino de una subred o una ruta de subred de intercambio de tráfico, Google Cloud ignora estas rutas dinámicas personalizadas. Por ejemplo, si existe una subred o una ruta de subred de intercambio de tráfico para el destino 10.70.1.0/24 y uno o más Cloud Routers en la red de VPC reciben el prefijo 10.70.1.0/25 a través de BGP, Google Cloud usa la subred o la ruta de subred de intercambio de tráfico e ignora la ruta dinámica personalizada en conflicto.

Ciclo de vida de las rutas de subred

Las rutas de subred se crean, actualizan y borran cuando creas, modificas o borras subredes o sus rangos de direcciones IP 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 siguientes interconexiones y túneles usan las rutas dinámicas:

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

Sin embargo, el destino de una ruta dinámica puede contener una máscara de subred más pequeña que el rango de IP de una subred. Por ejemplo, si tienes un rango de IP de subred de 10.10.10.0/24, puedes tener una ruta dinámica con un destino de 10.10.10.0/23. Si la dirección IP de destino de un paquete no se ajusta al destino de la ruta de la subred, el paquete se envía al siguiente salto de la ruta dinámica. 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 utilizada de forma privada. Puedes configurar un par para importar las rutas de subred que usan direcciones IP públicas utilizadas 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.

  • Se aplican rutas de acceso de retorno especiales cuando se enrutan a balanceadores de cargas de proxy, sistemas de verificación de estado y otros servicios de Google. Para obtener más información, consulta Rutas de acceso de retorno del balanceador de cargas. Estas rutas no se muestran en ninguna tabla de rutas.

  • 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 por 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 Google Cloud controla 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.

Orden de enrutamiento

En el siguiente proceso, se modela el comportamiento de selección de ruta de la red de VPC. Puedes seguir este proceso y comenzar con el conjunto de rutas aplicables (como se describe en la sección anterior) a fin de modelar las decisiones de selección de ruta que toma Google Cloud para un paquete.

  1. Destino más específico: Google Cloud primero determina cuál de las rutas aplicables tiene el destino más específico que contiene la dirección IP de destino del paquete. Google Cloud ignora todas las demás rutas con destinos menos específicos. Por ejemplo, 10.240.1.0/24 es un destino más específico que 10.240.0.0/16. El destino más específico podría ser cualquier tipo de ruta. Sin embargo, las rutas de subred, las rutas de subred de intercambio de tráfico y las rutas de retorno especiales son las más específicas por definición.

  2. Después de este paso, tu modelo de selección de ruta solo contiene las rutas con los destinos más específicos.

  3. Siguientes saltos en una sola red de VPC: Este paso solo es aplicable si la red de VPC cuyo comportamiento de ruta estás modelando está conectada a una o más redes de VPC mediante el intercambio de tráfico entre redes de VPC. Con el intercambio de tráfico entre redes de VPC, las rutas personalizadas con destinos idénticos pueden existir en más de una de las redes del grupo de intercambio de tráfico. El requisito modelado en este paso es que Google Cloud seleccione los siguientes saltos que se encuentran en una sola red de VPC.

    • Si una o más de las rutas en tu modelo de ruta tienen siguientes saltos dentro de la red de VPC que estás modelando, ignora todas las rutas que tienen siguientes saltos en redes de intercambio de tráfico. En esta situación, Google Cloud solo usa los siguientes saltos en la red de VPC local, incluso si los siguientes saltos para el mismo destino existen en una o más redes de VPC de intercambio de tráfico.

    • Si ninguna de las rutas en tu modelo de ruta tiene siguientes saltos dentro de la red de VPC que estás modelando, y todos los siguientes saltos existen en varias redes de intercambio de tráfico, Google Cloud usa un algoritmo interno a fin de seleccionar una sola red de intercambio de tráfico con los siguientes saltos para los destinos más específicos. En este punto, no se tiene en cuenta la prioridad de ruta. Además, si tu red de VPC intercambia tráfico con una red de VPC nueva o si se desconecta de una red de VPC con intercambio de tráfico existente, la red de VPC seleccionada para los siguientes saltos puede cambiar.

    Después de este paso, tu modelo de selección de ruta solo contiene las rutas con los destinos más específicos, y los siguientes saltos de estas rutas se encuentran en una sola red de VPC.

  4. Ignora las rutas estáticas personalizadas cuyos siguientes saltos están inactivos: En este paso, se modelan dos situaciones en las que Google Cloud ignora los siguientes saltos que considera inactivos. Este paso solo se aplica a las rutas estáticas personalizadas. En su lugar, las rutas dinámicas personalizadas se agregan y quitan de forma automática mediante anuncios de BGP.

    • Google Cloud ignora cada instancia de VM de siguiente salto (next-hop-instance o next-hop-address) si se detiene o se borra la VM de siguiente salto. Para obtener más detalles, consulta Comportamiento cuando las instancias se detienen o se borran en la sección Consideraciones para instancias de siguiente salto. Si tu modelo de ruta contiene rutas estáticas cuyas VM de siguiente salto se detienen o borran, quita esas rutas de tu modelo.

    • Google Cloud ignora todas las rutas estáticas personalizadas que usan un túnel de VPN clásica de siguiente salto si el túnel no tiene una asociación de seguridad (SA) de fase 1 (IKE). Para obtener más detalles, consulta Orden de las rutas en la documentación de VPN clásica. Si tu modelo de ruta contiene rutas estáticas cuyos siguientes saltos son túneles de VPN clásica sin SA de IKE establecidas, quita esas rutas de tu modelo.

  5. Ignora las rutas de prioridad baja: En este paso, se modela cómo Google Cloud ignora todas las rutas, excepto las que tienen la prioridad más alta.

    Después de este paso, tu modelo de selección de ruta puede estar vacío o puede contener una o más rutas. Si tu modelo contiene rutas, todas estas tienen todas estas características:

    • Destinos idénticos y más específicos
    • Todos los siguientes saltos en la misma red de VPC: la red de VPC local o una sola red de VPC con intercambio de tráfico.
    • Siguientes saltos que no se sabe que estén inactivos
    • Prioridades idénticas y más altas
  6. Selecciona solo la categoría de preferencia más favorable: Google Cloud evita el enrutamiento ECMP entre los diferentes tipos de siguientes saltos. Para modelar este comportamiento, considera el sistema de categoría de preferencia descrito en la siguiente tabla. En este paso, se define mejor el modelo de ruta para que solo contenga rutas que son del mismo tipo de ruta o una combinación del tipo de ruta y el tipo de siguiente salto.

    Categoría de preferencia Combinación de categoría y siguiente salto
    Primera opción (preferencia más alta) Rutas estáticas personalizadas con una instancia de siguiente salto en ejecución (next-hop-instance o next-hop-address) o un túnel de VPN clásica de siguiente salto establecido con SA de IKE
    Segunda opción Rutas dinámicas personalizadas aprendidas de cualquier sesión de BGP de cualquier Cloud Router
    Tercera opción Una sola ruta estática personalizada con un siguiente salto de balanceador de cargas TCP/UDP interno
    Google Cloud usa un algoritmo interno para seleccionar un único balanceador de cargas TCP/UDP interno de siguiente salto, ignorando los siguientes saltos del otro balanceador de cargas TCP/UDP interno con la misma prioridad. Para obtener más detalles, consulta “El mismo destino y varios balanceadores de cargas TCP/UDP internos de siguiente salto” en la sección Consideraciones para siguientes saltos de balanceadores de cargas TCP/UDP internos.
    Cuarta opción Una ruta estática personalizada con el siguiente salto default-internet-gateway

    Al final de este paso, puede haber cero, una, dos o más rutas en el modelo de ruta.

  7. Enviar o descartar paquete: Lo que sucede depende de la cantidad de rutas restantes en el modelo de ruta:

    • Si el modelo de ruta está vacío, el paquete se descarta con un error de destino de ICMP o red inaccesible. Google Cloud nunca recurre a una ruta menos específica que pueda tener un siguiente salto en funcionamiento.

    • Si el modelo de ruta contiene una sola ruta, Google Cloud envía el paquete al siguiente salto. Para los siguientes saltos de VM, Google Cloud no valida que el siguiente salto de VM pueda procesar paquetes. Para obtener más información, consulta Consideraciones comunes de siguientes saltos de balanceadores de cargas TCP/UDP internos e instancias. Si la ruta única es una ruta de subred o una ruta de subred de intercambio de tráfico y no hay un recurso de Google Cloud en la dirección IP de destino del paquete, el paquete se descarta.

    • Si el modelo de ruta contiene dos o más rutas, las rutas comparten el mismo destino más específico, se ubican en una sola red de VPC, tienen siguientes saltos que no se sabe que estén inactivos, tienen la misma prioridad más alta y pertenecen a una combinación de tipo de ruta y siguiente salto (categoría de preferencia). Google Cloud distribuye paquetes entre los siguientes saltos que implementan rutas múltiples de igual costo (ECMP) mediante un algoritmo de hash. Los cálculos de hash se realizan para cada paquete en el momento en que se envía, en función de la cantidad actual de siguientes saltos. Google Cloud usa un hash de cinco tuplas si el paquete contiene información de puertos. De lo contrario, usa un hash de tres tuplas. Si el modelo de ruta cambia a medida que se envían paquetes posteriores, Google Cloud podría dirigir esos paquetes a un siguiente salto diferente, incluso si el hash es el mismo.

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 siguientes páginas:

Rutas de acceso de retorno para el balanceador 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 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 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). Sin embargo, el destino de una ruta estática puede contener una máscara de subred más pequeña que el rango de IP de una subred. Por ejemplo, si tienes un rango de IP de subred de 10.10.10.0/24, puedes tener una ruta estática con un destino de 10.10.10.0/23. Si la dirección IP de destino de un paquete no se ajusta al destino de la ruta de la subred, el paquete se envía al siguiente salto de la ruta estática. 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.

Consideraciones comunes de siguientes saltos de balanceadores de cargas TCP/UDP internos e 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 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 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 VM 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 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 para instancias de siguiente salto

  • Siguiente salto por nombre de instancia (next-hop-instance): Si la ruta y la instancia de siguiente salto están en el mismo proyecto, puedes especificar una instancia de siguiente salto con su nombre y su zona. Antes de crear la ruta, Google Cloud requiere que exista una instancia de siguiente salto que cumpla con todos estos criterios:

    • El nombre de la instancia debe coincidir con el nombre de la VM del siguiente salto de la ruta.
    • La zona de la instancia debe coincidir con la zona del siguiente salto de la ruta.
    • La instancia debe tener una interfaz de red en la red de VPC de la ruta.

    Google Cloud actualiza de forma automática una ruta cuyo siguiente salto se especifica mediante next-hop-instance en estas situaciones:

    • Cuando cambia la dirección IPv4 de la instancia de siguiente salto
    • Cuando reemplazas la instancia de siguiente salto, siempre que la instancia de reemplazo cumpla con los mismos criterios que la instancia que se reemplazó.
  • Dirección IP interna de la instancia de siguiente salto (next-hop-address): Puedes especificar una instancia de siguiente salto mediante una dirección IPv4 interna asociada con una interfaz de red en la red de VPC de la ruta. Antes de crear la ruta, Google Cloud requiere que exista una instancia de siguiente salto que cumpla con todos estos criterios:

    • La instancia debe tener, al menos, una interfaz de red en la red de VPC de la ruta.
    • La interfaz de red de la instancia debe tener una dirección IPv4 interna que coincida con la dirección del siguiente salto de la ruta. La dirección IPv4 interna puede ser la dirección IPv4 principal de la interfaz de red o una dirección IPv4 de un rango de alias de IP en la interfaz de red.

    Google Cloud actualiza de forma automática una ruta cuyo siguiente salto se especifica mediante next-hop-address cuando la dirección IPv4 se mueve a una VM diferente, siempre que la VM de reemplazo cumpla con los criterios anteriores.

  • Siguientes saltos en un proyecto de servicio de VPC compartida: Si necesitas crear una ruta en una red de VPC compartida cuya instancia de siguiente salto se encuentra en un proyecto de servicio, debes especificar el siguiente salto mediante next-hop-address. No puedes especificar el siguiente salto mediante next-hop-instance.

  • 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 salida 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 siguiente salto cumple con todos los requisitos descritos en las Consideraciones comunes de siguientes saltos de balanceadores de cargas TCP/UDP internos e 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. Para mejorar la confiabilidad, usa un balanceador de cargas TCP/UDP interno como un siguiente salto en su lugar.

  • 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 VM 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 VM con varias interfaces para conectar redes de VPC y necesitas que la misma VM procese paquetes para una conexión determinada en ambas direcciones, debes usar un balanceador de cargas TCP/UDP interno de siguiente salto. El balanceador de cargas TCP/UDP interno de siguiente salto es necesario porque ofrece hash simétrico. Para obtener detalles sobre el hash simétrico, consulta Hash simétrico en la documentación de los balanceadores de cargas TCP/UDP internos como siguientes saltos.

  • Comportamiento cuando se detienen o borran instancias: Google Cloud no te impide detener o borrar una instancia de siguiente salto, sin importar la forma en que la especificaste (mediante next-hop-instance o next-hop-address). Google Cloud descarta todas las instancias detenidas o borradas en el paso de categorización de preferencias del orden de enrutamiento. En los siguientes ejemplos, se aclara este comportamiento:

    • Supongamos que tienes tres rutas estáticas personalizadas para el destino 192.168.168.0/24: una con prioridad 10 cuya VM de siguiente salto está detenida, una segunda con prioridad 20 cuya VM de siguiente salto está en ejecución y una tercera con prioridad 30 cuya VM de siguiente salto está en ejecución. Google Cloud envía paquetes a la segunda VM, aunque su ruta tenga una prioridad menor que la ruta cuya VM de siguiente salto está detenida. Si inicias la VM del primer salto, Google Cloud usa la primera ruta en su lugar.

    • Supongamos que tienes tres rutas estáticas personalizadas como se describió antes, pero todas las VM de siguiente salto se detienen o se borran. Los paquetes se descartan incluso si hay rutas menos específicas con siguientes saltos en funcionamiento porque Google Cloud considera la especificidad del destino antes de determinar si se está ejecutando una VM de siguiente salto.

Consideraciones para siguientes saltos de balanceadores de cargas TCP/UDP internos

  • Efecto del acceso global. Las rutas estáticas personalizadas que usan los siguientes saltos del balanceador de cargas de TCP/UDP 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 siguiente salto de balanceador de cargas TCP/UDP interno se descartan.
  • Cuando todos los backends están en mal estado. Cuando todos los backends de un balanceador de cargas de TCP/UDP interno fallan las verificaciones de estado, las rutas que usan ese siguiente 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). El balanceador de cargas de TCP/UDP interno de siguiente salto y las reglas de reenvío del balanceador de cargas de TCP/UDP interno con una dirección IP común son funciones excluyentes entre sí. Un balanceador de cargas de TCP/UDP interno de siguiente salto debe usar una dirección IP que sea única para la regla de reenvío del balanceador de cargas a fin de 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 TCP/UDP internos).

  • El mismo destino y varios balanceadores de cargas de TCP/UDP internos de siguiente salto. Si creas dos o más rutas estáticas personalizadas con el mismo destino mediante diferentes siguientes saltos del balanceador de cargas de TCP/UDP interno, Google Cloud nunca distribuye el tráfico entre los siguientes saltos del balanceador de cargas mediante ECMP. Si las rutas tienen prioridades únicas, Google Cloud usa el balanceador de cargas de TCP/UDP interno de siguiente salto de la ruta con la prioridad más alta. Si las rutas tienen las mismas prioridades, Google Cloud selecciona solo un balanceador de cargas de TCP/UDP interno de siguiente salto. En esta última situación, como se ilustra en el siguiente diagrama, Google Cloud usa un algoritmo determinista interno para seleccionar una sola regla de reenvío de siguiente salto (forwarding-rule-a), sin importar otras rutas con la misma prioridad.

    El mismo destino, diferentes siguientes saltos de balanceador de cargas de TCP/UDP interno
    El mismo destino, diferentes siguientes saltos de balanceador de cargas de TCP/UDP interno
  • Varios destinos y el mismo balanceador de cargas de TCP/UDP interno de siguiente salto.

    Con etiquetas de instancia:

    Si usas etiquetas de instancia (también llamadas etiquetas de red), puedes usar el mismo balanceador de cargas TCP/UDP interno de siguiente salto para varias rutas estáticas personalizadas con el mismo destino y la misma prioridad.

    Sin etiquetas de instancia: Si no usas etiquetas de instancia, no puedes crear múltiples rutas estáticas personalizadas que tengan la misma combinación de destino, prioridad y balanceador de cargas de TCP/UDP interno de siguiente salto. Por ejemplo, se pueden crear route-x, route-y y route-z, pero no se puede crear route-x-copy.

    Rutas sin etiquetar de ejemplo con un balanceador de cargas de TCP/UDP interno de siguiente salto común
    Rutas sin etiquetar de ejemplo con un balanceador de cargas de TCP/UDP interno de siguiente salto común
  • Etiquetas de instancia.

    Puedes especificar etiquetas de instancia (también llamadas etiquetas de red) para que la ruta del siguiente salto solo se aplique a las instancias de cliente que se configuraron con la etiqueta. Esto te permite seleccionar qué instancias de cliente se propagan con qué ruta etiquetada de siguiente salto y a qué conjunto de dispositivos enrutar el tráfico.

    No es necesario segregar las diferentes instancias de cliente a redes de VPC independientes, ya que cada una apunta a su balanceador de cargas de TCP/UDP interno preferido, que realiza un frontend de un conjunto de dispositivos.

  • Varias rutas al mismo prefijo de destino. Con las etiquetas de instancia, puedes especificar varias rutas al mismo destino con diferentes balanceadores de cargas internos como siguientes saltos. Puedes usar diferentes etiquetas de instancia o prioridades diferentes para estas mismas rutas de destino.

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 salida y agrega latencia a 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.

  • Comportamiento cuando los túneles de VPN clásica están inactivos: Las rutas estáticas personalizadas cuyos siguientes saltos son túneles de VPN clásica no se quitan de forma automática cuando los túneles de VPN clásica están inactivos. Para obtener más información sobre lo que ocurre cuando los túneles están inactivos, consulta Cuando los túneles están inactivos en la documentación de la VPN clásica.

¿Qué sigue?