Las rutas de Google Cloud definen las rutas de acceso que recorre el tráfico de red desde 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 lo entrega al siguiente salto de la ruta si la dirección de destino del paquete se encuentra dentro del rango de destino de la ruta.
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.
Rutas aplicables
Las rutas aplicables son un subconjunto de todas las rutas de la red de VPC. Cada instancia, túnel de Cloud VPN y adjunto de VLAN de interconnect tiene un conjunto de rutas aplicables, que son rutas que se aplican a ese recurso específico.
Las rutas aplicables va en función de a quien se aplica.
| Tipo de Ruta | ¿A que aplica? |
|---|---|
| 1.- Rutas de acceso de enrutamiento especiales. 2.- Rutas de subred | Estos tipos de rutas siempre se aplican a todas las instancias de VM, los adjuntos de VLAN para interconnect y los túneles de Cloud VPN |
| 1.- Rutas basadas en políticas (Policy-based) 2.- Rutas estáticas. 3.- Rutas dinámicas. | Estos tipos de rutas se pueden configurar para que se apliquen solo a ciertas instancias de VM, adjuntos de VLAN para interconnect o túneles de Cloud VPN (Mas detalle en la nota de la tabla de abajo) |
Tipos de rutas
En las siguientes tablas, se resume la forma en que Google Cloud categoriza las rutas en las redes de VPC.
Rutas basadas en políticas (Policy-based)
Las rutas basadas en políticas se evalúan antes que cualquier otro tipo de ruta.
| Tipo y destino | Siguiente salto | Notas |
|---|---|---|
| Estas rutas se pueden aplicar a paquetes según la dirección IP de origen, la dirección IP de destino, el protocolo o una combinación de estos. | Un balanceador de cargas de red de transferencia interno (Internal passthrough network Load Balancer) desplegado en la misma VPC que la ruta basada en política o en una VPC emparejada (Peering). | Las rutas basadas en políticas se pueden aplicar a todas las VMs de la red, a ciertas VMs seleccionadas por la etiqueta de red o al tráfico que ingresa a la VPC a través de los adjuntos de VLAN para Cloud Interconnect (en una sola región o en todas las regiones). Las rutas basadas en políticas nunca se intercambian a través del intercambio de tráfico entre VPC (Emparejamiento/Peering). |
Rutas de subred (Subnet routes)
Todos las rutas de este tipo se evalúan después de las rutas basadas en políticas, pero antes de las rutas personalizadas.
| Tipo y destino | Siguiente salto | Notas |
|---|---|---|
| Ruta de subred local: Se crea automáticamente para cada rango de direcciones IP de la subred | VPC network | Estas rutas, Google Cloud las crea, actualiza y quita de forma automática durante los eventos del ciclo de vida de la subred. Las rutas de subred locales se aplican a toda la VPC. |
| Ruta de subred de intercambio de tráfico: Representa un rango de direcciones IP de subred en una VPC diferente conectada mediante el intercambio de tráfico entre VPCs (Peering) | Siguiente salto en la red de VPC de intercambio de tráfico | El intercambio de tráfico entre VPC proporciona opciones para intercambiar rutas de subred. Google Cloud las crea, actualiza y quita de forma automática durante los eventos del ciclo de vida de la subred. Las rutas de subred de intercambio de tráfico importadas se aplican a toda la red de VPC. |
| Ruta de subred de Network Connectivity Center: Representa un rango de direcciones IP de subred en un radio de VPC (una VPC diferente conectada al concentrador de Network Connectivity Center) | Hub de Network Connectivity Center | Los administradores de spoke de Network Connectivity Center pueden excluir la exportación de rutas de subred. Google Cloud las crea, actualiza y quita de forma automática durante los eventos del ciclo de vida de la subred. Las rutas de subred importadas de Network Connectivity Center se aplican a toda la red de VPC. |
Rutas personalizadas
Las rutas personalizadas se evalúan después de las rutas basadas en políticas y después de las rutas de subred.
| Tipo y destino | Siguiente salto | Notas |
|---|---|---|
| Ruta estática local: Admite varios destinos | Reenvía paquetes a un siguiente salto de ruta estática. 1.- Puerta de enlace de próximo salto ( next-hop-gateway)Especifica una puerta de enlace de Internet predeterminada para definir una ruta de acceso a direcciones IP externas. 2.- Instancia de próximo salto por nombre y zona ( next-hop-instance)Envía paquetes a una VM de próximo salto que se identifica por nombre y zona y se encuentra en el mismo proyecto como la ruta. 3.- Instancia de próximo salto por dirección ( next-hop-address)Envía paquetes a una VM de próximo salto que identifica la dirección IPv4 interna principal o una dirección IPv6 interna o externa de su interfaz de red. 4.- Balanceador de cargas de red de transferencia interna de próximo salto por nombre ( next-hop-ilb) y región (next-hop-ilb-region) de la regla de reenvíoEnvía paquetes a backends de un balanceador de cargas de red de transferencia interna que se identifica por el nombre, la región y, de manera opcional, el proyecto de la regla de reenvío. 5.- Balanceador de cargas de red de transferencia interna de próximo salto por dirección ( next-hop-ilb).Envía paquetes a backends de un balanceador de cargas de red de paso interno que se identifica mediante la dirección IP de la regla de reenvío del balanceador de cargas. 6.- Túnel de VPN clásica de próximo salto ( next-hop-vpn-tunnel)Envía paquetes a un túnel de VPN clásica de próximo salto mediante el enrutamiento basado en políticas o VPN basadas en rutas. | Las rutas estáticas admiten los siguientes atributos: Nombre y descripción. Estos campos identifican la ruta. El nombre es obligatorio, pero la descripción es opcional. Cada ruta en el proyecto debe tener un nombre único. Red. Cada ruta debe estar asociada con solo una red de VPC. Próximo salto. El próximo salto identifica el recurso de red al que se envían los paquetes. Todos los tipos de próximo salto admiten destinos de IPv4, mientras que algunos tipos de próximo salto admiten destinos de IPv6. Rango de destino. El rango de destino es una sola notación CIDR IPv4 o IPv6. Los destinos de las rutas estáticas deben seguir las reglas descritas en Interacciones con rutas estáticas personalizadas y en Interacciones con rutas estáticas y de subred. El destino más amplio posible para una ruta estática IPv4 es 0.0.0.0/0. El destino más amplio posible para una ruta estática IPv6 es ::/0.Priority. Los números más bajos indican prioridades más altas. La prioridad más alta posible es 0, y la prioridad más baja posible es 65,535.Etiquetas de red. Puedes hacer que una ruta estática se aplique solo a instancias de VM seleccionadas en la red de VPC, identificadas por una etiqueta de red. Si no especificas una etiqueta de red, Google Cloud hace que la ruta estática se aplique a todas las instancias de la red. Las rutas estáticas con etiquetas nunca se intercambian cuando se usa el intercambio de tráfico entre redes de VPC. Las rutas estáticas aplican a todas las instancias de VM, los adjuntos de VLAN para interconnect, los túneles de Cloud VPN y solo instancias de VM identificadas por etiquetas de red. |
| Ruta dinámica local: Destinos que no entran en conflicto con las rutas de las subredes ni las rutas estáticas. Las rutas dinámicas que aprenden los Cloud Routers en la misma red de VPC se denominan rutas dinámicas locales. | Par de una sesión de BGP en un Cloud Router: 1.- Un adjunto de VLAN respaldado por una conexión de interconexión dedicada o una conexión de interconexión de Partner. 2.- Un túnel de Cloud VPN, ya sea un túnel VPN con alta disponibilidad o una VPN clásica configurada para usar enrutamiento dinámico. 3.- Un Router appliance VM instance | Las rutas se agregan y quitan de forma automática en función de las rutas aprendidas de Cloud Routers en tu red de VPC. Las rutas se aplican a las VM según el modo de enrutamiento dinámico de la red de VPC. |
| Ruta estática de intercambio de tráfico, ruta dinámica de intercambio de tráfico: Rutas estáticas o dinámicas en una red de VPC diferente conectada mediante el intercambio de tráfico entre redes de VPC | Siguiente salto en la red de VPC de intercambio de tráfico | El intercambio de tráfico entre redes de VPC proporciona opciones para intercambiar rutas estáticas. Las rutas estáticas de intercambio de tráfico importadas se aplican a toda la red de VPC. El intercambio de tráfico entre VPC proporciona opciones para intercambiar rutas dinámicas. Las rutas dinámicas de intercambio de tráfico se aplican a una región o a todas las regiones de la red de VPC según el modo de enrutamiento dinámico de la red de VPC que exporta las rutas. |
| Ruta dinámica de Network Connectivity Center(NCC): Son rutas dinámicas importadas desde spokes híbridos de Network Connectivity Center ubicados en diferentes redes de VPC. | Concentrador de Network Connectivity Center | Un Hub de Network Connectivity Center puede tener spokes de VPC y spokes híbridos. Las rutas dinámicas de Network Connectivity Center se aplican a una región o a todas las regiones de la VPC según el modo de enrutamiento dinámico de la VPC que contiene el spoke híbrido. |
Rutas predeterminadas generadas por el sistema
Una ruta predeterminada tiene el destino más amplio posible: 0.0.0.0/0 para IPv4 y ::/0 para IPv6. Google Cloud Solo usa una ruta predeterminada para entregar un paquete cuando este no coincide con una ruta más específica en el orden de enrutamiento.
La ausencia de una ruta predeterminada no necesariamente aísla tu red de Internet, ya que las rutas de enrutamiento especiales para balanceadores de cargas de red de transferencia externos y el reenvío de protocolos externos no dependen de una ruta predeterminada.
| Tipo y destino | Siguiente salto | Notas |
|---|---|---|
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. Google Cloud Solo usa una ruta predeterminada para entregar un paquete cuando este no coincide con una ruta más específica en el orden de enrutamiento. La ausencia de una ruta predeterminada no necesariamente aísla tu red de Internet, ya que las rutas de enrutamiento especiales para balanceadores de cargas de red de transferencia externos y el reenvío de protocolos externos no dependen de una ruta predeterminada. |
Rutas de acceso de enrutamiento especiales
Las redes de VPC tienen rutas especiales para ciertos servicios. Estas rutas de enrutamiento especiales no aparecen en la tabla de rutas de tu red de VPC. No puedes quitar ninguna ruta de acceso de enrutamiento especial. Sin embargo, puedes permitir o rechazar paquetes con las reglas de firewall de VPC o las políticas de firewall.
Rutas para balanceadores de cargas de red de transferencia externos y reenvío de protocolos externos
Los balanceadores de cargas de red de transferencia externos (External passthrough Network Load Balancers) y el reenvío de protocolos externos (external protocol forwarding) usan sistemas Maglev para enrutar paquetes de clientes en Internet a VMs de backend y a instancias de destino en tu red de VPC. Estos sistemas Maglev enrutan paquetes que tienen destinos que coinciden con el destino de la regla de reenvío externa.
Cada regla de reenvío para un balanceador de cargas de red de transferencia externo o para el reenvío de protocolos externos también proporciona una ruta de enrutamiento para que sus instancias de VM de backend o de destino envíen paquetes a destinos fuera de la red de VPC:
- Los paquetes que envían las instancias de destino o las VMs de backend pueden ser paquetes de respuesta salientes (que se envían al cliente) o paquetes salientes que inician una conexión nueva.
- Las fuentes de los paquetes deben coincidir con la dirección IP de la regla de reenvío. El protocolo del paquete y el puerto de origen no tienen que coincidir con la especificación del protocolo y el puerto de la regla de reenvío.
- Las rutas de enrutamiento de las reglas de reenvío no dependen de una ruta predeterminada ni del uso del próximo salto de la puerta de enlace de Internet predeterminada.
- Las instancias de VM de backend y de destino no necesitan tener habilitado el reenvío de IP.
Rutas entre Google Front Ends y backends
Los balanceadores de cargas de aplicaciones externos (External Application Load Balancers) y los balanceadores de cargas de red de proxy externos ( external proxy Network Load Balancers) usan Google Front End (GFE). Los GFE de segunda capa abren conexiones TCP a tus VMs de backend y envían paquetes desde las siguientes fuentes:
35.191.0.0/16y130.211.0.0/22para IPv42600:2d00:1:1::/64para IPv6
Google Cloud usa rutas en la red de Google para entregar paquetes de esos rangos de origen a las VMs de backend en tu red de VPC. Cada red de VPC incluye rutas de enrutamiento que permiten que las VMs envíen paquetes de respuesta a los rangos.
Rutas de las verificaciones de estado
Las verificaciones de estado de todos los balanceadores de cargas y de la reparación automática de grupos de instancias administrados envían paquetes a las VMs de backend desde los rangos de direcciones IP del sondeo de verificación de estado.
En la siguiente tabla, se muestran los rangos de IP de origen que se permiten para cada balanceador de cargas:
| Producto | Rangos de IP de origen del sondeo de verificación de estado |
|---|---|
| Balanceador de cargas de aplicaciones externo globalBalanceador de cargas de red del proxy externo global | * 35.191.0.0/16* 130.211.0.0/22Para el tráfico IPv6 a los backends: * 2600:2d00:1:b029::/64* 2600:2d00:1:1::/64 |
| Balanceador de cargas de aplicaciones externo regional 1, 2Balanceador de cargas de aplicaciones interno entre regiones 1Balanceador de cargas de aplicaciones interno regional 1, 2Balanceador de cargas de red del proxy externo regional1, 2Balanceador de cargas de red del proxy interno regional1, 2Balanceador de cargas de red del proxy interno entre regiones 1 | * 35.191.0.0/16* 130.211.0.0/22Para el tráfico IPv6 a los backends: * 2600:2d00:1:b029::/64 |
| Balanceador de cargas de red del proxy clásicoBalanceador de cargas de aplicaciones clásicoCloud Service Mesh, excepto para backends de NEG de Internet y de NEG híbridos | * 35.191.0.0/16* 130.211.0.0/22 |
| Balanceador de cargas de red de transferencia externo 3 | Para el tráfico IPv4 a los backends: * 35.191.0.0/16* 209.85.152.0/22* 209.85.204.0/22Para el tráfico IPv6 a los backends: * 2600:1901:8001::/48 |
| Balanceador de cargas de red de transferencia interno | Para el tráfico IPv4 a los backends: * 35.191.0.0/16* 130.211.0.0/22Para el tráfico IPv6 a los backends: * 2600:2d00:1:b029::/64 |
| Cloud Service Mesh con backends de NEG de Internet y backends de NEG híbridos | Direcciones IP de las VMs que ejecutan el software de Envoy |
Google Cloud usa rutas en la red de Google para entregar paquetes de los sistemas de sondeo de verificación de estado a las VMs de tu red de VPC. Cada red de VPC incluye rutas de enrutamiento que permiten que las VMs envíen paquetes de respuesta a los sistemas de sondeo de verificación de estado.
Rutas de Identity-Aware Proxy (IAP)
El reenvío de TCP con IAP usa 35.235.240.0/20 para IPv4 y 2600:2d00:1:7::/64 para IPv6 como rangos solo internos con próximos saltos que se encuentran completamente dentro de la red de Google. Google no publica rutas a estos rangos en Internet.
Las rutas de la red de Google entregan paquetes de 35.235.240.0/20 o 2600:2d00:1:7::/64 a las VMs de tu red de VPC cuando usas el reenvío de TCP de IAP. Cada red de VPC incluye rutas de enrutamiento que permiten que las VMs envíen paquetes de respuesta a estos rangos.
Rutas de acceso para Cloud DNS y el Directorio de servicios
Las siguientes funciones de Cloud DNS y el Directorio de servicios usan 35.199.192.0/19 como un rango solo interno con próximos saltos que se encuentran completamente dentro de la red de Google. Google no publica rutas a 35.199.192.0/19 en Internet.
- Destinos de reenvío de Cloud DNS que usan enrutamiento privado
- Servidores de nombres alternativos de Cloud DNS que usan enrutamiento privado
- Acceso a redes privadas para el Directorio de servicios
Las rutas de la red de Google entregan paquetes de 35.199.192.0/19 a las VMs de tu red de VPC cuando usas estas funciones de Cloud DNS y el Directorio de servicios. Cada red de VPC incluye rutas de enrutamiento que permiten que las VMs envíen paquetes de respuesta a 35.199.192.0/19.
Rutas para el Acceso a VPC sin servidores
El Acceso a VPC sin servidores usa 35.199.224.0/19 como un rango solo interno con próximos saltos que se encuentran completamente dentro de la red de Google. Google no publica rutas a 35.199.224.0/19 en Internet.
Las rutas de la red de Google entregan paquetes de 35.199.224.0/19 a instancias de conectores de Acceso a VPC sin servidores. Cada red de VPC incluye rutas de enrutamiento que permiten que las instancias de conectores envíen paquetes de respuesta a 35.199.224.0/19.
Rutas para los extremos de Private Service Connect de las APIs de Google globales
Cuando creas un extremo de Private Service Connect para las APIs de Google globales, Google Cloud agrega una ruta para el extremo a tu red de VPC. El destino de la ruta es la dirección IP interna global del extremo.