Interacciones del producto 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 siguientes 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 próximo salto es la puerta de enlace de Internet predeterminada. Para obtener más información, 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,de Cloud NAT dejen de funcionar:

  • Si creas una ruta estática con próximos saltos configurados como cualquier otro tipo de próximo salto de ruta estática, los paquetes con direcciones IP de destino que coincidan con el destino de la ruta se enviarán a ese próximo salto en lugar de a la puerta de enlace de Internet predeterminada. Por ejemplo, si usas instancias de máquina virtual (VM) que ejecutan un software de puerta de enlace NAT, firewall o 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 de siguiente salto o de las VMs de siguiente salto en sí no puede usar las puertas de enlace deNAT pública.

  • Si creas una ruta estática personalizada cuyo próximo salto es un túnel de Cloud VPN,NAT públicano usa esa ruta. Por ejemplo, una ruta estática con el destino 0.0.0.0/0 y un túnel de Cloud VPN de salto siguiente dirige 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 dirigiría al túnel de Cloud VPN o al adjunto de VLAN. Este comportamiento se mantiene incluso para destinos más específicos, incluidos 0.0.0.0/1 y 128.0.0.0/1.

La NAT privada usa las siguientes rutas:

  • Rutas de subred de NCC y rutas dinámicas de NCC:
    • Para el tráfico entre radios de VPC, la puerta de enlace NAT usa rutas de subred.
    • En el caso de los concentradores de NCC que tienen radios de VPC y radios híbridos, la puerta de enlace de NAT usa rutas de subred y rutas dinámicas.
  • Rutas dinámicas locales: En el caso de Hybrid NAT, la puerta de enlace de NAT usa rutas dinámicas que Cloud Router aprende a través de Cloud Interconnect o Cloud VPN.
  • Rutas de subred locales y rutas estáticas locales (solo NAT64): La puerta de enlace de NAT usa estas rutas para el tráfico dentro de la misma red de VPC.

Para obtener más información sobre el enrutamiento en la NAT privada, consulta Rutas y reglas de firewall.

Interacciones del Acceso privado a Google

Una puerta de enlace de NAT pública nunca ejecuta NAT para el tráfico que se envía a las direcciones IP externas de los servicios y las APIs 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 aplicar a ese rango de subredes, ya sea principal o secundaria. 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 Cloud NAT o 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 de NAT privadas no se aplican al Acceso privado a Google.

Interacciones de la 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.

Interacciones del intercambio de tráfico entre redes de VPC

Una puerta de enlace de Cloud NAT se configura para los rangos de direcciones IP de subred en una sola región y una sola red de VPC.

Por lo tanto, una puerta de enlace de Cloud NAT creada en una red de VPC no puede proporcionar NAT44 o NAT64 para las VMs en otras redes de VPC, incluso si esas redes están conectadas a través del intercambio de tráfico entre redes de VPC y las VMs se encuentran en la misma región que la puerta de enlace.

Además, para la NAT privada, Cloud NAT no admite destinos en redes de VPC que estén conectadas a través del intercambio de tráfico entre redes de VPC.

Interacciones de GKE

Una puerta de enlace de NAT pública puede realizar la 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 que se aplique 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 un clúster privado completo es configurar una puerta de enlace dePublic NATpara que se aplique a todos los rangos de direcciones IP de 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 se configura para proporcionar NAT a un clúster privado, reserva direcciones IP y puertos de origen de NAT 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ública , 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 servir 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 los siguientes requisitos, una puerta de enlace dePublic NATpuede procesar los paquetes enviados desde los Pods de un clúster no privado:

  • En el caso de los clústeres nativos de la VPC, la puerta de enlace de NAT pública se configura para que se aplique 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 deNAT públicacon GKE:

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

En este ejemplo, deseas que tus contenedores se traduzcan con NAT. Para habilitar la 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 la 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 un clúster no privado. La puerta de enlace de NAT privada se aplica automáticamente a todos los rangos de direcciones IP de subred para la subred privada que usa tu clúster.

Interacciones de salida de VPC directa

Las puertas de enlace de Cloud NAT pueden proporcionar NAT para los recursos de Cloud Run que están configurados con la salida de VPC directa. Para habilitar Cloud Run para que use una puerta de enlace de Cloud NAT para NAT pública o NAT privada, configura lo siguiente:

  • Cuando implementes tus recursos de Cloud Run, establece la marca --vpc-egress. Si quieres usar la NAT pública, el valor debe establecerse en all-traffic.

  • Configura la puerta de enlace de Cloud NAT con los siguientes parámetros:

    • Especifica qué rangos de subred de origen pueden usar la puerta de enlace configurando la marca --nat-custom-subnet-ip-ranges. Establece el valor en los nombres de las subredes en las que implementas tus recursos de Cloud Run.
    • Establece el valor de la marca --endpoint-types en ENDPOINT_TYPE_VM.

    • En el caso de la NAT pública, asegúrate de que el valor de la marca --min-ports-per-vm esté establecido en el doble de la cantidad de puertos que necesita una sola instancia de Cloud Run. En el caso de Private NAT, este parámetro debe establecerse en cuatro veces la cantidad de puertos necesarios por instancia de Cloud Run.

    • Si deseas configurar la asignación manual de direcciones IP de NAT (solo NAT pública), asigna a tu puerta de enlace una cantidad de direcciones IP que sea suficiente para cubrir la suma de las instancias de VM y las instancias de Cloud Run que se publican a través de la puerta de enlace.

Los registros de Cloud NAT para la salida de VPC directa no muestran los nombres de los recursos de Cloud Run.

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 de NAT públicas o puertas de enlace de 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

LosGoogle Cloud balanceadores de cargas de aplicaciones internos regionales y los balanceadores de cargas de aplicaciones externos regionales se comunican con varios backends de grupos de extremos de red (NEG) de Internet 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 donde se debe originar 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 Google Cloud balanceadores de cargas externos y sistemas de verificación de estado se comunican con las VMs a través de rutas de acceso especiales. Las VMs de backend no requieren direcciones IP externas, y una puerta de enlace de Cloud NAT no administra la comunicación para los balanceadores de cargas ni las verificaciones de estado. Para obtener más información, consulta la descripción general de Cloud Load Balancing y la descripción general de las verificaciones de estado.

Interacciones de conexiones propagadas de Private Service Connect

Cuando se usan NAT privada para NCC y conexiones propagadas de Private Service Connect en el mismo radio de VPC, se aplica lo siguiente:

  • Si una subred está configurada con NAT privada, se descarta el tráfico de la subred a las conexiones propagadas de Private Service Connect.

  • Para evitar que se descarte el tráfico de subredes que no se superponen, ten en cuenta lo siguiente cuando configures la NAT privada:

    • Especifica subredes superpuestas con la marca --nat-custom-subnet-ip-ranges.
    • No especifiques subredes que no se superpongan y que necesiten acceder a conexiones propagadas.
    • No uses la marca --nat-all-subnet-ip-ranges.

Interacciones de Hybrid Subnets

Hybrid NAT no es compatible con Hybrid Subnets.

Si el tráfico se origina en una subred en la que se configuró la NAT híbrida y la dirección IP de destino coincide con una ruta de subred híbrida, no se realiza la SNAT. Esta configuración genera un comportamiento de enrutamiento impredecible, ya que el tráfico puede llegar a una red que no es de VPC con la dirección IP de origen original sin traducir.

No uses subredes híbridas en redes en las que se configuró la NAT híbrida.

¿Qué sigue?