Soluciona problemas de configuración

En esta guía, te ayudaremos a resolver problemas comunes con Cloud NAT.

Problemas comunes

Las VM pueden acceder a Internet de forma inesperada, sin Cloud NAT

Si tus instancias de máquina virtual (VM) o instancias de contenedor pueden acceder a Internet sin Cloud NAT, pero no deseas que lo hagan, verifica los siguientes problemas:

• Determina si la interfaz de red de la VM tiene una dirección IP externa. Si la interfaz de red tiene una dirección IP externa asignada, Google Cloud realiza automáticamente NAT uno a uno para los paquetes cuyas fuentes coinciden con la dirección IP interna principal de la interfaz. Para obtener más información, consulta Especificaciones de Cloud NAT.

  Para determinar si una VM tiene una dirección IP externa, consulta cómo cambiar o asignar una dirección IP externa a una instancia existente.

• Asegúrate de que tu clúster de Google Kubernetes Engine (GKE) sea privado. Cada VM de nodo en un clúster no privado tiene una dirección IP externa, por lo que cada nodo puede usar rutas en tu red de nube privada virtual (VPC) cuyo próximo salto es la puerta de enlace predeterminada de Internet sin depender de Cloud NAT. Para obtener más información, incluida la forma en que los clústeres no privados interactúan con las puertas de enlace de Cloud NAT, consulta Interacción con Compute Engine.

• Enumera las rutas en tu red de nube privada virtual y busca las que puedan proporcionar conectividad a Internet a través de un siguiente salto diferente al de la puerta de enlace de Internet predeterminada. A modo de ejemplo:

  • Las rutas estáticas cuyos próximos saltos son VMs, balanceadores de cargas de red de transferencia internos o túneles de Cloud VPN pueden proporcionar de forma indirecta la conectividad a Internet. Por ejemplo, el Es posible que las VMs de próximo salto o de backend para un balanceador de cargas de red de transferencia interno direcciones IP externas, o un túnel de Cloud VPN podrían conectarse a una red que ofrezca acceso a Internet.

  • Las rutas dinámicas que Cloud Routers aprendió de las redes locales en tu red de VPC pueden conectarse a una red que ofrezca acceso a Internet.

• Ten en cuenta que otras rutas personalizadas en tu red de VPC pueden tener prioridades más altas que las rutas cuyos próximos saltos sean puertas de enlace de Internet predeterminadas. Si quieres saber cómo Google Cloud evalúa las rutas, consulta aplicabilidad y orden del enrutamiento.

No se generan registros

• Verifica que el registro de NAT esté habilitado.

• Vuelve a verificar que tu vista de los registros no filtre los registros que buscas. Para obtener instrucciones, consulta Visualiza los registros.

• Asegúrate de que una regla de firewall no esté bloqueando el tráfico. Las reglas de firewall que bloquean el tráfico de salida se aplican antes de que el tráfico se enviara a la puerta de enlace NAT. Puedes usar Registro de reglas de firewall para ver si tus reglas de salida personalizadas bloquean el tráfico saliente.

• Revisa Tipos de Cloud NAT. Es posible que NAT no administre el destino de tu tráfico.

Algunos registros están excluidos

• Verifica que el registro de NAT esté habilitado y que tu filtro de registro no excluya los registros que deseas conservar. Puedes borrar un filtro de registros para que no se excluya nada.

• Cloud NAT no registra todos los eventos. Durante períodos de mucho tráfico de salida, se limita el registro de NAT en forma proporcional al tipo de máquina de la VM. Es posible que se omitan los registros de traducción o de error, y no se puede determinar qué se omite durante la regulación.

Los paquetes se descartaron con motivo de los recursos

Si ves una pérdida de paquetes de VM que usan Cloud NAT, esto podría deberse a que no hay suficientes direcciones IP de origen NAT disponibles ni tuplas de puerto de origen para que la VM se use en el momento de la pérdida del paquete (agotamiento del puerto). Una tupla quíntuple (dirección IP de origen de NAT, puerto de origen y tupla triple de destino) no se puede volver a usar dentro del tiempo de espera TIME_WAIT de TCP.

