Interacciones de Cloud NAT con otros productos

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

Interacciones de rutas

Una pasarela de NAT público solo puede usar rutas cuyo siguiente salto sea la pasarela de Internet predeterminada. Cada red de nube privada virtual (VPC) empieza con una ruta predeterminada cuyo destino es 0.0.0.0/0 y cuyo siguiente salto es la pasarela de Internet predeterminada. Para obtener información general importante, consulta el resumen de rutas.

En los siguientes ejemplos se ilustran situaciones que podrían provocar que las pasarelas NAT pública dejen de funcionar:

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

  • Si creas una ruta estática personalizada cuyo siguiente salto es un túnel de Cloud VPN, Public NAT no 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 siguiente salto dirige el tráfico a ese túnel, no a la pasarela de Internet predeterminada. Por lo tanto, las pasarelas de NAT público no pueden usar esa ruta. Del mismo modo, las pasarelas de NAT público no pueden usar rutas estáticas con destinos más específicos, como 0.0.0.0/1 y 128.0.0.0/1.

  • Si un router on-premise anuncia una ruta dinámica a un Cloud Router que gestiona un túnel de Cloud VPN o una vinculación de VLAN, las pasarelas de Public NAT no pueden usar esa ruta. Por ejemplo, si tu router on-premise 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 a la vinculación de VLAN. Este comportamiento se aplica incluso a destinos más específicos, como 0.0.0.0/1 y 128.0.0.0/1.

Private NAT usa las siguientes rutas:

  • En el caso de los radios de Network Connectivity Center, Private NAT usa rutas de subred y rutas dinámicas:
    • En el caso del tráfico entre dos radios de VPC conectados a un centro de conectividad de red que solo contiene radios de VPC, Private NAT usa las rutas de subred intercambiadas por los radios de VPC conectados. Para obtener información sobre los radios de VPC, consulta la descripción general de los radios de VPC.
    • Si un eje de NCC contiene radios de VPC y radios híbridos, como vinculaciones de VLAN para Cloud Interconnect, túneles de Cloud VPN o VMs de dispositivo router, Private NAT 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 conectados. Para obtener información sobre los radios híbridos, consulta Radios híbridos.
  • En el caso de Hybrid NAT, Private NAT usa rutas dinámicas aprendidas por Cloud Router a través de Cloud Interconnect o Cloud VPN.

Interacciones de Acceso privado de Google

Una pasarela NAT pública nunca realiza NAT para el tráfico enviado a las direcciones IP externas seleccionadas para las APIs y los servicios de Google. En su lugar,Google Cloud habilita automáticamente el acceso privado de GoogleGoogle Cloud para un intervalo de direcciones IP de subred cuando configuras una NAT pública puerta de enlace para aplicar a ese intervalo de subred, ya sea principal o secundario. Mientras la puerta de enlace proporcione NAT para el intervalo de una subred, el Acceso privado de Google estará activo en ese intervalo y no se podrá inhabilitar manualmente.

Una pasarela de Public NAT no cambia el funcionamiento del acceso privado de Google. Para obtener más información, consulta Acceso privado de Google.

Las pasarelas Private NAT no se aplican al Acceso privado de Google.

Interacciones de VPC compartida

La VPC compartida permite que varios proyectos de servicio de una misma organización usen una red de VPC compartida común en un proyecto host. Para proporcionar NAT a las VMs de los proyectos de servicio que usan una red de VPC compartida, debes crear pasarelas de Cloud NAT en el proyecto del host.

Interacciones de emparejamiento entre redes de VPC

Las pasarelas de Cloud NAT están asociadas a intervalos de direcciones IP de subredes de una sola región y una sola red de VPC. Una pasarela de Cloud NAT creada en una red de VPC no puede proporcionar NAT a las máquinas virtuales de otras redes de VPC conectadas mediante el emparejamiento entre redes de VPC, aunque las máquinas virtuales de las redes emparejadas estén en la misma región que la pasarela.

Interacciones de GKE

Una pasarela de NAT pública puede realizar NAT para nodos y pods de un clúster privado, que es un tipo de clúster nativo de VPC. La pasarela de NAT pública debe configurarse para que se aplique al menos a los siguientes intervalos de direcciones IP de subred de la subred que usa tu clúster:

  • Intervalo de direcciones IP principales de la subred (usado por los nodos)
  • Intervalo de direcciones IP secundarias de la subred que se usa para los pods del clúster.
  • Intervalo de direcciones IP secundarias de la subred que se usa para los servicios del clúster.

La forma más sencilla de proporcionar NAT a un clúster privado completo es configurar una pasarela de Public NAT para que se aplique a todos los intervalos de direcciones IP de la subred del clúster.

Para obtener información general sobre cómo utilizan los clústeres nativos de VPC los intervalos de direcciones IP de subredes, consulta Intervalos de direcciones IP de clústeres nativos de VPC.

Cuando se configura una pasarela de NAT pública para proporcionar NAT a un clúster privado, reserva direcciones IP de origen y puertos de origen de NAT para cada VM de nodo. Los pods pueden usar esas direcciones IP y puertos de origen de NAT porque las direcciones IP de los pods se implementan como intervalos de IP de alias asignados a cada VM de nodo.

