Interacciones con productos de Cloud NAT

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

Interacciones de rutas

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

Los siguientes ejemplos ilustran situaciones que pueden causar NAT pública que las puertas de enlace dejen de ser operativas:

  • Si creas una ruta estática personalizada con los próximos saltos establecidos en cualquier otro tipo de próximo salto de ruta estática personalizada, luego los paquetes con direcciones IP de destino que coincidan con el destino de la ruta se envían al próximo salto, en lugar de a la puerta de enlace de Internet predeterminada. Por ejemplo, usa instancias de máquina virtual (VM) que ejecutan una puerta de enlace NAT, un firewall crea rutas estáticas personalizadas para dirigir el tráfico a esas VMs como en el próximo salto que indiques. Las VM de siguiente salto requieren direcciones IP externas. Por lo tanto, tráfico de las VMs que dependen de las VMs del próximo salto o del siguiente salto no pueden usar NAT pública de enlace de enlace virtual de enlace de puerta de enlace.

  • Si creas una ruta estática personalizada cuyo próximo salto es una Cloud VPN túnel, NAT pública no usa esa ruta. Por ejemplo, una entrada Ruta estática con destino 0.0.0.0/0 y un Cloud VPN de próximo salto redirige el tráfico a ese túnel, no a la puerta de enlace de Internet predeterminada. Por lo tanto, NAT pública puertas de enlace no pueden ruta. De forma similar, NAT pública no pueden usar una puerta de enlace estática rutas 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 personalizada a un Cloud Router que administra un túnel de Cloud VPN un adjunto de VLAN, NAT pública no pueden usar esa ruta. Por ejemplo, si tu router local anuncia una ruta dinámica personalizada con el destino 0.0.0.0/0, 0.0.0.0/0 se dirigirá al túnel de Cloud VPN o un adjunto de VLAN. Este comportamiento se aplica incluso destinos más específicos, como 0.0.0.0/1 y 128.0.0.0/1.

La NAT privada usa las siguientes rutas:

  • Para los radios de Network Connectivity Center, la NAT privada usa subredes rutas y rutas dinámicas:
    • Para el 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 rutas de subred intercambiados por los radios de VPC adjuntos. Información sobre radios de VPC, consulta Descripción general de los radios de VPC.
    • Si un concentrador de Network Connectivity Center contiene ambos radios de VPC y radios híbridos, como adjuntos de VLAN para Cloud Interconnect, Los túneles de Cloud VPN o las VMs del dispositivo de router La NAT privada usa rutas dinámicas aprendidos por los radios híbridos a través de BGP (vista previa) y las rutas de subred intercambiadas por los radios de VPC adjuntos. Para obtener información sobre la nube híbrida consulta Radios híbridas.
  • Para la NAT híbrida (vista previa), La NAT privada usa rutas dinámicas aprendidas por Cloud Router a través de Cloud Interconnect o Cloud VPN.

Interacción con Acceso privado a Google

R NAT pública puerta de enlace nunca ejecuta NAT para el tráfico enviado a la puerta de enlace las direcciones IP externas para las APIs de Google Google Cloud. Más bien, Google Cloud habilita automáticamente el Acceso privado a Google para un rango de direcciones IP de subred cuando configuras NAT pública para aplicar a ese rango de subred, ya sea principal o como 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.

R NAT pública la puerta de enlace no cambia la forma El Acceso privado a Google funciona. 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. R La puerta de enlace de Cloud NAT creada en una red de VPC no puede proporcionan NAT a las VMs en otras redes de VPC conectadas por con el intercambio de tráfico entre redes de VPC, incluso si las VMs de las redes con intercambio de tráfico están en la misma región que la puerta de enlace.

Interacción con GKE

R 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. El NAT pública puerta de enlace debe configurarse para aplicarse al menos a los siguientes rangos de direcciones IP de subredes 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 pañal NAT pública para aplicar a todos los rangos de direcciones IP de subredes 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 un elemento NAT pública puerta de enlace está configurada para proporcionar NAT del clúster, 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 alias de IP que contenga más de una dirección IP (máscara de red más pequeña que /32).

  • Si la asignación de puertos estáticos es la NAT pública, la NAT pública procedimiento de reserva de puertos 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.

