Der Server antwortet mit Verzögerung auf TCP-SYN-Pakete

Ich habe die folgende Netzwerktopologie:

Wenn Arbeitsstation eine Verbindung herstellt zu HTTPS Server - Server , dann in der Regel - Server sendet SYN + ACK - Paket mit 60 Sekunden Verzögerung ~. Die Paketerfassung vom Server ist unten zu sehen:

10:15:21.310878 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503046494 0,nop,wscale 7>
10:15:23.102826 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503046942 0,nop,wscale 7>
10:15:23.326801 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503046998 0,nop,wscale 7>
10:15:27.230802 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503047974 0,nop,wscale 7>
10:15:27.486804 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503048038 0,nop,wscale 7>
10:15:35.422853 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503050022 0,nop,wscale 7>
10:15:35.678797 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503050086 0,nop,wscale 7>
10:15:51.550815 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503054054 0,nop,wscale 7>
10:15:51.806784 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503054118 0,nop,wscale 7>
10:16:24.062769 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503062182 0,nop,wscale 7>
10:16:24.062832 00:11:25:8c:7a:1a > 1c:87:2c:5a:43:e2, ethertype IPv4 (0x0800), length 74: 10.10.10.16.443 > 10.10.10.160.38256: S 561747608:561747608(0) ack 3411497796 win 5792 <mss 1460,sackOK,timestamp 3558683637 2503062182,nop,wscale 2>
10:16:24.062843 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503062182 0,nop,wscale 7>
10:16:24.062860 00:11:25:8c:7a:1a > 1c:87:2c:5a:43:e2, ethertype IPv4 (0x0800), length 74: 10.10.10.16.443 > 10.10.10.160.38244: S 562554685:562554685(0) ack 3008273870 win 5792 <mss 1460,sackOK,timestamp 3558683637 2503062182,nop,wscale 2>
10:16:24.063075 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 66: 10.10.10.160.38256 > 10.10.10.16.443: . ack 1 win 229 <nop,nop,timestamp 2503062182 3558683637>
10:16:24.063116 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 66: 10.10.10.160.38244 > 10.10.10.16.443: . ack 1 win 229 <nop,nop,timestamp 2503062182 3558683637>

Um ARP-bezogene Probleme auszuschließen, habe ich den statischen ARP-Eintrag für die Workstation auf dem Server installiert :

# ip neigh show 10.10.10.160                               
10.10.10.160 dev eth0 lladdr 1c:87:2c:5a:43:e2 PERMANENT                      
#

Zu guter Letzt kann ich jederzeit 10.10.10.160 vom 10.10.10.16 anpingen. Zum Beispiel war ich den ganzen Tag while :; do ping -c 1 -I 10.10.10.16 10.10.10.160 &>/dev/null || date; sleep 2; doneauf dem Server und kein einziger Ping ist fehlgeschlagen.

Wenn ich schließlich das vom Client gesendete TCP-SYN-Paket mit 10:15:51.806784(empfange kein SYN + ACK vom Server ) mit 10:16:24.062769(empfange SYN + ACK vom Server ) in Wireshark vergleiche, sind sie mit Ausnahme der Prüfsummen identisch.

Außerdem ist die serverseitige Firewall so konfiguriert, dass die erste Regel der INPUT- Kette TCP-SYN-Pakete vom 10.10.10.160 ( iptables -I INPUT -s 10.10.10.160 -d 10.10.10.16 -p tcp --syn --dport 443 -j LOG) protokolliert und die zweite Regel den gesamten Datenverkehr vom 10.10.10.160 akzeptiert. Beispielsweise werden folgende Zeilen im Kernel-Ringpuffer protokolliert:

IN=eth0 OUT= MAC=00:11:25:8c:7a:1a:00:19:e2:9e:df:f0:08:00 SRC=10.10.10.160 DST=10.10.10.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=65477 DF PROTO=TCP SPT=40066 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0

Wie ich bereits sagte, werden sie in der nächsten Regel akzeptiert. Dies sollte alle tc/ netfilterverwandte Probleme ausschließen.

Andere Clients (z. B. 10.10.10.170) funktionieren einwandfrei.

Was könnte ein solches Verhalten verursachen?

tcp

— Martin
quelle

Ich weiß nicht, ob es zutrifft, aber Sie könnten hier und hier nach möglichen Hinweisen suchen .

— Meuh

@meuh Danke für die zwei guten Artikel! Der erste scheint für mich nicht zutreffend zu sein, da meine SYN-Warteschlangengröße ( /proc/sys/net/ipv4/tcp_max_syn_backlog) 1024 beträgt, was weitaus größer ist als die Verbindungen im Status SYN RECEIVED. Darüber hinaus scheint das Problem nur bei diesem einen Client zu liegen. Der zweite Artikel scheint auch nicht zuzutreffen, da dies meines TIME-WAITWissens nur Verbindungen betrifft, die den TCP-Drei-Wege-Handshake bestanden haben. In meinem Fall antwortet der Server mit einer Verzögerung von einer Minute auf die ersten SYN-Pakete.

— Martin

Wird jede Paketantwort für diese Workstation um 60 Sekunden verzögert oder tritt das Problem nur für das ursprüngliche SYN + ACK-Paket auf?

— Roaima

Wie sieht der Datenverkehr auf der Serverseite aus ?

— Andrew Henle

