Eure Settings bzgl. TCP-Aging

[MDCYP]

Hi,

wollte mal fragen ob ihr auch das TCP Aging erhöht habt? Default ist ja 300sek - gibts ja manchmal Probleme mit SSH Timeouts.

Habt ihr das erhöht? Frage mich, ob es Probleme gibt wenn man z.B. den Wert auf 3000 erhöht? Gibts da einen Überlauf oder so ?

[backslash]

Hi MDCYP,

Habt ihr das erhöht?

nein, wieso... i.A. macht das keine Probleme - und wenn du SSH-Abbrüche hast: Putty z.B. kann Keep-Alives senden...

Frage mich, ob es Probleme gibt wenn man z.B. den Wert auf 3000 erhöht? Gibts da einen Überlauf oder so ?

Wenn alle TCP-Sessions sich sauber abbauen - nein... Wenn du aber einen bösartigen User im Netz hast, dann kann er dir mit TCP-Sessions, die er absichtlich nicht schließt, die Maskierungstabelle füllen... Und natürlich belegt jede Session in der Firewall einen Eintrag und somit weiteren Speicher, der somit irgendwann kanpp werden könnte...

Gruß
Backslash

[Dr.Einstein]

TCP meist auf 3600s und UDP ganz selten bei Bedarf auf 600s erhöht. In der Regel zu viel altes Zeugs unterwegs, was kein Keep Alive macht.

Gruß Dr.Einstein

[GrandDixence]

gibts ja manchmal Probleme mit SSH Timeouts.

Dagegen hilft SSH Keep Alive:
https://patrickmn.com/aside/how-to-keep ... -sessions/

[MDCYP]

Ja, das stimmt. Aber bei Datenbank Verbindungen gibts sowas z.B. nicht - jedenfalls bei Informix.

Aber ok, dann fahren wir ja mit 3000 noch ganz gut. Danke für die Info

[backslash]

Hi MDCYP

Aber bei Datenbank Verbindungen gibts sowas z.B. nicht - jedenfalls bei Informix.

dann wende dich doch mal an Informix und fordere das ein... NAT und damit Session-Timeouts in Routern ist nunmal nicht gerade selten in dieser Welt...

Gruß
Backslash

[失败是成功之母]

Also ich verwende den Wert aus RFC 5382, das sind 7440 Sekunden.

In jener RFC steht auch warum: TCP hat (für erfolgreich aufgebaute Verbindungen) ein eingebautes Keep-Alive. Und dieses Keep-Alive hat den Standard-Wert von zwei Stunden (7200 Sekunden). Um Verzögerungen abzufangen, kommt die RFC dann am Ende auf 7440 Sekunden.

Konkurrenz-Hersteller wie DrayTek haben als Standard-Wert sogar einen ganzen Tag. Die „Konkurrenz“ AVM macht immerhin ganze 15 Minuten. Aber auch das ist kritisch, weil bereits IMAP-IDLE aus dem 1997 als Timeout mindestens 29 Minuten kannte. Lancoms 5 Minuten sind auch deshalb so problematisch, weil Mobil-Betriebssysteme wie Apple iOS jene Apps aus dem Hintergrund wirft, die zu oft aktualisieren. Angeblich alles unter 10 Minuten bei Aktualisierungen auf Application-Layer. Ob man als App den TCP-Keep-Alive beeinflussen und auf weniger als 5 Minuten setzen kann und ob das vermeidet als App aus dem Arbeitsspeicher gelöscht zu werden – ich weiß es nicht.

Wenn Deine Anwendung selbst kein Keep-Alive innerhalb von 5 Minuten macht/erlaubt, in Desktop-Betriebssysteme kannst Du das Intervall für das TCP-Keep-Alive systemweit heruntersetzen, z.B. in Linux: sudo sysctl -w net.ipv4.tcp_keepalive_time=295. Windows: KeepAliveTime. Apple macOS: keepidle.

Ob das für alle Systeme bei Euren Kunden sinnvoll ist … ich weiß es nicht. Ich habe hier nur Low-Load-Systeme. Auch fand die keine Dokumentation, wieviele Sessions ein aktueller Lancom Business-Router überhaupt bzw. ob er die möglichen Zustände einer TCP-Verbindung (noch nicht aufgebaut, aufgebaut, …) erkennt bzw. gesondert behandelt. Aber selbst wenn, DrayTek kann das unterscheiden und macht trotzdem noch eine eigene Warteschlange für HTTP-Verbindungen.