Verbindungen von Servern in einem privaten Subnetz nach außen (Plattform-Authentifizierung, Zahlung, externe APIs) laufen über ein NAT-Gateway, das Adresse und Port umschreibt. Übersteigen die gleichzeitigen Verbindungen zum selben Ziel das Port-Limit des Gateways, schlagen neue Verbindungen fehl.
Warum Server öffnen viele kurze Verbindungen zur selben externen Adresse, etwa für Plattform-Authentifizierung oder Zahlung, oder halten Verbindungen lange offen → Folge NAT-Gateway kann für dieses Ziel keine weiteren Quellports vergeben, neue Verbindungen schlagen fehl → Auf dem Bildschirm Im Spiel selbst läuft alles, nur Funktionen mit externen Aufrufen wie Login, Zahlung oder Belohnungsvergabe scheitern oder hängen (Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback)
Verbindungen zu externen APIs wiederverwenden (HTTP Keep-Alive, Connection-Pool) und nicht für jede Anfrage eine neue Verbindung öffnen, Idle-Verbindungen im Pool in kürzeren Abständen als das NAT-Idle-Timeout (AWS 350 s) per Keepalive aktiv halten oder vorher schließen, nach Fehlern mit wachsenden, zufällig gestreuten Abständen erneut versuchen, Fehlerrate und Latenz pro externem Aufruf protokollieren.
Aufgaben Infrastrukturteam
Dem NAT-Gateway IP-Adressen hinzufügen (ein öffentliches AWS NAT Gateway nimmt standardmäßig nur 2 Elastic IPs auf, für mehr eine Kontingenterhöhung beantragen), Gateways nach Availability Zone und Subnetz aufteilen, Alarm auf Metriken für fehlgeschlagene Portzuweisung (AWS ErrorPortAllocation, Azure SNAT Connection Count mit Status Failed, Google Cloud dropped_sent_packets_count mit OUT_OF_RESOURCES), bei Google Cloud NAT die Mindestzahl an Ports pro VM erhöhen oder dynamische Portzuweisung nutzen.
Größenordnungen
Ein AWS NAT Gateway kann pro IP-Adresse bis zu 55.000 gleichzeitige Verbindungen zum selben Ziel (IP, Port, Protokoll) öffnen, mit bis zu 8 IPs lässt sich das erweitern. Verbindungen, die 350 s still sind, werden gelöscht, und Pakete, die danach über diese Verbindung gesendet werden, erhalten ein RST. Azure NAT Gateway bietet 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs). Google Cloud NAT verteilt 64.512 Ports pro NAT-IP auf die VMs. Da die Mindestzahl an Ports pro VM standardmäßig 64 beträgt (statische Zuweisung), ist eine VM mit Standardeinstellungen meist auf 64 gleichzeitige Verbindungen zum selben Ziel begrenzt.
Im Graphen
Plateau am Limit · Gleichzeitige Verbindungen des NAT-Gateways, fehlgeschlagene Portzuweisungen
Wo nachsehen
Bei AWS die NAT-Gateway-Metriken ErrorPortAllocation, ActiveConnectionCount und PacketsDropCount in CloudWatch (Azure: SNAT Connection Count gefiltert auf Status Failed und Dropped Packets, Google Cloud: dropped_sent_packets_count mit reason OUT_OF_RESOURCES) neben die Zeitpunkte legen, an denen externe Aufrufe des Spielservers scheitern
Spricht dafür
Zum Zeitpunkt der gescheiterten externen Aufrufe ist ErrorPortAllocation (Azure: SNAT Connection Count mit Status Failed, Google Cloud: Drops mit OUT_OF_RESOURCES) größer als 0, und die Fehler betreffen Aufrufe zu ein, zwei Zielen mit vielen Verbindungen wie Authentifizierungs- oder Zahlungsservern
Spricht dagegen
Fehlgeschlagene Portzuweisungen bei 0, aber connect auf dem Spielserver scheitert mit EADDRNOTAVAIL, und TIME_WAIT nähert sich dem Bereich der ephemeren Ports: „Erschöpfte ephemere Ports bei Verbindungen zwischen Servern“. Verbindung klappt, nur die Antwort ist langsam: „Abhängigkeit von externen Diensten“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei „Erschöpfte ephemere Ports bei Verbindungen zwischen Servern“ gehen einem einzelnen Server die ephemeren Ports aus. Hier liegt das Limit beim NAT-Gateway, und alle Server dahinter teilen es sich (Google Cloud NAT teilt es pro VM auf). Haben TIME_WAIT und der Bereich der ephemeren Ports auf dem Server noch Reserven und scheitern trotzdem nur externe Aufrufe, liegt diese Ursache vor. Auch Ports geschlossener Verbindungen werden nicht sofort wieder für dasselbe Ziel verwendet (Azure: Cooldown, Google Cloud: während TIME_WAIT gesperrt). Je öfter kurze Verbindungen aufgebaut werden, desto schneller ist das Limit erreicht.
Quellen
NAT gateway basicsAWS Pro IPv4-Adresse 55.000 gleichzeitige Verbindungen zum selben Ziel (Ziel-IP, Port, Protokoll), mit bis zu 8 IPs erweiterbar (Elastic IPs eines öffentlichen NAT Gateways standardmäßig 2, mehr per Kontingenterhöhung), die Bandbreite skaliert automatisch von 5 auf 100 Gbps und der Durchsatz von 1 Million auf 10 Millionen Pakete pro Sekunde, darüber hinaus werden Pakete verworfen
NAT gateway metrics and dimensionsAWS ErrorPortAllocation: Zahl der Fälle, in denen kein Quellport vergeben werden konnte (größer als 0 heißt: zu viele gleichzeitige Verbindungen), ActiveConnectionCount, IdleTimeoutCount (nach 350 s Inaktivität aufgeräumte Verbindungen), PacketsDropCount
Troubleshoot NAT gatewaysAWS Nach 350 s Inaktivität läuft die Verbindung ab, weiteres Senden wird mit RST beantwortet, Keepalive in kürzeren Abständen als 350 s empfohlen, bei Erreichen des Verbindungslimits Gateways pro Availability Zone oder zusätzliche IPs einrichten oder die Zahl der Verbindungen senken
Source Network Address Translation (SNAT) with Azure NAT GatewayMicrosoft Azure 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs), jede Verbindung zum selben Ziel braucht einen eigenen Port, geschlossene Ports durchlaufen einen Cooldown, bevor sie wieder für dasselbe Ziel genutzt werden
Metrics and alerts for Azure NAT GatewayMicrosoft Azure Ist SNAT Connection Count gefiltert auf Status Failed größer als 0, sind die SNAT-Ports möglicherweise erschöpft, Dropped Packets
IP addresses and portsGoogle Cloud Pro NAT-IP je 64.512 Ports für TCP und UDP, Standard-Mindestzahl an Ports pro VM 64 (statische Zuweisung) bzw. 32 (dynamische Zuweisung), die für eine VM reservierten Ports begrenzen die gleichzeitigen Verbindungen zum selben Ziel, geschlossene Verbindungen sind während TIME_WAIT nicht nutzbar
Logs and metricsGoogle Cloud dropped_sent_packets_count mit reason OUT_OF_RESOURCES: Pakete, die verworfen wurden, weil NAT-IPs oder Ports nicht reichten
Verwandte Ursachen
Gleiche Schicht: L5 Netzwerkgeräte im Rechenzentrum