Si no hay suficientes tuplas NAT disponibles, el motivo dropped_sent_packets_count es OUT_OF_RESOURCES. Para obtener más información sobre las métricas, consulta Usa métricas de instancia de VM.

Consulta Reduce el uso de los puertos para conocer formas de reducir el uso de puertos.

Si usas la asignación dinámica de puertos, consulta la siguiente sección para conocer las formas de reducir los descartes de paquetes cuando se usa la asignación dinámica de puertos.

Se descartan paquetes cuando se configura la asignación dinámica de puertos

La asignación dinámica de puertos detecta cuando una VM está a punto de salir de los puertos y duplica la cantidad de puertos asignados a la VM. Esto ayuda a garantizar que los puertos no se desperdicien, pero puede dar como resultado que se descarten paquetes mientras aumenta la cantidad de puertos asignados.

Para reducir la cantidad de paquetes descartados, considera lo siguiente:

• Si puedes aumentar las conexiones más rápido, Cloud NAT tiene más tiempo para asignar más puertos.

• Si las VMs realizan conexiones TCP, puedes configurar las VMs con un valor mayor para tcp_syn_retries, lo que le da al sistema más tiempo para establecer la conexión y aumenta las probabilidades de que esta se realice correctamente.

  Por ejemplo, puedes ver la configuración actual para las VM de Linux:

    sysctl net.ipv4.tcp_syn_retries
    

  Si es necesario, puedes aumentar la configuración:

    sudo sysctl -w net.ipv4.tcp_syn_retries=NUM
    

  Nota: Aumentar el valor de tcp_syn_retries puede generar latencia, ya que el sistema sigue descartando paquetes hasta que la conexión se realiza correctamente después de varios reintentos.

• Si tienes cargas de trabajo inestables y necesitas asignar más puertos con rapidez, es posible que debas ajustar la cantidad mínima de puertos por VM. Visualiza el uso del puerto y determina un número mínimo de puertos adecuado por VM.

Paquetes descartados con el motivo: conflicto independiente de extremo

Nota: Esta sección no se aplica a NAT privada.

Si ves pérdida de paquetes en VMs que usan NAT pública El mapeo independiente de extremo activado. La pérdida de paquetes podría deberse a un de extremo independiente conflicto. Si es así, el motivo de dropped_sent_packets_count es ENDPOINT_INDEPENDENT_CONFLICT. Para obtener más información sobre las métricas, consulta Usa métricas de instancia de VM.

Puedes reducir las posibilidades de conflictos independientes de extremos si usas las siguientes técnicas:

• Desactiva el mapeo independiente de extremos. Esto permite que la conexión nueva de una dirección IP y un puerto de origen determinado usen una dirección IP y un puerto NAT diferentes que antes. Si inhabilitas o habilitas el mapeo independiente de extremos, no se interrumpirán las conexiones establecidas.

• Aumenta la cantidad mínima predeterminada de puertos NAT por instancia de VM para que el procedimiento de reserva de puertos pueda asignar más IP de origen de NAT y tuplas de direcciones de origen y puertos a cada VM cliente. Esto disminuye la probabilidad de que dos o más direcciones IP de cliente y tuplas de puerto de origen efímeras tengan la misma dirección IP de origen y tupla de puerto de origen de NAT.

• Comprueba cuántos puertos de origen efímeros se están usando:

  • Para las VM de Linux:

    netstat -an | egrep 'ESTABLISHED|TIME_WAIT|CLOSE_WAIT' | wc -l
    

  • Para las VM de Windows:

    netstat -tan | findstr "ESTABLISHED TIME_WAIT CLOSE_WAIT" | find /c /v ""
    

