Interacciones de productos de Cloud NAT

En esta página, se describen las interacciones importantes entre Cloud NAT y otros productos de Google Cloud.

Interacciones de rutas

Una puerta de enlace de NAT pública solo puede usar rutas cuyos próximos saltos sean la puerta de enlace de Internet predeterminada. Cada red de nube privada virtual (VPC) comienza con una ruta predeterminada cuyo destino es 0.0.0.0/0 y cuyo siguiente salto es la puerta de enlace de Internet predeterminada. Para obtener información general importante, consulta la descripción general de las rutas.

En los siguientes ejemplos, se ilustran situaciones que podrían provocar que las puertas de enlace de NAT pública se vuelvan inoperables:

  • Si creas una ruta estática con los siguientes saltos establecidos en cualquier otro tipo de salto siguiente de ruta estática, los paquetes con IP de destino que coincidan con el destino de la ruta se enviarán a ese salto siguiente en lugar de la puerta de enlace de Internet predeterminada. Por ejemplo, si usas instancias de máquina virtual (VM) que ejecutan una puerta de enlace NAT, un firewall o software proxy, creas rutas estáticas para dirigir el tráfico a esas VMs como el siguiente salto. Las VM de siguiente salto requieren direcciones IP externas. Por lo tanto, el tráfico de las VMs que dependen de las VMs del siguiente salto o las VMs del siguiente salto no puede usar las puertas de enlace de NAT pública .

  • Si creas una ruta estática personalizada cuyo siguiente salto es un túnel de Cloud VPN, NAT pública no usa esa ruta. Por ejemplo, una ruta estática con destino 0.0.0.0/0 y un túnel de Cloud VPN de siguiente salto dirigen el tráfico a ese túnel, no a la puerta de enlace de Internet predeterminada. Por lo tanto, las puertas de enlace de NAT pública no pueden usar esa ruta. Del mismo modo, las puertas de enlace de NAT pública no pueden usar rutas estáticas con destinos más específicos, incluidos 0.0.0.0/1 y 128.0.0.0/1.

  • Si un router local anuncia una ruta dinámica a un Cloud Router que administra un túnel de Cloud VPN o un adjunto de VLAN, las puertas de enlace deNAT pública,no pueden usar esa ruta. Por ejemplo, si tu router local anuncia una ruta dinámica con el destino 0.0.0.0/0, 0.0.0.0/0 se direccionará al túnel de Cloud VPN o al adjunto de VLAN. Este comportamiento es válido incluso para destinos más específicos, como 0.0.0.0/1 y 128.0.0.0/1.

La NAT privada usa las siguientes rutas:

  • En el caso de los radios de Network Connectivity Center, la NAT privada usa rutas de subred y rutas dinámicas:
    • En el caso del tráfico entre dos radios de VPC conectados a un concentrador de Network Connectivity Center que solo contiene radios de VPC, la NAT privada usa las rutas de subred que intercambian los radios de VPC conectados. Para obtener información sobre los radios de VPC, consulta Descripción general de los radios de VPC.
    • Si un concentrador de Network Connectivity Center contiene radios de VPC y radios híbridos, como adjuntos de VLAN para Cloud Interconnect, túneles de Cloud VPN o VMs de dispositivos de router, el NAT privado usa las rutas dinámicas que aprenden los radios híbridos a través de BGP y las rutas de subred que intercambian los radios de VPC adjuntos. Para obtener información sobre los radios híbridos, consulta Radios híbridos.
  • En el caso de la NAT híbrida, la NAT privada usa rutas dinámicas que aprende Cloud Router a través de Cloud Interconnect o Cloud VPN.

Interacción con Acceso privado a Google

Una puerta de enlace de NAT pública nunca realiza NAT para el tráfico enviado a las direcciones IP externas seleccionadas de las APIs y los servicios de Google. En cambio, Google Cloud habilita automáticamente el Acceso privado a Google para un rango de direcciones IP de subred cuando configuras una puerta de enlace de NAT pública para aplicarla a ese rango de subred, ya sea primario o secundario. Siempre que la puerta de enlace proporcione NAT para el rango de una subred, el Acceso privado a Google estará activo para ese rango y no se podrá inhabilitar de forma manual.

Una puerta de enlace de NAT pública no cambia la forma en que funciona el Acceso privado a Google. Para obtener más información, consulta Acceso privado a Google.

Las puertas de enlace NAT privadas no se aplican al Acceso privado a Google.

Interacción de VPC compartida

La VPC compartida permite que varios proyectos de servicio de una misma organización usen una red compartida de VPC común en un proyecto host. A fin de proporcionar NAT para las VM en proyectos de servicio que usan una red de VPC compartida, debes crear puertas de enlace de Cloud NAT en el proyecto host.

