Límites de conexiones y puertos del gateway NAT en la nube Cloud NAT gateway connection / port limits

ID de la causa dc-nat-gateway · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Cuando los servidores de una subred privada abren conexiones hacia fuera (autenticación de la plataforma, pagos, API externas), el gateway NAT cambia su dirección y su puerto antes de enviarlas. Si las conexiones simultáneas hacia un mismo destino superan el límite de puertos del gateway, las conexiones nuevas fallan.

Por qué Los servidores abren muchas conexiones cortas hacia una misma dirección externa, como la autenticación de la plataforma o los pagos, o mantienen conexiones abiertas mucho tiempo → Efecto El gateway NAT no puede asignar más puertos de origen para ese destino, así que las conexiones nuevas fallan → En pantalla Dentro del juego todo va bien, pero fallan o tardan solo las funciones que llaman a servicios externos, como el inicio de sesión, los pagos o la entrega de recompensas (el juego no conecta o se queda en carga infinita; acciones perdidas o rollback)

Síntomas: No conecta / carga infinita, Acción perdida / rollback
Factores: Pérdida de paquetes, Latencia
A quién afecta: Solo una función, Todo el servidor
Cuándo: Al conectar o tras un mantenimiento, Horas pico de la noche, Cuando se junta mucha gente
Responsable: Responsable principal Infraestructura de red (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Reutilizar las conexiones a las API externas (HTTP keep-alive, pool de conexiones) y no abrir una conexión nueva por cada solicitud, enviar keepalive en las conexiones inactivas del pool a intervalos más cortos que el timeout por inactividad del NAT (350 s en AWS) o cerrarlas antes, reintentar los fallos con intervalos crecientes y aleatorios, registrar la tasa de fallos y la latencia de cada llamada externa.
Tareas (Equipo de infraestructura): Añadir direcciones IP al gateway NAT (un gateway NAT público de AWS solo admite 2 IP elásticas por defecto; para más, pedir un aumento de cuota), separar los gateways por zona de disponibilidad y subred, poner alertas sobre las métricas de fallos de asignación de puertos (ErrorPortAllocation en AWS, Failed en SNAT Connection Count de Azure, OUT_OF_RESOURCES en dropped_sent_packets_count de Google Cloud), subir el mínimo de puertos por VM o usar la asignación dinámica de puertos en Google Cloud NAT.
Cifras de referencia: Un gateway NAT de AWS puede abrir hasta 55,000 conexiones simultáneas hacia un mismo destino (IP, puerto y protocolo) por cada dirección IP, y se amplía asociando hasta 8 IP. Borra las conexiones que pasan 350 segundos en silencio y responde con RST a los paquetes que se envíen después por ellas. Azure NAT Gateway tiene 64,512 puertos SNAT por IP pública (hasta 16 IP). Google Cloud NAT reparte entre las VM 64,512 puertos por cada IP de NAT, pero el mínimo por defecto es de 64 puertos por VM (asignación estática), así que con la configuración por defecto una VM suele quedar limitada a 64 conexiones simultáneas hacia un mismo destino.
En el gráfico: Topa con el límite · Conexiones simultáneas del gateway NAT, fallos de asignación de puertos
Dónde mirar: Poner las métricas del gateway NAT ErrorPortAllocation, ActiveConnectionCount y PacketsDropCount de CloudWatch en AWS (en Azure, SNAT Connection Count filtrado por el estado Failed y Dropped Packets; en Google Cloud, dropped_sent_packets_count con reason OUT_OF_RESOURCES) junto a las horas en que fallaron las llamadas externas del servidor del juego
Se confirma si: Cuando fallan las llamadas externas, ErrorPortAllocation (en Azure, SNAT Connection Count en estado Failed; en Google Cloud, los descartes por OUT_OF_RESOURCES) pasa de 0, y los fallos se concentran en las llamadas a uno o dos destinos con muchas conexiones, como los servidores de autenticación o de pagos
Se descarta si: Si los fallos de asignación de puertos están en 0, pero el connect del servidor del juego falla con EADDRNOTAVAIL y las conexiones en TIME_WAIT se acercan al tamaño del rango de puertos efímeros, apunta a “Agotamiento de puertos efímeros en conexiones entre servidores”. Si conecta, pero las respuestas tardan, a “Dependencia de servicios externos”
Se verifica con: Con herramientas de infraestructura (no hace falta código del juego)
Para saber más: En “Agotamiento de puertos efímeros en conexiones entre servidores” se acaban los puertos efímeros de un solo servidor. Este límite, en cambio, está en el gateway NAT y lo comparten todos los servidores que hay detrás (Google Cloud NAT lo reparte por VM). Si solo fallan las llamadas externas mientras los servidores tienen margen de sobra en TIME_WAIT y en el rango de puertos efímeros, la causa es esta. Los puertos de las conexiones cerradas tampoco se reutilizan enseguida para el mismo destino (Azure aplica un periodo de espera y Google Cloud no los deja usar durante TIME_WAIT), así que cuantas más conexiones cortas se repiten, antes se llega al límite.

Fuentes

NAT gateway basics AWS
55,000 conexiones simultáneas por dirección IPv4 hacia un mismo destino (IP, puerto y protocolo de destino), ampliable asociando hasta 8 IP (los gateways NAT públicos tienen 2 IP elásticas por defecto y se amplían pidiendo un aumento de cuota); el ancho de banda escala automáticamente de 5 a 100 Gbps y el throughput de 1 millón a 10 millones de paquetes por segundo, y los paquetes que superan ese límite se descartan
NAT gateway metrics and dimensions AWS
ErrorPortAllocation: veces que no se pudo asignar un puerto de origen (si pasa de 0, hay demasiadas conexiones simultáneas), ActiveConnectionCount, IdleTimeoutCount (conexiones eliminadas tras 350 s de inactividad), PacketsDropCount
Troubleshoot NAT gateways AWS
Tras 350 s de inactividad la conexión expira y, si se sigue enviando, se responde con RST; se recomienda un keepalive de menos de 350 s; al llegar al límite de conexiones, añadir gateways por zona de disponibilidad, añadir IP o reducir las conexiones
Source Network Address Translation (SNAT) with Azure NAT Gateway Microsoft Azure
64,512 puertos SNAT por IP pública (hasta 16 IP); cada conexión hacia un mismo destino necesita un puerto distinto; los puertos cerrados pasan un periodo de espera (cooldown) antes de reutilizarse para el mismo destino
Metrics and alerts for Azure NAT Gateway Microsoft Azure
Si SNAT Connection Count filtrado por el estado Failed pasa de 0, es posible que se hayan agotado los puertos SNAT; Dropped Packets
IP addresses and ports Google Cloud
64,512 puertos para TCP y otros tantos para UDP por IP de NAT; mínimo de puertos por VM por defecto: 64 (asignación estática) o 32 (asignación dinámica); los puertos reservados para una VM limitan sus conexiones simultáneas hacia un mismo destino; los puertos de las conexiones cerradas no se pueden usar durante TIME_WAIT
Logs and metrics Google Cloud
dropped_sent_packets_count con reason OUT_OF_RESOURCES: paquetes descartados por falta de IP o puertos de NAT

Ver también

Misma capa: L5 Equipos de red del centro de datos

Causas de otras capas con el mismo síntoma (No conecta / carga infinita)

Inspección de paquetes del software de seguridad L2 SO y dispositivo del cliente
Router poco potente o sobrecalentado L3 Red doméstica
Restricciones en Wi-Fi público y redes corporativas L3 Red doméstica
Restricciones de UDP e inspección de paquetes por país o ISP L4 Ruta por internet
Fallos y lentitud del DNS L4 Ruta por internet
Enlaces compartidos saturados por un DDoS L4 Ruta por internet
IP compartida del ISP (CGNAT) L4 Ruta por internet
Paso por una VPN o un acelerador de juegos L4 Ruta por internet

Ver la ficha interactiva con gráficos y simulaciones