Solucionar problemas de configuración

Esta guía puede ayudarle a resolver problemas habituales con Cloud NAT.

Problemas más comunes

Las VMs pueden acceder a Internet de forma inesperada sin Cloud NAT

Si tus instancias de máquina virtual o de contenedor pueden acceder a Internet sin Cloud NAT, pero no quieres que lo hagan, comprueba si se da alguno de los siguientes problemas:

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

  Para determinar si una VM tiene una dirección IP externa, consulta el artículo sobre cómo cambiar o asignar una dirección IP externa a una instancia ya creada.

• Asegúrate de que tu clúster de Google Kubernetes Engine (GKE) sea privado. Cada VM de nodo de 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) cuya siguiente parada sea la pasarela de Internet predeterminada sin depender de Cloud NAT. Para obtener más información, incluido cómo interactúan los clústeres no privados con las pasarelas de Cloud NAT, consulta Interacción con Compute Engine.

• Lista las rutas de tu red de nube privada virtual y busca las que puedan proporcionar conectividad a Internet a través de un siguiente salto distinto de la pasarela de Internet predeterminada. Por ejemplo:

  • Las rutas estáticas cuyos siguientes saltos son máquinas virtuales, balanceadores de carga de red internos de tipo pasarela o túneles de Cloud VPN pueden proporcionar conectividad a Internet de forma indirecta. Por ejemplo, las máquinas virtuales de salto siguiente o las máquinas virtuales de backend de un balanceador de carga de red interno de tipo pasarela pueden tener direcciones IP externas o un túnel de Cloud VPN puede conectarse a una red que ofrezca acceso a Internet.

  • Las rutas dinámicas aprendidas de las redes on-premise por los routers de Cloud Router de tu red de VPC pueden conectarse a una red que ofrezca acceso a Internet.

• Ten en cuenta que otras rutas personalizadas de tu red VPC pueden tener prioridades más altas que las rutas cuyos saltos siguientes sean pasarelas de Internet predeterminadas. Para obtener información sobre cómoGoogle Cloud evalúa las rutas, consulta la aplicabilidad y el orden de las rutas.

No se generan registros

• Verifica que el registro de NAT esté habilitado.

• Comprueba que la vista de los registros no esté filtrando los registros que buscas. Para ver las instrucciones, consulta Ver registros.

• Asegúrate de que ninguna regla del cortafuegos esté bloqueando el tráfico. Las reglas de cortafuegos que bloquean el tráfico de salida se aplican antes de que el tráfico se envíe a la pasarela NAT. Puedes usar el almacenamiento de registros de reglas de cortafuegos para ver si tus reglas de salida personalizadas están bloqueando el tráfico saliente.

• Consulte los tipos de Cloud NAT. Es posible que NAT no gestione el destino de su tráfico.

Se excluyen determinados registros

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

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

Paquetes descartados con el motivo "Sin recursos"

Si observas una pérdida de paquetes en las VMs que usan Cloud NAT, puede deberse a que no hay suficientes tuplas de dirección IP de origen y puerto de origen de NAT disponibles para que las VMs las usen en el momento de la pérdida de paquetes (agotamiento de puertos). Una quíntupla (dirección IP de origen de NAT, puerto de origen y una tupla de destino) no se puede reutilizar en el tiempo de espera TIME_WAIT de TCP.

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

Consulta Reducir el uso de puertos para ver cómo hacerlo.

Si usas la asignación dinámica de puertos, consulta la siguiente sección para ver cómo reducir la pérdida de paquetes cuando se usa esta asignación.

Paquetes descartados cuando se configura la asignación dinámica de puertos

La asignación dinámica de puertos detecta cuándo una VM está a punto de quedarse sin puertos y duplica el número de puertos asignados a la VM. De esta forma, se asegura que no se desperdicien puertos, pero pueden perderse paquetes mientras aumenta el número de puertos asignados.

Para reducir el número de paquetes perdidos, ten en cuenta lo siguiente:

• Si puedes aumentar las conexiones más lentamente, Cloud NAT tendrá más tiempo para asignar más puertos.

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

  Por ejemplo, en las máquinas virtuales Linux, puedes ver la configuración actual:

    sysctl net.ipv4.tcp_syn_retries
    

  Si es necesario, puedes aumentar el valor de este ajuste:

    sudo sysctl -w net.ipv4.tcp_syn_retries=NUM
    

• Si tienes cargas de trabajo con picos de actividad y necesitas asignar más puertos rápidamente, puede que tengas que ajustar el número mínimo de puertos por VM. Consulta el uso de tus puertos y determina el número mínimo de puertos por VM adecuado.

Paquetes descartados por conflicto de independencia de endpoint

Si observas una pérdida de paquetes en las máquinas virtuales que usan NAT público y tienes activada la asignación independiente del endpoint, es posible que la pérdida de paquetes se deba a un conflicto independiente del endpoint. Si es así, el dropped_sent_packets_count motivo es ENDPOINT_INDEPENDENCE_CONFLICT. Para obtener más información sobre las métricas, consulta Usar métricas de instancias de VM.

Para reducir las probabilidades de que se produzcan conflictos independientes de los endpoints, puedes usar las siguientes técnicas:

