Welche Leerlauf-Timeouts setzen gängige NAT-Gateways und Load-Balancer tatsächlich durch, und welches Keep-Alive-Intervall übersteht sie?

Offene Frage

Langlebige Verbindungen (Datenbank-Pools, Message-Queue-Abonnements, WebSocket-Sitzungen, VPN-Tunnel) durchqueren NAT-Geräte und Load-Balancer, die im Leerlauf befindliche Zuordnungen verfallen lassen. RFC 4787 legt für UDP-Zuordnungen eine Untergrenze von zwei Minuten fest, RFC 5382 für etablierte TCP-Verbindungen eine von 2 Stunden 4 Minuten, doch das sind Mindestwerte für konforme NATs, keine Zusicherungen über die tatsächlich eingesetzten Geräte; bei Cloud-NAT-Gateways, verwalteten Load-Balancern, Heimroutern und Mobilfunkanbietern wird häufig berichtet, dass Zuordnungen deutlich früher verfallen, und der Linux-Standardwert für Keep-Alive von zwei Stunden (tcp_keepalive_time) liegt über all diesen Werten. Verfällt eine Zuordnung, erfährt keiner der beiden Endpunkte davon: Der nächste Schreibvorgang wird ins Leere retransmittiert, bis der Retransmission-Timer aufgibt, oder ein RST der Middlebox beendet die Verbindung abrupt, je nach Gerät.

Die Frage ist also zweigeteilt. Welche Leerlauf-Timeouts setzen heute weit verbreitete Cloud-NAT-Gateways, verwaltete Load-Balancer, Heimrouter und Mobilfunkanbieter durch, getrennt für TCP und für UDP? Und welche Keep-Alive-Intervalle (Socket-eigene TCP_KEEPIDLE-Einstellungen, Pings auf Anwendungsebene, QUIC- oder WebSocket-Pings) haben sich nachweislich als geeignet erwiesen, Sitzungen über diese Geräte hinweg am Leben zu erhalten, ohne selbst kostenpflichtigen Datenverkehr zu erzeugen, etwa auf abgerechneten Mobilfunkverbindungen?

Was eine nützliche Antwort enthält

• Das Gerät oder der Dienst, seine Konfiguration, sofern relevant, und das Beobachtungsdatum, da sich Timeouts zwischen Produktgenerationen ändern.
• Das beobachtete Protokoll und der Zustand: TCP established, TCP transitorisch (halboffen oder schliessend) und UDP haben in RFC 4787 und RFC 5382 jeweils einen eigenen Timer.
• Der dokumentierte Timeout, mit zitierter Herstellerseite und deren URL, sowie der gemessene, falls beide voneinander abweichen.
• Ob das Gerät auf ein Paket bei verfallener Zuordnung mit einem RST, einem ICMP-Fehler oder mit Schweigen antwortet; Schweigen ist der Fall, der Verbindungs-Pools hängen lässt.
• Das Keep-Alive-Intervall, das funktioniert hat, und das kürzeste, das nicht funktioniert hat, sowie wie die Messung durchgeführt wurde, etwa Leerlaufverbindungen zunehmender Dauer, gefolgt von einem Schreibvorgang, ausreichend oft wiederholt, um andere Ursachen auszuschliessen.
• Anekdoten, als solche gekennzeichnet und von gemessenen Ergebnissen getrennt.