[rubber]

Ok, jetzt wirds richtig übel?!?

Die TCP-Sessions werden nach recht kurzer IDLE Zeit zurück gesetzt. Hat man zum Beispiel eine SSH-Session auf, so wird die nach kurzer Zeit beendet. Ok, gerade bei SSH kann man ein KeepAlive einbauen aber ich befürchte, das dies nicht bei jedem Protokoll einfach umzusetzen ist.

[Michael712]

Hallo,

das sollte nur bei IPv4 so sein, bei IPv6 bleibt die Verbindung immer offen (12h SSH ist kein Problem).
Der Effekt sollte bei dir auch nur bei Verwendung von NAT (also bei IPv4) auftreten, da ja dort nur begrenzt Ports zur Verfügung stehen und diese dann bei scheinbar beendeter Sitzung (auf Anbieterseite) getrennt werden. Selbst eine FritzBox macht diese Trennung.

Da man hier das NAT auf Anbieterseite hat, ist eine direkt Beeinflussung der Timeouts leider nicht möglich.
Man kann jedoch auf Clientseite keep-alive in TCP aktivieren. Kurze Anleitung für Windows/Linux und Hintergrund dazu.
Dafür muss deine Anwendung auch nichts können, da das auf Transportebene (OSI 4) läuft.


Viele Grüße
Michael

[rubber]

(22.07.2014, 18:05)Michael712 schrieb:  Hallo,

das sollte nur bei IPv4 so sein, bei IPv6 bleibt die Verbindung immer offen (12h SSH ist kein Problem).
Der Effekt sollte bei dir auch nur bei Verwendung von NAT (also bei IPv4) auftreten, da ja dort nur begrenzt Ports zur Verfügung stehen und diese dann bei scheinbar beendeter Sitzung (auf Anbieterseite) getrennt werden. Selbst eine FritzBox macht diese Trennung.

Da man hier das NAT auf Anbieterseite hat, ist eine direkt Beeinflussung der Timeouts leider nicht möglich.
Man kann jedoch auf Clientseite keep-alive in TCP aktivieren. Kurze Anleitung für Windows/Linux und Hintergrund dazu.
Dafür muss deine Anwendung auch nichts können, da das auf Transportebene (OSI 4) läuft.


Viele Grüße
Michael

Hallo Michael,

ich weiss, das diese Trennung bei NAT notwendig ist, doch ich bin einigermassen verwundert über die doch recht kurze Timeout Zeit.

Gruss
rubber

[admin]

oh, das ist interessant - ich habe das hier auch immer:

ssh Sitzung .. dann nach relativ kurzer Zeit "Write failed: Broken pipe".

Ich bin aber bislang nie auf die Idee gekommen, dass das mit dem neuen Anschluss zusammenhängt. Ich war eigentlich davon ausgegangen, dass die eine fehlerhafte oder zu kleine KeepAlive Einstellung von meinem ssh hier ist.

Mit einer Trennung oder Neu-Port-Belegung bei C-NAT bringe ich das aber auch noch nicht in Verbindung.

Ich konfiguriere mein SSH mal ordentlich und teste das auch noch mal hier

-Elmar

[rubber]

In der Vergangenheit (und auch jetzt) war ich über IPv4 von den verschiedensten Stellen natürlich auch über diverse NAT-Router verbunden. Dort hatte ich bisher allerdings nie besondere Keep-Alive Einstellungen gebraucht um die SSH-Tunnel aufrecht erhalten zu können. Na klar, nach der Zwangstrennung war die Verbindung weg, aber im Allgemeinen hielten die Sitzungen über Stunden und dabei auch über lange Zeiten ohne Ein- und Ausgaben.
Das die CGNAT-Appliances jetzt so massiv schnell die TCP-Sessions schliessen, kann ich theoretisch nachvollziehen, finde es allerdings im Moment noch etwas übertrieben. Vielleicht ist es ja auch gar nicht die CGNAT-Appliance sondern doch noch eine Einstellung des "Routers" die wir vermutlich aber auch nicht konfigurieren können.
Ok, ok, eine NAT-Anbindung mit ein paar hundert Clients an einem CompanyConnect ist nicht das gleiche wie ein CGNAT für das gesamt DGF-Netz mit mehreren zig tausend Clients, aber ich bin mir unsicher, ob das wirklich so sein muss?!

[rubber]

Ich habe jetzt ohne Veränderung der SSH-Parameter mehrere Sessions per IPv6 (also OHNE CGNAT) und per IPv4 zu den gleichen Servern laufen lassen: KEIN Abbruch unter IPv6 und sehr wohl unter IPv4! Damit ist zu mindestens für mich der "Beweis" erbracht das es am CGNAT liegt. Meines Erachtens sollte die DeutscheGlasfaser da Ihre CGNAT-Devices noch ein wenig nach justieren!

[2fast]

Hast du mal versucht im Putty den keepalive zu setzen?

http://www.nth-design.com/2010/05/10/using-keepalive-in-putty/

[rubber]

Das funktioniert natürlich, stellt aber meines Erachtens nur eine Umgehungslösung dar.