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.
la source
Réponses:
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.
la source