Interacciones del producto 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 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 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 hacer que las puertas de enlace de NAT pública dejen de funcionar:

  • Si creas una ruta estática personalizada con los siguientes saltos establecidos en cualquier otro tipo de siguiente salto de ruta estática personalizada, los paquetes con direcciones IP de destino que coinciden con el destino de la ruta se envían a ese salto siguiente en lugar de a la puerta de enlace de Internet predeterminada. Por ejemplo, si usas instancias de VM que ejecutan NAT, firewall o software proxy, necesariamente crearías rutas estáticas personalizadas para dirigir el tráfico a esas VM como el salto siguiente. Las VM de siguiente salto requieren direcciones IP externas. Por lo tanto, el tráfico de las VM que dependen de las VM de siguiente salto o de siguiente salto no pueden usar puertas de enlace NAT públicas.

  • Si creas una ruta estática personalizada cuyo siguiente salto es un túnel de Cloud VPN, Public NAT no usará esa ruta. Por ejemplo, una ruta estática personalizada 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úblicas no pueden usar esa ruta. Del mismo modo, las puertas de enlace de NAT públicas no pueden usar rutas estáticas personalizadas 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 personalizada a un Cloud Router que administra un túnel de Cloud VPN o un adjunto de VLAN, las puertas de enlace de NAT pública no pueden usar esa ruta. Por ejemplo, si tu router local anuncia una ruta dinámica personalizada con destino 0.0.0.0/0, 0.0.0.0/0 se dirigirá al túnel de Cloud VPN o al adjunto 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.

Una puerta de enlace de NAT privada (vista previa) usa solo las rutas que se intercambian por radios de VPC de Network Connectivity Center. Para obtener más información sobre los radios de VPC conectados de Network Connectivity Center, consulta la Descripción general de los radios de VPC (Vista previa).

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 API y los servicios de Google. En cambio, Google Cloud habilita de forma automática el Acceso privado a Google en un rango de direcciones IP de subred cuando configuras una puerta de enlace NAT pública para que se aplique 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 las VM de otras redes de VPC conectadas mediante el intercambio de tráfico entre redes de VPC o radios de VPC de Network Connectivity Center, incluso si las VM de redes de intercambio de tráfico están en la misma región que la puerta de enlace.

Interacción con GKE

Una puerta de enlace 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 NAT pública debe configurarse a fin de aplicar al menos los siguientes rangos de direcciones IP de subred para la subred que usa el 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 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 se configura una puerta de enlace de NAT pública a fin de proporcionar NAT para un clúster privado, se reservan 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 alias de IP que contiene más de una dirección IP (máscara de red menor que /32).

  • Si la asignación de puertos estáticos está configurada, 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 la NAT pública, Google Kubernetes Engine realiza la traducción de direcciones de red de origen (NAT de origen o SNAT) mediante un 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 sobre el tráfico de salida desde los Pods, puedes usar una política de red.

En ciertas circunstancias, la NAT pública también puede ser útil para clústeres no nativos de VPC nativa. Debido a que 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 los clústeres nativos de la VPC, la puerta de enlace de NAT pública se configura 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 la NAT pública con GKE:

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

En este ejemplo, quiere que sus contenedores se traduzcan con NAT. Si quieres habilitar NAT para todos los contenedores y el nodo de GKE, debes elegir todos los rangos de direcciones IP de Subnet 1 como candidato para 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 se puede habilitar NAT solo para Pod1 o Pod2.

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

Interacciones con Cloud Load Balancing

Los balanceadores de cargas externos y los sistemas de verificación de estado de Google Cloud se comunican con las VM mediante rutas especiales. Las VM 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?