• Configura tus instancias de VM para usar un conjunto más grande de puertos de origen efímeros:

  • Para las VM de Linux:

    • Puedes ver qué rango de puertos está configurado con este comando:

      cat /proc/sys/net/ipv4/ip_local_port_range
      

    • Puedes definir ip_local_port_range como la cantidad máxima de puertos de origen efímeros (64,512) con este comando:

      echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
      

  • Para las VM de Windows:

    • Puedes ver qué rangos de puertos están configurados con estos comandos:

      netsh int ipv4 show dynamicport tcp
      netsh int ipv4 show dynamicport udp
      

    • Puedes establecer la cantidad máxima de puertos TCP y UDP de origen efímeros en el máximo posible (64,512) con estos comandos:

      netsh int ipv4 set dynamicport tcp start=1024 num=64512
      netsh int ipv4 set dynamicport udp start=1024 num=64512
      

    • En los nodos de Google Kubernetes Engine, puedes automatizar esta configuración mediante un DaemonSet con privilegios.

• En el caso de los clústeres de GKE, inhabilita la NAT de origen que se realiza en cada nodo para los paquetes que se envían a los destinos de interés. Para esto, puedes usar uno de estos métodos:

  • Si implementas ip-masq-agent y agregas los destinos de interés a la lista de nonMasqueradeCIDRs.

  • Inhabilita la SNAT para los destinos predeterminados sin enmascarar con la marca --disable-default-snat cuando crees un clúster.

Paquetes recibidos descartados

Una puerta de enlace de Cloud NAT mantiene una tabla de seguimiento de conexiones para almacenar datos activos y las asignaciones de puertos y direcciones IP de las VMs: cómo las direcciones IP y los puertos a direcciones IP y puertos de NAT. Una puerta de enlace de Cloud NAT descarta una entrada un paquete de datos si la tabla de seguimiento de conexión no que contiene cualquier entrada para la conexión.

La ausencia de una entrada de conexión en la tabla puede deberse a alguno de los siguientes motivos: motivos:

• Se agotó el tiempo de espera de una conexión TCP establecida porque el tiempo de espera de inactividad de la conexión TCP establecida venció debido a la inactividad.
• Un extremo externo no puede establecer una conexión nueva antes de que venza el tiempo de espera de inactividad de la conexión transitoria de TCP. Por ejemplo, un recurso de Google Cloud inicia una conexión con TCP SYN, pero el extremo externo no responde con un SYN ACK.
• Un extremo externo, como un sistema de sondeo, intenta conectarse a una dirección IP de NAT y puerto. Cloud NAT no acepta conexiones entrantes no solicitadas. Las entradas de este tipo de conexiones no estarán presentes en la tabla de conexiones. Por lo tanto, se descartarán todos los paquetes recibidos.
• Si quitas las IP de NAT de tu puerta de enlace mientras las conexiones de NAT aún están activas, las asignaciones de NAT dejan de ser válidas y estas conexiones se quitan de inmediato de la tabla de seguimiento de conexiones, y se descarta todo el tráfico de retorno.

Antes de abordar las pérdidas de paquetes de entrada, confirma si estas afectan realmente tu aplicación. Para confirmar, verifica si hay errores en tu aplicación cada vez que se produzcan aumentos repentinos en los paquetes de entrada perdidos.

Si las pérdidas de paquetes de entrada afectan tu aplicación, intenta usar el siguiente técnicas para abordar el problema:

• Usa mecanismos de keepalive en tu aplicación para que las conexiones de larga duración pueden permanecer abiertos por un período más largo.
• Aumenta el valor del tiempo de espera de inactividad de la conexión transitoria de TCP para que los extremos externos que reciben tráfico (iniciado por recursos de Google Cloud) a través de una puerta de enlace de Cloud NAT tengan más tiempo para responder y establecer la conexión.
• Aumenta el valor del tiempo de espera de inactividad de la conexión establecida de TCP, si tienes disminuyó significativamente el valor predeterminado.