Independiente de NAT pública , Google Kubernetes Engine se encarga de las redes de origen traducción de direcciones (NAT de origen o SNAT) usando software que se ejecuta en cada nodo cuando los Pods envían paquetes a Internet a menos que hayas cambiado el enmascaramiento de IP del clúster actual. Si necesitas detallado sobre el tráfico de salida desde los Pods, puedes usar una red política.

Bajo ciertas circunstancias, NAT pública puede ser útil para usuarios no privados clústeres nativos de la VPC. Debido a que los nodos de un clúster no privado tienen direcciones IP externas, los paquetes enviados desde la dirección IP interna principal del nodo Cloud NAT: Sin embargo, si las siguientes afirmaciones son verdaderas, los paquetes enviados desde Los Pods en un clúster no privado pueden procesarse NAT pública puerta de enlace:

  • Para los clústeres nativos de la VPC, la NAT pública la puerta de enlace está para aplicar 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.

El siguiente ejemplo 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, quieres que tus contenedores se traduzcan con NAT. Cómo habilitar la NAT para todos los contenedores y el nodo de GKE, debes elegir todos los Rangos de direcciones IP de Subnet 1 como candidato de NAT:

  • Rango de direcciones IP principal de la subred: 10.240.0.0/24
  • Rango de direcciones IP secundario de la subred usado para Pods: 10.0.0.0/16

No se puede habilitar NAT solo para Pod1 o Pod2.

Una puerta de enlace NAT privada puede realizar NAT para nodos y Pods en un clúster privado y en un clúster no privado. El La puerta de enlace 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 directas de salida de VPC

NAT pública pueden realizar NAT para servicios de Cloud Run o trabajos configurados con Salida de VPC directa. Para permitir que Cloud Run use una NAT pública de enlace, configura tu NAT pública con la siguiente configuración:

  • Para configurar qué subredes y rangos de direcciones IP de subredes asociados con tu Las instancias de Cloud Run pueden usar el NAT pública puerta de enlace 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 el NAT pública especifica el objeto --nat-all-subnet-ip-ranges marca.
    • Para permitir que solo subredes y rangos de direcciones IP específicos de subredes, usa el NAT pública especifícalas con el comando --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 VM de salida de VPC directa puedan usar el NAT pública de enlace NAT.
  • En el caso de la asignación de puertos estáticos, establece el valor de --min-ports-per-vm. a cuatro veces la cantidad de puertos requeridos por 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 NAT pública puerta de enlace para dar cuenta de de la cantidad de instancias de Google Cloud y la cantidad de las instancias de Cloud Run implementadas en tu de VPC de Google Cloud.

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

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

Para evitar que los servicios o trabajos de Cloud Run configura la marca --vpc-egress como private-ranges-only para que no use un NAT pública de la puerta de enlace, haz lo siguiente:

  • Configura el 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 servicios o trabajos de Cloud Run con la marca --vpc-egress. se define en all-traffic.

Las siguientes limitaciones se aplican a los servicios y trabajos de Cloud Run que usan puertas de enlace 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 una servicio, revisión o trabajo de Cloud Run.

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

Interacciones de las pruebas de conectividad

Puedes usar pruebas de conectividad para verificar la conectividad entre redes extremos 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 configuración de NAT en el seguimiento del análisis de configuración. en la página Detalles de la prueba de conectividad.

Interacciones con Cloud Load Balancing

Balanceadores de cargas de aplicaciones internos regionales de Google Cloud y balanceadores de cargas de aplicaciones externos regionales comunicarse con varios backends de grupos de extremos de red (NEG) regionales de Internet. Con la configuración de las puertas de enlace de Cloud NAT para la NEG regionales de Internet, puedes asignar tu propio conjunto de rangos de direcciones IP externas desde donde debe originarse el tráfico de Google Cloud. Las verificaciones de estado y El tráfico del plano de datos se origina en 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 VMs a través de rutas especiales. VMs de backend no requieren direcciones IP externas ni tampoco una puerta de enlace la comunicación entre balanceadores de cargas y 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?