Interacción de intercambio de tráfico entre redes de VPC

Las puertas de enlace de Cloud NAT están asociadas con rangos de direcciones IP de subred en una sola región y una sola red de VPC. Una puerta de enlace de Cloud NAT creada en una red de VPC no puede proporcionar NAT a máquinas virtuales en otras redes de VPC conectadas mediante Intercambio de tráfico de red de VPC, incluso si las VM en redes de intercambio de tráfico están en la misma región que las puertas de enlace.

Interacción con GKE

Una puerta de enlace de NAT pública puede realizar NAT para nodos y Pods en un clúster privado, que es un tipo de clúster nativo de la VPC. La puerta de enlace de NAT pública debe configurarse para aplicarse al menos a los siguientes rangos de direcciones IP de subred para la subred que usa tu clúster:

  • Rango de direcciones IP principal de la subred (para los nodos)
  • Rango de direcciones IP secundario de la subred utilizado para los Pods del clúster
  • Rango de direcciones IP secundario de la subred utilizado para los servicios del clúster

La forma más sencilla de proporcionar NAT para todo un clúster privado es configurar una puerta de enlace de NAT pública para que se aplique a todos los rangos de direcciones IP de la subred de la subred del clúster.

Si deseas obtener información general sobre cómo los clústeres nativos de la VPC usan rangos de direcciones IP de subred, consulta Rangos de IP para clústeres nativos de la VPC.

Cuando una puerta de enlace de NAT pública está configurada para proporcionar NAT a un clúster privado, esta reserva direcciones IP de origen de NAT y puertos de origen para cada VM de nodo. Los Pods pueden usar esas direcciones IP y puertos de origen porque sus direcciones IP se implementan como rangos de alias de IP que se asignan a cada VM de nodo.

Los clústeres nativos de la VPC de Google Kubernetes Engine (GKE) siempre asignan a cada nodo un rango de IP de alias que contiene más de una dirección IP (máscara de red menor que /32).

  • Si se configura la asignación estática de puertos, el procedimiento de reserva de puertos de NAT pública reserva al menos 1,024 puertos de origen por nodo. Si el valor especificado para la cantidad mínima de puertos por VM es superior a 1,024, se usa ese valor.

  • Si se configura la asignación dinámica de puertos, el valor especificado para los puertos mínimos por VM se asigna inicialmente por nodo. La cantidad de puertos asignados varía de forma posterior entre los valores especificados para la cantidad mínima y máxima de puertos por VM, según la demanda.

Para obtener información sobre los rangos de direcciones IP de Pod y los clústeres nativos de la VPC, consulta Rango de direcciones IP secundario de la subred para Pods.

Independientemente de NAT público , Google Kubernetes Engine realiza la traducción de direcciones de red de origen (NAT de origen o SNAT) con el software que se ejecuta en cada nodo cuando los Pods envían paquetes a Internet, a menos que cambies la configuración de enmascaramiento de IP del clúster. Si necesitas un control detallado sobre el tráfico de salida desde los Pods, puedes usar una política de red.

En determinadas circunstancias, NAT pública también puede ser útil para clústeres nativos de la VPC que no son privados. Como los nodos de un clúster no privado tienen direcciones IP externas, Cloud NAT nunca procesa los paquetes enviados desde la dirección IP interna principal del nodo. Sin embargo, si se cumplen las siguientes condiciones, una puerta de enlace NAT pública puede procesar los paquetes enviados desde los Pods de un clúster no privado:

  • En el caso de los clústeres nativos de VPC, la puerta de enlace de NAT pública está configurada para aplicarse al rango de direcciones IP secundario de los Pods del clúster.

  • La configuración de enmascaramiento de IP del clúster no se puede utilizar a fin de realizar SNAT dentro del clúster para los paquetes enviados desde los Pods a Internet.

En el siguiente ejemplo, se muestra la interacción de NAT pública con GKE:

NAT pública con GKE
NAT pública con GKE (haz clic para ampliar).

En este ejemplo, el objetivo es que tus contenedores se traduzcan con NAT. Para habilitar NAT para todos los contenedores y el nodo de GKE, debes elegir todos los rangos de direcciones IP de Subnet 1 como candidatos de NAT:

  • Rango de direcciones IP principal de la subred: 10.240.0.0/24
  • Rango de direcciones IP secundario de la subred utilizado para los pods: 10.0.0.0/16

No es posible habilitar NAT solo para Pod1 o Pod2.

Una puerta de enlace de NAT privada puede realizar NAT para nodos y Pods en un clúster privado y en uno no privado. La puerta de enlace de NAT privada se aplica automáticamente a todos los rangos de direcciones IP de la subred de la subred privada que usa tu clúster.