• Desactiva Asignación independiente de puntos finales. De esta forma, la nueva conexión de una dirección IP y un puerto de origen determinados puede usar una dirección IP y un puerto de origen de NAT diferentes a los que usaba antes. Habilitar o inhabilitar la asignación independiente de puntos finales no interrumpe las conexiones establecidas.

• Aumenta el número mínimo predeterminado de puertos NAT por instancia de VM para que el procedimiento de reserva de puertos pueda asignar más tuplas de dirección IP de origen y puerto de origen NAT a cada VM de cliente. De esta forma, se reduce la probabilidad de que se asignen la misma dirección IP de origen de NAT y la misma tupla de puerto de origen a dos o más tuplas de dirección IP de cliente y puerto de origen efímero.

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

  • En el caso de las VMs Linux:

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

  • En las máquinas virtuales de Windows:

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

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

  • En el caso de las VMs Linux:

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

      cat /proc/sys/net/ipv4/ip_local_port_range
      

    • Puedes definir ip_local_port_range en el número máximo de puertos de origen efímeros (64.512) con este comando:

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

  • En las máquinas virtuales de Windows:

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

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

    • Puedes definir el número 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 los clústeres de GKE, inhabilita la NAT de origen que se realiza en cada nodo para los paquetes enviados a los destinos de interés. Puedes hacerlo de dos formas:

  • Para ello, implementa el ip-masq-agent y añade los destinos de interés a la lista de nonMasqueradeCIDRs.

  • Para inhabilitar SNAT en los destinos predeterminados que no usan masquerade con la marca --disable-default-snat al crear un clúster.

Paquetes recibidos descartados

Una pasarela Cloud NAT mantiene una tabla de seguimiento de conexiones para almacenar los detalles de las conexiones activas y las asignaciones de direcciones IP y puertos, es decir, cómo se traducen las direcciones IP y los puertos de las VMs a las direcciones IP y los puertos de NAT. Una pasarela de Cloud NAT descarta un paquete de datos de entrada si la tabla de seguimiento de conexiones no contiene ninguna entrada para la conexión.

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

• Se ha agotado el tiempo de espera de una conexión TCP establecida porque ha caducado el tiempo de espera de inactividad de la conexión TCP establecida.
• Un endpoint externo no puede establecer una nueva conexión antes de que expire el tiempo de espera de conexión transitoria TCP. Por ejemplo, un Google Cloud recurso inicia una conexión con TCP SYN, pero el endpoint externo no responde con un SYN ACK.
• Un endpoint externo, como un verificador, intenta conectarse a una dirección IP y un puerto de NAT. 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 IPs de NAT de tu pasarela mientras las conexiones NAT siguen activas, las asignaciones de NAT dejarán de ser válidas y estas conexiones se eliminarán inmediatamente de la tabla de seguimiento de conexiones, por lo que se descartará cualquier tráfico de retorno.

Antes de abordar las pérdidas de paquetes de entrada, confirma si afectan a tu aplicación. Para confirmarlo, comprueba si hay errores en tu aplicación cuando se produzcan picos en los paquetes de entrada descartados.

Si las pérdidas de paquetes de entrada afectan a tu aplicación, prueba a usar las siguientes técnicas para solucionar el problema:

• Usa mecanismos de mantenimiento de la conexión en tu aplicación para que las conexiones de larga duración puedan permanecer abiertas durante más tiempo.
• Aumenta el valor de Tiempo de espera inactivo de conexión transitoria de TCP para que los endpoints externos que reciben tráfico (iniciado por recursos) a través de una pasarela de Cloud NAT tengan más tiempo para responder y establecer la conexión. Google Cloud
• Aumenta el valor de Tiempo de espera inactivo de conexión establecida de TCP si has reducido significativamente el valor predeterminado.

Necesito asignar más direcciones IP

A veces, tus VMs no pueden acceder a Internet porque no tienes suficientes direcciones IP de NAT. Este problema puede deberse a varios factores. Para obtener más información, consulta la siguiente tabla.

Causa principal	Síntoma	Solución
Has asignado direcciones manualmente, pero no has asignado suficientes teniendo en cuenta el uso de puertos actual.	La consola 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.	Elige una de estas opciones: Minimiza el uso de puertos, tal como se describe en la sección Reduce el uso de puertos. Añade más direcciones IP manualmente, tal como se describe en Actualizar las direcciones IP externas asociadas a NAT.
Has superado el límite estricto de direcciones IP de NAT.	El valor de la métrica nat_allocation_failed es true.	Minimiza el uso de puertos, tal como se describe en la sección Reduce el uso de puertos.

Para monitorizar los fallos causados por un número insuficiente de direcciones IP, crea una alerta para la métrica nat_allocation_failed. Esta métrica se define como true si Google Cloud no puede asignar suficientes direcciones IP a ninguna VM de tu pasarela NAT. Para obtener información sobre las políticas de alertas, consulta Definir políticas de alertas.

Reducir el uso de puertos

Puedes minimizar el número de puertos que usa cada VM en situaciones en las que no es posible o no te interesa asignar más direcciones IP de NAT.

Para reducir el uso de puertos, sigue estos pasos:

1. Inhabilita Asignación independiente de puntos finales.