Nota: Aumenta el valor de TCP y del tiempo de espera de inactividad de la conexión transitoria de TCP. El tiempo de espera de inactividad de la conexión establecido afecta la forma en que se reutiliza Cloud NAT y puertos. La puerta de enlace mantiene un puerto asignado a la conexión por un período más prolongado, incluso si no se establece o no recibe tráfico durante un tiempo.

Es necesario asignar más direcciones IP

En ocasiones, tus VM no pueden acceder a Internet, ya que no tienes suficientes direcciones IP de NAT. Varios factores pueden causar este problema. Para obtener más información, consulta los siguientes recursos:

Causa raíz	Síntoma	Solución
Asignaste direcciones de forma manual, pero no asignaste suficientes, dado el uso actual de tu puerto.	La consola de Google Cloud muestra un error que dice Debes asignar al menos “X” direcciones IP más para permitir que todas las instancias accedan a Internet. El valor de la métrica nat_allocation_failed es true.	Realice una de las acciones siguientes: Minimiza el uso de puertos, como se describe en Reduce el uso de puertos. Agrega manualmente más direcciones IP, como se describe en Cambia direcciones IP externas asociadas con NAT.
Superaste un límite estricto para las direcciones IP de NAT.	El valor de la métrica nat_allocation_failed es true.	Minimiza el uso de puertos, como se describe en Reduce el uso de puertos.

Para supervisar las fallas que generan una cantidad insuficiente de direcciones IP, crea una alerta para la métrica nat_allocation_failed. Esta métrica se establece en true si Google Cloud no puede asignar suficientes direcciones IP para ninguna VM de tu puerta de enlace de NAT. Para obtener información sobre las políticas de alertas, consulta Define políticas de alertas.

Reduce el uso de puertos

Puedes minimizar la cantidad de puertos que usa cada VM en situaciones en las que no es posible ni recomendable asignar más direcciones IP de NAT.

Importante: Si necesitas una asignación independiente de extremos, las recomendaciones de esta no se aplican las políticas. Debes aumentar la cantidad de direcciones IP de NAT disponibles y de tuplas de puerto configuradas en la puerta de enlace NAT o usar varias puertas de enlace NAT.

Advertencia: Es posible que se interrumpan las conexiones establecidas si habilitas o inhabilitas la asignación dinámica de puertos, o si disminuyes la cantidad mínima de puertos por VM. Para obtener más información, consulta Cambia el método de asignación de puertos y Reduce los puertos por VM.

Para reducir el uso de puertos, completa los siguientes pasos:

1. Inhabilita la asignación independiente de extremos.

2. Habilita la asignación dinámica de puertos. Para usar la asignación dinámica de puertos, debes establecer una cantidad mínima de puertos por VM y una cantidad máxima de puertos por VM. Cloud NAT asigna automáticamente una cantidad de direcciones IP de origen de NAT y tuplas de puerto de origen entre la cantidad mínima y máxima de puertos, inclusiva. Usar un número bajo para la cantidad mínima de puertos reduce el desperdicio de direcciones IP de origen de NAT y de tuplas de puerto de origen en VMs con menos conexiones activas. Si encuentras tiempos de espera de conexión mientras se asignan puertos, consulta Reduce la pérdida de paquetes con la asignación dinámica de puertos.

3. Determina la cantidad mínima de puertos más baja posible para satisfacer tus necesidades. Existen varios métodos para hacerlo y la mayoría se basa en la revisión de la cantidad de puertos usados (compute.googleapis.com/nat/port_usage) como entrada para el proceso de toma de decisiones. Para obtener información sobre cómo encontrar el uso de puertos, consulta Visualiza el uso de puertos. Los siguientes son dos métodos de ejemplo para determinar una cantidad mínima de puertos:

   • Considera el valor promedio de compute.googleapis.com/nat/port_usage durante un período representativo para una cantidad representativa de VMs.
   • Considera el valor más común de compute.googleapis.com/nat/port_usage durante un período representativo para una cantidad representativa de VMs.

