Paquet de données abandonné sur la connexion satellite

8

Nous avons plusieurs PC intégrés dans des fermes au Royaume-Uni et aux États-Unis. Entre autres connexions, celles-ci parlent à notre serveur en envoyant un petit paquet de données (100 - 600 octets) toutes les 20 secondes.

Sur DSL, c'est très bien. Sur les connexions par satellite, nous perdons la plupart des paquets.

Nous utilisons TCP, et tcpdump sur le client affiche la séquence:

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

Le serveur voit cependant:

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

Je pense avoir raison de dire que les accusés de réception supplémentaires que le client reçoit sont usurpés par le point d'extrémité du satellite afin d'accélérer la connexion

Nous avons ~ 100 sites DSL et 3 satellites. La DSL va bien et les satellites sont tous cassés de la même manière.

Qu'arrive-t-il aux données? Il passe peut-être une fois sur 20.

modifier Je peux envoyer une requête ping au serveur à partir du client en question. Les clients ont tous un tunnel ssh inverse vers le serveur qui fonctionne bien. Nous pouvons entrer et télécharger des données. C'est juste ce téléchargement qui a des problèmes.

Connexion DSL - réussie

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

Connexion satellite - échec

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

Il n'y avait aucun trafic ICMP dans les deux cas.

tcp  packet-loss 
— Johan
source
Une partie du trafic atteint-elle les serveurs? c'est-à-dire les cingler?
— GerryEgan
Oui, je peux envoyer une requête ping au serveur à partir du client en question. Les clients ont tous un tunnel ssh inverse vers le serveur, et cela fonctionne très bien. Nous pouvons entrer et télécharger des données. C'est juste ce téléchargement qui ne fonctionne pas.
— Johan
Cela aiderait si nous avions deux PCAP de comparaison provenant de la même machine: A) sur DSL et B) sur satellite. Les informations contenues dans la question ne sont pas suffisantes pour aider au diagnostic. Veuillez capturer TCP et ICMP ... donnez-nous un dropbox, un lecteur Google ou un autre lien "cloud" vers les pcaps si possible
— Mike Pennington
Nous n'avons pas de machines avec DSL et satellite. Je peux exécuter tcpdump sur deux machines distinctes, une avec DSL et l'autre satellite, toutes deux avec le même logiciel et parlant au même serveur.
— Johan
Est-ce les données dont vous aviez besoin? Je viens de voir votre suggestion de boîte de dépôt, donc je suppose que vous vous attendiez à plus de données ...
— Johan

Réponses:

2

Les horodatages sur vos entrées de PCAP satellite impliquent une usurpation de l'accusé de réception TCP. La plupart des appareils qui effectuent une usurpation d’accusé de réception peuvent être configurés pour contourner l’accélération en fonction d’une combinaison d’adresse IP source / destination, de port source / destination; concepts ACL standard. Cela pourrait être une fonctionnalité configurable dans les modems satellites (ou les appareils à proximité) de votre hub et locaitons de rayons.

Les solutions d'optimisation ou d'accélération étendues sont également courantes dans de telles architectures de réseau. Encore une fois, ces solutions devraient fournir une méthode pour contourner votre trafic qui rencontre des problèmes. Des appareils tels que Riverbed Steelhead, Cisco WAAS, Bluecoat et Citrix Cloudbridge / Wanscaler sont des exemples de technologies susceptibles d'avoir un impact sur votre application. Une discussion avec votre fournisseur (ou un responsable du réseau) devrait révéler si de telles technologies sont utilisées sur votre réseau; si c'est le cas, demandez à contourner le trafic affecté sur ces appareils pour voir si le comportement change. Bonne chance.

— perte de paquets
source
Ceci est une bonne théorie; L'accélération WAN est une tactique courante pour tenter de contrecarrer les connexions à haute latence (satellite).
— Ryan Foley
Étant donné que le client recevait des accusés de réception que le serveur n'envoyait pas, j'ai supposé qu'il devait être usurpé. Cela entraînerait-il cependant la suppression des paquets?
— Johan
Johan, il serait très difficile de dépanner davantage sans 1) les informations d'en-tête TCP (les numéros de séquence sont importants ici) et 2) la chaîne d'équipement, y compris les modems satellites, les proxys améliorant les performances et / ou l'équipement d'optimisation WAN. Juste une pensée ici, étant donné que ssh ne semble pas être affecté, avez-vous pensé à tunnelliser vos données d'application personnalisées via un tunnel ssh?
— packetloss
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.