Datenpaket bei Satellitenverbindung verworfen

8

Wir haben mehrere eingebettete PCs auf Farmen in Großbritannien und den USA. Unter anderem kommunizieren diese mit unserem Server und senden alle 20 Sekunden ein kleines Datenpaket (100 - 600 Byte).

Über DSL ist das in Ordnung. Über Satellitenverbindungen verlieren wir die meisten Pakete.

Wir verwenden TCP und tcpdump auf dem Client zeigt die Reihenfolge:

-> syn                   (send)
<- syn ack               (receive)
-> ack
-> push ack
<- ack                   (spoofed?)
-> fin ack
<- ack                   (spoofed?)
<- fin ack
-> ack

Der Server sieht jedoch:

<- syn                   (receive)
-> syn ack               (send)
<- ack
<- fin ack
-> fin ack
<- ack

Ich glaube, ich kann zu Recht sagen, dass die zusätzlichen Bestätigungen, die der Client erhält, vom Satellitenendpunkt gefälscht werden, um die Verbindung zu beschleunigen

Wir haben ~ 100 DSL-Standorte und 3 Satelliten. Die DSL sind alle in Ordnung und die Satelliten sind alle auf die gleiche Weise kaputt.

Was passiert mit den Daten? Es kommt vielleicht einmal in 20 durch.

bearbeiten Ich kann den Server vom betreffenden Client aus anpingen. Die Clients haben alle einen umgekehrten SSH-Tunnel zum Server, der einwandfrei funktioniert. Wir können ssh in und auch Daten herunterladen. Es ist nur dieser Upload, der Probleme hat.

DSL-Verbindung - erfolgreich

root@mini2440:~ tcpdump port 1080 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:55:20.126968 IP (tos 0x0, ttl 64, id 29228, offset 0, flags [DF], proto TCP (6), length 60)
    client > server: Flags [S], cksum 0x1877 (incorrect -> 0x5ebd), seq 21640692, win 14600, options [mss 1460,sackOK,TS val 1485260760 ecr 0,nop,wscale 1], length 0
14:55:20.194124 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    server > client: Flags [S.], cksum 0xf10a (correct), seq 4087778233, ack 21640693, win 14480, options [mss 1452,sackOK,TS val 43969567 ecr 1485260760,nop,wscale 4], length 0
14:55:20.194465 IP (tos 0x0, ttl 64, id 29229, offset 0, flags [DF], proto TCP (6), length 52)
    client > server: Flags [.], cksum 0x186f (incorrect -> 0x3bcb), seq 1, ack 1, win 7300, options [nop,nop,TS val 1485260773 ecr 43969567], length 0
14:55:20.197225 IP (tos 0x0, ttl 64, id 29230, offset 0, flags [DF], proto TCP (6), length 403)
    client > server: Flags [P.], cksum 0x39c5 (correct), seq 1:352, ack 1, win 7300, options [nop,nop,TS val 1485260774 ecr 43969567], length 351
14:55:20.197564 IP (tos 0x0, ttl 64, id 29231, offset 0, flags [DF], proto TCP (6), length 52)
    client > server: Flags [F.], cksum 0x186f (incorrect -> 0x3a6a), seq 352, ack 1, win 7300, options [nop,nop,TS val 1485260774 ecr 43969567], length 0
14:55:20.267543 IP (tos 0x0, ttl 52, id 26507, offset 0, flags [DF], proto TCP (6), length 52)
    server > client: Flags [.], cksum 0x530f (correct), seq 1, ack 352, win 972, options [nop,nop,TS val 43969587 ecr 1485260774], length 0
14:55:20.271456 IP (tos 0x0, ttl 52, id 26508, offset 0, flags [DF], proto TCP (6), length 52)
    server > client: Flags [F.], cksum 0x530d (correct), seq 1, ack 353, win 972, options [nop,nop,TS val 43969587 ecr 1485260774], length 0
14:55:20.271771 IP (tos 0x0, ttl 64, id 29232, offset 0, flags [DF], proto TCP (6), length 52)
    client > server: Flags [.], cksum 0x186f (incorrect -> 0x3a46), seq 353, ack 2, win 7300, options [nop,nop,TS val 1485260789 ecr 43969587], length 0
8 packets captured

Satellitenverbindung - nicht erfolgreich

root@mini2440:~ tcpdump port 1080 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:14:50.027783 IP (tos 0x0, ttl 64, id 13618, offset 0, flags [DF], proto TCP (6), length 60)
    client > server: Flags [S], cksum 0x1884 (incorrect -> 0x1b8a), seq 2040495825, win 14600, options [mss 1460,sackOK,TS val 16534499 ecr 0,nop,wscale 1], length 0
15:14:50.029731 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    server > client: Flags [S.], cksum 0x3451 (correct), seq 51102354, ack 2040495826, win 5792, options [mss 1460,sackOK,TS val 67452903 ecr 16534499,nop,wscale 7], length 0
15:14:50.034910 IP (tos 0x0, ttl 64, id 13619, offset 0, flags [DF], proto TCP (6), length 52)
    client > server: Flags [.], cksum 0x187c (incorrect -> 0x5d38), seq 1, ack 1, win 7300, options [nop,nop,TS val 16534500 ecr 67452903], length 0
15:14:50.036082 IP (tos 0x0, ttl 64, id 13620, offset 0, flags [DF], proto TCP (6), length 173)
    client > server: Flags [P.], cksum 0x8d87 (correct), seq 1:122, ack 1, win 7300, options [nop,nop,TS val 16534500 ecr 67452903], length 121