4. Determina la cantidad máxima de puertos más baja posible para satisfacer tus necesidades. Una vez más, revisa compute.googleapis.com/nat/port_usage como entrada para el proceso de toma de decisiones. Considera el valor máximo de compute.googleapis.com/nat/port_usage durante un período representativo para una cantidad representativa de VMs como un punto de partida para la cantidad máxima de puertos. Ten en cuenta que establecer una cantidad máxima demasiada alta puede evitar que otras VMs reciban direcciones IP de origen de NAT y tuplas de puerto de origen.

5. Encontrar los valores correctos para la cantidad de puertos mínima y máxima implica pruebas iterativas. Si quieres conocer los pasos para cambiar la cantidad mínima y máxima de puertos, consulta Cambia la cantidad mínima o máxima de puertos cuando está configurada la asignación dinámica de puertos.

6. Revisa los tiempos de espera de NAT, sus significados y sus valores predeterminados. Si necesitas crear con rapidez una serie de conexiones de TCP a la misma tupla triple de destino, considera reducir el tiempo de espera de TCP para que Cloud NAT pueda volver a usar con mayor rapidez la dirección IP de origen de NAT y las tuplas de puerto de origen. Esto permite que Cloud NAT use más rápido la misma tupla quíntuple en lugar de tener que usar una única tupla quíntuple, que podría requerir la asignación de direcciones IP de origen de NAT y tuplas de puerto de origen adicionales para cada VM que envía. Si quieres conocer los pasos para cambiar los tiempos de espera de NAT, consulta Cambia los tiempos de espera de NAT.

Preguntas frecuentes

Restricción regional para Cloud NAT

¿Puedo usar la misma puerta de enlace de Cloud NAT en más de una región?

No. Una puerta de enlace NAT de Cloud no se puede asociar con más de una región, una red de VPC o Cloud Router.

Si necesitas proporcionar conectividad para otras regiones o redes de VPC, crea puertas de enlace adicionales de Cloud NAT para ellas.

Pregunta: ¿Las direcciones IP NAT externas que usan las puertas de enlace de Cloud NAT son globales o regionales?

Las puertas de enlace de Cloud NAT usan direcciones IP externas regionales como direcciones IP NAT. Aunque son regionales, se pueden enrutar públicamente. Para obtener información sobre las formas diferentes en que se pueden asignar direcciones IP NAT, consulta Direcciones IP NAT.

Cuándo se puede usar Cloud NAT

¿Cloud NAT se aplica a las instancias, incluidas las VM de nodo de GKE, que tienen direcciones IP externas?

En general, no. Si la interfaz de red de una VM tiene una dirección IP externa, Google Cloud siempre realiza NAT uno a uno para los paquetes enviados desde la dirección IP interna principal de la interfaz de red sin usar Cloud NAT. Sin embargo, de todos modos Cloud NAT podría proporcionar servicios NAT a los paquetes enviados desde rangos de direcciones IP de alias de esa misma interfaz de red. Para obtener detalles adicionales, consulta Cloud NAT especificaciones y Compute Engine interactiva.

¿La NAT pública permite que una VM de origen cuya interfaz de red no tenga una dirección IP externa envíe tráfico a una VM de destino o a un balanceador de cargas que tenga una dirección IP externa, incluso si la fuente y el destino están en la misma red de VPC?

Sí. La ruta de acceso a la red implica enviar tráfico fuera de la red de VPC a través de una puerta de enlace de Internet predeterminada y, luego, recibirlo en la misma red.

Cuando la VM de origen envía un paquete al destino, la NAT pública realiza NAT de origen (SNAT) antes de entregar el paquete a la segunda instancia. La NAT pública lleva a cabo la NAT de destino (DNAT) para las respuestas de la segunda a la primera. Para ver un ejemplo paso a paso, consulta Flujo de trabajo y configuración básica de NAT pública.

¿Puedo usar NAT privada para la comunicación entre VMs en la misma red de VPC?

