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 pasarela de NAT pública 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 los siguientes saltos definidos como cualquier otro tipo de siguiente 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 siguiente salto 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, cortafuegos 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 siguientes opciones: 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 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ública no pueden usar esa ruta. Del mismo modo, las pasarelas de NAT pública 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 local 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 NAT pública 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 hub de Network Connectivity Center que solo contenga 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 hub de Network Connectivity Center contiene radios de VPC y radios híbridos, como vinculaciones de VLAN para Cloud Interconnect, túneles de Cloud VPN o VMs de dispositivo de router, Private NAT usa las rutas dinámicas aprendidas por los radios híbridos a través de BGP y las rutas de subred intercambiadas por los radios de VPC conectados. Para obtener información sobre los radios híbridos, consulta Radios híbridos.
  • En el caso de NAT híbrida, NAT privada 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 aplicarla a ese intervalo de subred, ya sea principal o secundario. Mientras la pasarela 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 NAT pública no cambia el funcionamiento del acceso privado de Google. Para obtener más información, consulta Acceso privado a Google.

Las pasarelas NAT privadas 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 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 en un clúster privado, que es un tipo de clúster nativo de VPC. La pasarela NAT pública debe configurarse para que se aplique al menos a los siguientes intervalos de direcciones IP 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 NAT público 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 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úblico reserva al menos 1024 puertos de origen por nodo. Si el valor especificado para minimum ports per 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 los pods.

Independientemente de NAT pública , 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 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, los paquetes enviados desde los pods de un clúster no privado pueden procesarse mediante una pasarela de NAT pública :

  • En los clústeres nativos de VPC, la pasarela NAT pública 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:

Public NAT con GKE.
NAT pública con GKE (haz clic en la imagen para ampliarla).

En este ejemplo, quieres que tus contenedores se traduzcan con 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 de NAT:

  • Intervalo de direcciones IP principales de la subred: 10.240.0.0/24
  • Intervalo de direcciones IP secundarias de la subred que se usa para los pods: 10.0.0.0/16

No es posible habilitar NAT solo para Pod1 o Pod2.

Una pasarela 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 NAT privada 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 NAT pública, 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 NAT público, 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 NAT privada, esta marca debe configurarse con un valor cuatro veces superior al 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 pasarelas NAT públicas o pasarelas 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 endpoints 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 de 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 máquinas virtuales 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 se usan tanto Private NAT para Network Connectivity Center como conexiones propagadas de Private Service Connect en el mismo radio de VPC, se aplican las siguientes condiciones:

  • Si una subred está configurada con NAT privado, 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 NAT privado:

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

Siguientes pasos