15:14:50.036351 IP (tos 0x0, ttl 64, id 13621, offset 0, flags [DF], proto TCP (6), length 52)
    client > server: Flags [F.], cksum 0x187c (incorrect -> 0x5cbe), seq 122, ack 1, win 7300, options [nop,nop,TS val 16534500 ecr 67452903], length 0
15:14:50.037547 IP (tos 0x0, ttl 63, id 64893, offset 0, flags [DF], proto TCP (6), length 52)
    server > client: Flags [.], cksum 0x790d (correct), seq 1, ack 122, win 46, options [nop,nop,TS val 67452911 ecr 16534500], length 0
15:14:50.076479 IP (tos 0x0, ttl 63, id 64894, offset 0, flags [DF], proto TCP (6), length 52)
    server > client: Flags [.], cksum 0x78e4 (correct), seq 1, ack 123, win 46, options [nop,nop,TS val 67452951 ecr 16534500], length 0
15:14:51.076273 IP (tos 0x0, ttl 63, id 64895, offset 0, flags [DF], proto TCP (6), length 52)
    server > client: Flags [F.], cksum 0x74e4 (correct), seq 1, ack 123, win 46, options [nop,nop,TS val 67453974 ecr 16534500], length 0
15:14:51.076482 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    client > server: Flags [.], cksum 0x57be (correct), seq 123, ack 2, win 7300, options [nop,nop,TS val 16534708 ecr 67453974], length 0
9 packets captured

In beiden Fällen gab es keinen ICMP-Verkehr.

tcp  packet-loss 
— Johan
quelle
Erreicht der Datenverkehr die Server? dh sie anpingen?
— GerryEgan
Ja, ich kann den Server vom betreffenden Client aus anpingen. Die Clients haben alle einen umgekehrten SSH-Tunnel zum Server, und dies funktioniert einwandfrei. Wir können ssh in und auch Daten herunterladen. Es ist nur dieser Upload, der nicht funktioniert.
— Johan
Es wäre hilfreich, wenn wir zwei Vergleichs-PCaps von derselben Maschine hätten: A) über DSL und B) über Satellit. Die Informationen in der Frage reichen nicht aus, um die Diagnose zu erleichtern. Bitte erfassen Sie sowohl TCP als auch ICMP ... geben Sie uns nach Möglichkeit eine Dropbox, ein Google Drive oder einen anderen "Cloud" -Link zu den PCaps
— Mike Pennington,
Wir haben keine Maschinen mit DSL und Satellit. Ich kann tcpdump auf zwei separaten Computern ausführen, einem mit DSL und dem anderen Satelliten, beide mit derselben Software und mit demselben Server.
— Johan
Sind das die Daten, die Sie brauchten? Ich habe gerade Ihren Dropbox-Vorschlag gesehen, also schätze ich, dass Sie mehr Daten erwartet haben ...
— Johan

Antworten:

2

Die Zeitstempel auf Ihren Satelliten-PCAP-Einträgen implizieren ein Spoofing der TCP-Bestätigung. Die meisten Geräte, die Bestätigungsspoofing durchführen, können so konfiguriert werden, dass die Beschleunigung basierend auf einer Kombination aus Quell- / Ziel-IP-Adresse, Quell- / Zielport umgangen wird. Standard-ACL-Konzepte. Dies kann eine Funktion sein, die in den Satellitenmodems (oder in einem nahe gelegenen Gerät) an Ihrem Hub und an den Speichenstandorten konfiguriert werden kann.

Weitbereichsoptimierungs- oder Beschleunigungslösungen sind in solchen Netzwerkarchitekturen ebenfalls üblich. Auch diese Lösungen sollten eine Methode bieten, um Ihren problematischen Datenverkehr zu umgehen. Geräte wie Riverbed Steelhead, Cisco WAAS, Bluecoat und Citrix Cloudbridge / Wanscaler sind Beispiele für Technologien, die sich auf Ihre Anwendung auswirken können. Eine Diskussion mit Ihrem Provider (oder Netzwerk-Typ) sollte zeigen, ob solche Technologien in Ihrem Netzwerk verwendet werden. Wenn ja, fordern Sie die Umgehung Ihres betroffenen Datenverkehrs auf diesen Geräten an, um festzustellen, ob sich das Verhalten ändert. Viel Glück.

— Paketverlust
quelle
Das ist eine gute Theorie; Die WAN-Beschleunigung ist eine gängige Taktik, um Verbindungen mit hoher Latenz (Satelliten) zu verhindern.
— Ryan Foley
Da der Client Probleme bekam, die der Server nicht sendete, ging ich davon aus, dass es sich um Spoofing handeln musste. Würde dies jedoch dazu führen, dass Pakete verworfen werden?
— Johan
Johan, dies wäre sehr schwer weiter zu beheben, ohne 1) TCP-Header-Informationen (Sequenznummern sind hier wichtig) und 2) den Geräte-String, einschließlich Satellitenmodems, Performance Enhancing Proxies und / oder WAN-Optimierungsausrüstung. Nur ein Gedanke hier, da ssh nicht betroffen zu sein scheint. Haben Sie darüber nachgedacht, Ihre benutzerdefinierten Anwendungsdaten durch einen ssh-Tunnel zu tunneln?
— Paketverlust
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.