Interacciones de salida de VPC directa

NAT pública Cloud NAT pueden realizar NAT para los servicios de Cloud Run o las tareas que se configuran con la salida de VPC directa. Para habilitar Cloud Run para que use una puerta de enlace de NAT pública , configura tu puerta de enlace de NAT pública con la siguiente configuración:

  • Para configurar qué subredes y rangos de direcciones IP de subred asociados con tus instancias de Cloud Run pueden usar la puerta de enlace de NAT pública , especifica la marca --nat-all-subnet-ip-ranges o --nat-custom-subnet-ip-ranges:
    • Para permitir que todos los rangos de direcciones IP de todas las subredes de la región usen la puerta de enlacede NAT pública, especifica la marca --nat-all-subnet-ip-ranges.
    • Para permitir que solo subredes específicas y rangos de direcciones IP de subredes usen la puerta de enlacede NAT pública, especifícalas con la marca --nat-custom-subnet-ip-ranges.
  • Establece el valor de la marca --endpoint-types en ENDPOINT_TYPE_VM. Este valor garantiza que solo las VMs y los extremos de salida de VM de VPC directa puedan usar la puerta de enlace NAT pública .
  • En el caso de la asignación de puertos estáticos, establece el valor de la marca --min-ports-per-vm en cuatro veces la cantidad de puertos que requiere una sola instancia de Cloud Run.
  • En el caso de la asignación manual de direcciones IP de NAT, asigna una cantidad adecuada de direcciones IP a tu puerta de enlace NAT pública para tener en cuenta la suma de la cantidad de instancias de Google Cloud y la cantidad de instancias de Cloud Run que se implementan en tu red de VPC.

Además de la configuración de la puerta de enlace, para enviar tráfico de salida desde un servicio o trabajo de Cloud Run, debes establecer la marca --vpc-egress en all-traffic cuando crees el servicio o trabajo.

Si configuraste un servicio o trabajo de Cloud Run que tiene la marca --vpc-egress establecida en private-ranges-only, el servicio o trabajo envía tráfico solo a direcciones IP internas. No necesitas una puerta de enlace NAT pública para enrutar el tráfico a destinos internos.

Para evitar que los servicios o trabajos de Cloud Run que tengan la marca --vpc-egress establecida en private-ranges-only usen una puerta de enlace NAT pública , haz lo siguiente:

  • Configura la puerta de enlace de NAT pública con la marca --nat-custom-subnet-ip-ranges.
  • Establece el valor de la marca --nat-custom-subnet-ip-ranges en los nombres de las subredes en las que implementaste trabajos o servicios de Cloud Run con la marca --vpc-egress establecida en all-traffic.

Las siguientes limitaciones se aplican a los servicios y trabajos de Cloud Run que usan puertas de enlace de NAT públicas:

  • Las métricas de Cloud NAT para los extremos de salida de VPC directa no se exportan a Cloud Monitoring.
  • Los registros de Cloud NAT para la salida de VPC directa no muestran el nombre de un servicio, una revisión o un trabajo de Cloud Run.

No puedes usar puertas de enlace de NAT privadas con extremos de salida de VPC directa.

Interacciones de las pruebas de conectividad

Puedes usar las pruebas de conectividad para verificar la conectividad entre los extremos de red que usan configuraciones de Cloud NAT. Puedes ejecutar pruebas de conectividad en redes que usan puertas de enlace NAT públicas, puertas de enlace NAT privadas o ambas.

Consulta los detalles de la configuración de NAT en el panel Registro del análisis de configuración de la página Detalles de la prueba de conectividad.

Interacciones con Cloud Load Balancing

Los balanceadores de cargas de aplicaciones internos regionales y los balanceadores de cargas de aplicaciones externos regionales de Google Cloud se comunican con varios backends de grupo de extremos de red de Internet (NEG) regionales. Si configuras puertas de enlace de Cloud NAT para los NEG de Internet regionales, puedes asignar tu propio conjunto de rangos de direcciones IP externas desde los que debe originarse el tráfico de Google Cloud. Las verificaciones de estado y el tráfico del plano de datos provienen de las direcciones IP de NAT que asignas.

Otros balanceadores de cargas externos y sistemas de verificación de estado de Google Cloud se comunican con las VMs mediante rutas de enrutamiento especiales. Las VMs de backend no requieren direcciones IP externas, y las puertas de enlace de Cloud NAT no administran la comunicación de los balanceadores de cargas ni de las verificaciones de estado. Para obtener más información, consulta Descripción general de Cloud Load Balancing y Descripción general de las verificaciones de estado.

¿Qué sigue?