TCP keep-alive wird nach TCP zero-window eingebunden und schließt die Verbindung irrtümlicherweise

Question

Wir sehen, dass dieses Muster zwischen zwei RHEL 6-Boxen passiert, die Daten über eine TCP-Verbindung übertragen. Der Client gibt ein TCP Window Full aus, 0.2 Sekunden später sendet der Client TCP Keepalives, auf die der Server mit ähnlich aussehenden Antworten reagiert. Der Client ist jedoch nicht zufrieden damit und sendet weiterhin TCP-Keepalives, bis er schließlich die Verbindung mit einem RST fast 9s später schließt.

Dies ist trotz der RHEL-Boxen die configuratation Standard-TCP-Keep-Alive mit

net.ipv4.tcp_keepalive_time = 7200 
net.ipv4.tcp_keepalive_probes = 9 
net.ipv4.tcp_keepalive_intvl = 75 

die, dass dies erklärt nur bis 2 Stunden der Stille auftreten sollte. Liest ich meinen PCAP falsch (relevante Pakete auf Anfrage)?

Unten ist Wireshark sreenshot des Musters, mit meinen eigenen Päckchen Notizen in der Mitte.

M.

Answer 1

Die Quell- und Ziel-IP-Adressen in den Paketen vom Client stamm nicht die Ziel- und Quell-IP-Adressen in den Antwortpaketen entsprechen, die, dass es anzeigt, einige Geräte zwischen die Boxen machen NAT. Es ist auch wichtig zu verstehen, wo die Pakete erfasst wurden. Wahrscheinlich hilft eine Paketerfassung auf dem Client selbst, das Problem zu verstehen.

Bitte beachten Sie, dass der Client TCP Keepalive generieren kann, wenn er zwei Stunden oder länger kein Datenpaket empfängt. Gemäß RFC 1122 versucht der Client Keepalive, wenn er keine Keepalive-Response vom Peer erhält. Es trennt sich schließlich nach einem fortlaufenden Wiederholungsfehler.

Die NAT-Geräte implementieren in der Regel Verbindungs-Caches, um den Status der laufenden Verbindungen beizubehalten. Wenn die Größe der Verbindung das Limit erreicht, löschen die NAT-Geräte alte Verbindungen, um die neuen Verbindungen zu bedienen. Dies könnte auch zu einem solchen Szenario führen.

Die angegebene Paketerfassung zeigt an, dass eine hohe Wahrscheinlichkeit besteht, dass Pakete den Client nicht erreichen. Daher ist es hilfreich, Pakete auf dem Clientcomputer zu erfassen.

Answer 2

las ich die Spur etwas anders: Sender mehr Daten senden als Empfänger verarbeiten kann und bekommen zerowindow Antwort Sender Fenster Sonden senden (nicht Keep Alive es Weg ist, bald dafür) und die Anwendung mit nicht nach 10 Sekunden aufgibt Fortschritt und schließt die Verbindung, der Reset zeigt an, dass im TCP-Sendepuffer Daten anstehen. Wenn die Anwendung eine große Blockgröße in den Socket schreibt, hat sie möglicherweise für mehr als die 10 Sekunden im tcpdump keinen Fortschritt gesehen.

Wenn dies eine gerade Verbindung ist (keine Proxies etc.) der wahrscheinlichste Grund ist, dass die Aufnahme auf Aufnahmestoppers (oder langsamer ist als die Absender & Datenübertragung)

Answer 3

Es scheint mir, wie Paketnummer 249522 provoziert die Anwendung auf 10.120.67.113, um die Verbindung abzubrechen. Alle Fenster-Probes erhalten eine Null-Fenster-Antwort von 0,132 (ohne Nutzlast) und dann sendet 0,12 (unaufgefordert) Paket 249522 mit 63 Bytes (und zeigt immer noch 0 Fenster an). Das PSH-Flag schlägt vor, dass diese 63 Bytes die gesamten Daten sind, die von der App auf .132 geschrieben werden. Dann antwortet .113 in derselben Millisekunde mit einer RST. Ich kann mir keinen Grund vorstellen, warum der TCP-Stack sofort nach dem Empfang von Daten eine RST senden würde (Sequenznummern sind korrekt). Meiner Ansicht nach ist es fast sicher, dass die App auf .113 basierend auf der 63-Byte-Nachricht von.132.