Los clústeres nativos de VPC de Google Kubernetes Engine (GKE) siempre asignan a cada nodo un intervalo de IPs 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 Public NAT reserva al menos 1024 puertos de origen por nodo. Si el valor especificado para el número mínimo de puertos por VM es superior a 1024, se usará ese valor.

  • Si se configura la asignación dinámica de puertos, el valor especificado para el número mínimo de puertos por VM se asigna inicialmente por nodo. El número de puertos asignados varía posteriormente entre los valores especificados para el número mínimo y máximo de puertos por VM, en función de la demanda.

Para obtener información sobre los intervalos de direcciones IP de los pods y los clústeres nativos de VPC, consulta Intervalo de direcciones IP secundario de la subred para pods.

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

En determinadas circunstancias, NAT pública también puede ser útil para los clústeres nativos de VPC no 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 dos condiciones siguientes, una pasarela de NAT público puede procesar los paquetes enviados desde los pods de un clúster no privado:

  • En los clústeres nativos de VPC, la pasarela Public NAT se configura para que se aplique al intervalo de direcciones IP secundario de los pods del clúster.

  • La configuración de enmascaramiento de IP del clúster no está configurada para realizar SNAT en el clúster para los paquetes enviados desde los pods a Internet.

En el siguiente ejemplo se muestra la interacción de Public NAT con GKE:

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

En este ejemplo, quieres que tus contenedores se traduzcan mediante NAT. Para habilitar NAT en todos los contenedores y el nodo de GKE, debes elegir todos los intervalos de direcciones IP de Subnet 1 como candidatos a NAT:

  • Intervalo de direcciones IP principales de la subred: 10.240.0.0/24
  • Intervalo de direcciones IP secundarias de subred usado para pods: 10.0.0.0/16

No es posible habilitar NAT solo para Pod1 o Pod2.

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

Interacciones de salida de VPC directa

Las pasarelas de Cloud NAT pueden proporcionar NAT a los recursos de Cloud Run que estén configurados con salida directa de VPC. Para habilitar Cloud Run para que use una pasarela de Cloud NAT para NAT pública o NAT privada, configura lo siguiente:

  • Cuando despliegues tus recursos de Cloud Run, define la marca --vpc-egress. Si quieres usar Public NAT, el valor debe ser all-traffic.

  • Configura la pasarela Cloud NAT con los siguientes ajustes:

    • Especifica qué intervalos de subredes de origen pueden usar la pasarela configurando la marca --nat-custom-subnet-ip-ranges. Asigna el valor a los nombres de las subredes en las que implementes tus recursos de Cloud Run.
    • Asigna el valor ENDPOINT_TYPE_VM a la marca --endpoint-types.

    • En el caso de Public NAT, asegúrate de que el valor de la marca --min-ports-per-vm sea el doble del número de puertos que necesita una sola instancia de Cloud Run. En el caso de Private NAT, esta marca debe configurarse como cuatro veces el número de puertos necesarios por instancia de Cloud Run.

    • Si quieres configurar la asignación manual de direcciones IP de NAT (solo NAT público), asigna a tu pasarela un número de direcciones IP suficiente para cubrir la suma de las instancias de VM y las instancias de Cloud Run a las que sirve la pasarela.

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

Interacciones de pruebas de conectividad

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

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

Interacciones de Cloud Load Balancing

LosGoogle Cloud balanceadores de carga de aplicaciones internos regionales y los balanceadores de carga de aplicaciones externos regionales se comunican con varios backends de grupos de extremos de red (NEG) de Internet regionales. Si configura pasarelas de Cloud NAT para los NEGs de Internet regionales, puede asignar su propio conjunto de intervalos de direcciones IP externas desde donde debe originarse el tráfico de Google Cloud . Las comprobaciones del estado y el tráfico del plano de datos proceden de las direcciones IP de NAT que asignes.

Otros balanceadores de carga externos y sistemas de comprobación del estado se comunican con las VMs mediante rutas especiales. Google Cloud Las VMs de backend no necesitan direcciones IP externas, y una pasarela Cloud NAT no gestiona la comunicación de los balanceadores de carga ni las comprobaciones de estado. Para obtener más información, consulta la descripción general de Cloud Load Balancing y la descripción general de las comprobaciones del estado.

Interacciones de conexiones propagadas de Private Service Connect

Si usas tanto Private NAT para NCC como conexiones propagadas de Private Service Connect en el mismo radio de VPC, se aplican las siguientes condiciones:

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

  • Para evitar que se pierda tráfico de subredes que no se solapan, ten en cuenta lo siguiente al configurar Private NAT:

    • Especifica subredes superpuestas con la marca --nat-custom-subnet-ip-ranges.
    • No especifiques subredes que no se solapen 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 subredes híbridas.

Si el tráfico procede de una subred en la que se ha configurado 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 provoca un comportamiento de enrutamiento impredecible, ya que el tráfico puede llegar a una red que no sea de VPC mediante la dirección IP de origen original sin traducir.

No uses subredes híbridas en redes en las que se haya configurado Hybrid NAT.

Siguientes pasos