No, la NAT privada no realiza NAT en el tráfico entre VMs en la misma red de VPC.

No se admiten conexiones entrantes no solicitadas

¿Cloud NAT admite conexiones entrantes (por ejemplo, SSH) a instancias sin direcciones IP externas?

No, Cloud NAT no admite conexiones entrantes no solicitadas. Para obtener más información, consulta Especificaciones de Cloud NAT. Sin embargo, el perímetro de red de Google Cloud podría responder a pings si la dirección IP de destino es una dirección IP externa de la puerta de enlace de Cloud NAT que tiene asignaciones de puertos activas a, al menos, una instancia de VM. Para ver las direcciones IP asignado a una puerta de enlace de Cloud NAT, usa el Comando gcloud compute routers get-nat-ip-info. Es posible que las direcciones IP externas marcadas como IN_USE respondan a pings.

Si necesitas conectarte a una VM que no tiene una dirección IP externa, consulta Elige una opción de conexión para VMs solo internas. Por ejemplo, como parte del ejemplo de Cloud NAT Compute Engine configuración, te conectes a una VM sin una dirección IP externa con Identity-Aware Proxy.

Cloud NAT y puertos

¿Por qué una VM tiene una cantidad fija de puertos (de forma predeterminada, 64)?

Cuando una puerta de enlace de Cloud NAT proporciona NAT para una VM, reserva la dirección de origen y las tuplas de puerto de origen según el procedimiento de reserva de puerto.

Para obtener más información, consulta los ejemplos de reservas de puertos.

Pregunta:: ¿Puedo cambiar el número mínimo de puertos reservados para una VM?

Sí. Puedes aumentar o disminuir la cantidad mínima de puertos por VM cuando creas una puerta de enlace de Cloud NAT nueva o si la editas más tarde. Cada puerta de enlace de Cloud NAT reserva tuplas de puertos de origen y direcciones de origen según el procedimiento de reserva de puertos.

Para obtener más información sobre la reducción de la cantidad mínima de puertos, consulta la siguiente pregunta.

¿Puedo reducir la cantidad mínima de puertos por VM después de crear la puerta de enlace de Cloud NAT?

Sí. Sin embargo, disminuir la cantidad mínima de puertos puede provocar que el procedimiento de reserva de puertos reserve una cantidad más pequeña de puertos por VM. Cuando esto sucede, puede que las conexiones TCP existentes se reinicien y, de ser así, se deben restablecer.

Cuando se cambia la asignación NAT de los rangos primario y secundario a Solo rango principal, ¿se asignan puertos adicionales a cada instancia inmediatamente?

No. Los puertos adicionales usados por rangos secundarios las retienen las instancias hasta que se reduzca la configuración de puertos mínimos por VM. Cuando Cloud NAT se configura para asignar rangos secundarios (alias) para subredes, Cloud NAT asigna un mínimo de 1,024 puertos por instancia en función del procedimiento de reserva de puertos.

Cuando cambias solo a rangos primarios, Cloud NAT conserva esos puertos asignados adicionales para instancias que ya tienen asignados esos puertos. Después de cambiar los rangos para los que Cloud NAT se aplica solo a principal, la cantidad real de puertos asignados a esas instancias no se cambiará hasta que se reduzca la configuración puertos mínimos por VM.

Para reducir la cantidad de puertos asignados a esas instancias, después del cambio a rangos principales, se debe reducir la configuración de puertos mínimos por VM. Después de reducir ese valor, Cloud NAT ajusta de forma automática la cantidad de puertos asignados por instancia, lo que reduce el consumo de puertos.

Cloud NAT y otros servicios de Google

¿Cloud NAT habilita el acceso a los servicios y las API de Google?

Cuando habilitas Cloud NAT para el rango de IP principal de una subred, Google Cloud habilita el Acceso privado a Google de forma automática. Para obtener más información, consulta Interacción con el Acceso privado a Google.

¿Qué sigue?

• Obtén asistencia