Nur das SYN + ACK-Paket des anfänglichen TCP-Drei-Wege-Handshakes wird um ~ 60 Sekunden verzögert. @ AndrewHenle Die Paketerfassung in meinem ersten Beitrag erfolgt von der Serverseite . Auf der Clientseite kann ich TCP-SYN-Pakete vom 10.10.10.160: <ephemeral_port_nr> bis 10.10.10.16:443 sehen. Normalerweise wird ein Dutzend Versuche und dann der TCP + SYN vom Server empfangen und ab diesem Zeitpunkt funktioniert alles normal.

— Martin

Ich sehe hier ein großes Problem: Die Antworten von Ihrem Server gehen nicht denselben Weg wie die Pakete, die an ihn gesendet werden.

Ihre Workstation verwendet Ihren Router 10.10.10.190, um den Server über die Adresse 10.10.10.16/32 (/ 32? In Ihrer Zeichnung steht auch / 28) zu erreichen, anstatt die Adresse 10.10.10.148 zu verwenden, die sich im selben LAN-Segment wie der WS befindet .

Die TCP-Pakete, die vom Server zum WS gesendet werden, verwenden den Router jedoch nicht, da der Server den WS direkt erreichen kann.

Warum spielt es eine Rolle?

Die Folge ist, dass Ihr Router die Antworten von Ihrem Server nicht sieht und eine falsche Vorstellung vom Verbindungsstatus hat (obwohl der Server mit SYN + ACK geantwortet hat, befindet sich der Verbindungsstatus aus Sicht des Routers immer noch im anfänglichen SYN).

Wie die meisten heutigen Router blockiert es wahrscheinlich alle nachfolgenden TCP-Pakete, die vom WS zum Server gesendet werden, bis SYN + ACK vom Server erkannt wird (dies wird nicht passieren).

Daher besteht Ihr eigentliches Problem wahrscheinlich nicht darin, dass Ihr Server 60 Sekunden wartet, bevor er diese SYN + ACK sendet, sondern dass Ihr Router den TCP-Verkehr von Ihrem WS zum Server nach der anfänglichen SYN blockiert.

Warum dann diese Verkehrsmüllkippe?

Wenn meine Theorie richtig ist, täuscht der Verkehrsdump, den Sie in Ihrer Frage gepostet haben, weil wir nicht den vollständigen Dump haben:

Der Server antwortet nicht auf SYN-Anforderungen, da er bereits auf die erste Antwort geantwortet hat und diese als Duplikate betrachtet werden
Was Sie um 10: 16: 24.062769 und um 10: 16: 24.062860 sehen, ist wahrscheinlich, dass der Server seine SYN + ACK-Antwort nach einer bestimmten Verzögerung erneut sendet, ohne etwas vom WS zu erhalten

Wie kann man das beheben?

Sie haben mehrere Möglichkeiten:

Erreichen Sie den Server direkt über seine 10.10.10.148 IP-Adresse (eigentlich kein Fix)
Entfernen Sie diese 10.10.10.148 IP-Adresse vom Server (keine Option, denke ich)
Deaktivieren Sie die Verbindungsverfolgung der Firewall auf dem Router (keine Option, denke ich, und sowieso nicht wünschenswert).
Geben Sie die MAC-Adresse des Routers 00: 19: e2: 9e: df: f0 in die ARP-Tabelle des Servers für 10.10.10.160 ein (ein hässlicher Hack IMHO, und Sie werden ein anderes ähnliches Problem haben, wenn Sie den Server direkt über seine IP 10.10.10.148 erreichen Adresse, da die SYN-Pakete den Router nicht verwenden, die Antworten des Servers jedoch)
Verwenden Sie das quellenbasierte Routing (Richtlinienrouting), um den Server anzuweisen, den Router zu verwenden, wenn die Quelladresse der ausgehenden Pakete 10.10.10.16 ist, unabhängig von der Zieladresse

Natürlich werden die Optionen angegeben, die eigentlich keine echten Optionen sind, damit Sie meine Theorie experimentieren und validieren können. Quellbasiertes Routing ist das, was Sie tun sollten.

— xhienne
quelle

Gut möglich. Was in der ursprünglichen Frage besonders fehlt, ist, wie der Netzwerkverkehr vom Server aussieht .

— Andrew Henle

@ AndrewHenle Du meinst wahrscheinlich von der Workstation (ich stimme zu)? Der Netzwerkverkehr in der Frage wurde auf dem Server ausgegeben.

— Xhienne

@xhienne Zunächst einmal sind Sie richtig - der Verkehr in der Frage wurde auf dem Server ausgegeben . In Bezug auf den asymmetrischen Pfad sollte dies kein Problem sein, da dieser Router keine Stateful Firewalling ausführt und die TCP-Header nicht überprüfen sollte. Darüber hinaus 10.10.10.170funktioniert es für andere Kunden wie gut. Was ist noch seltsamer ist , dass , wenn ich ausführen send(IP(dst="10.10.10.16", src="10.10.10.160")/TCP(dport=443, flags="S"), count=20)in scapydieser problematischen Workstation , dann kann ich von dem Server sehen , dass alle 20 SYN - Pakete sofort SYN + ACK als Antwort bekommen.

— Martin

Es gibt eine andere Möglichkeit, dies zu testen, die nicht vollständig gleichwertig ist. @Martin protokolliert bereits eingehende Pakete von der Workstation auf dem Server. Er kann auch ausgehende Pakete auf der Workstation protokollieren und die Zeitstempel überprüfen. Dies würde zeigen, ob die Verzögerung vom Server oder vom Router ausgeht.

— Marius Matutiae