Paquete de datos descartado en la conexión satelital

Tenemos varias PC integradas en granjas en el Reino Unido y los Estados Unidos. Entre otras conexiones, estas hablan con nuestro servidor enviando un pequeño paquete de datos (100 - 600 bytes) cada 20 segundos.

Sobre DSL esto está bien. Sobre conexiones satelitales, perdemos la mayoría de los paquetes.

Estamos usando TCP, y tcpdump en el cliente muestra la secuencia:

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

El servidor, sin embargo, ve:

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

Creo que estoy en lo cierto al decir que los puntos extra que recibe el cliente son falsificados por el punto final del satélite para acelerar la conexión

Tenemos ~ 100 sitios DSL y 3 satélites. Los DSL están bien, y los satélites están todos rotos de la misma manera.

¿Qué pasa con los datos? Se supera quizás una vez en 20.

editar Puedo hacer ping al servidor desde el cliente en cuestión. Todos los clientes tienen un túnel ssh inverso al servidor que funciona bien. Podemos ingresar y también descargar datos. Es solo esta carga la que tiene problemas.

Conexión DSL - exitosa

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

Conexión satelital - sin éxito

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

No hubo tráfico ICMP en ninguno de los casos.

tcp packet-loss

— Johan
fuente

¿Algo del tráfico llega a los servidores? es decir, hacerles ping?

— GerryEgan

Sí, puedo hacer ping al servidor desde el cliente en cuestión. Todos los clientes tienen un túnel ssh inverso al servidor, y esto está funcionando bien. Podemos ingresar y también descargar datos. Es solo esta carga que no funciona.

— Johan

Sería útil si tuviéramos dos pcaps de comparación de la misma máquina: A) a través de DSL y B) a través de satélite. La información en la pregunta no es suficiente para ayudar en el diagnóstico. Capture TCP e ICMP ... dénos un dropbox, google drive u otro enlace "en la nube" a los pcaps si es posible

— Mike Pennington

No tenemos máquinas con DSL y satélite. Puedo ejecutar tcpdump en dos máquinas separadas, una con DSL y la otra por satélite, ambas con el mismo software y hablando con el mismo servidor.

— Johan

¿Es esa la información que necesitabas? Acabo de ver su sugerencia de Dropbox, así que supongo que esperaba más datos ...

— Johan

Las marcas de tiempo en las entradas pcap de su satélite implican suplantación de reconocimiento de tcp. La mayoría de los dispositivos que realizan falsificaciones de acuse de recibo se pueden configurar para evitar la aceleración en función de alguna combinación de dirección IP de origen / destino, puerto de origen / destino; conceptos estándar de ACL. Esta podría ser una función que se puede configurar en los módems satelitales (o dispositivo cercano) en su ubicación de concentrador y radio.

Las soluciones de aceleración o optimización de área amplia también son comunes en tales arquitecturas de red. Una vez más, estas soluciones deberían proporcionar un método para evitar el tráfico que tiene problemas. Los dispositivos como Riverbed Steelhead, Cisco WAAS, Bluecoat y Citrix Cloudbridge / Wanscaler son ejemplos de tecnologías que pueden afectar su aplicación. Una discusión con su proveedor (o persona de la red) debe revelar si tales tecnologías están en uso en su red; si es así, solicite omitir el tráfico afectado en estos dispositivos para ver si cambia el comportamiento. La mejor de las suertes.

— paquete perdido
fuente

Esta es una buena teoría; La aceleración de WAN es una táctica común para tratar de frustrar las conexiones de alta latencia (satélite).

— Ryan Foley

Dado que el cliente estaba recibiendo reconocimientos que el servidor no enviaba, supuse que tenía que ser una suplantación de identidad. Sin embargo, ¿esto provocaría que se descartaran los paquetes?

— Johan

Johan, esto sería muy difícil de solucionar sin 1) información del encabezado tcp (los números de secuencia son importantes aquí) y 2) la cadena del equipo, incluidos los módems satelitales, los Proxies de mejora del rendimiento y / o el equipo de optimización WAN. Solo una idea aquí, dado que ssh no parece verse afectado, ¿ha pensado en tunelizar los datos de su aplicación personalizada a través de un túnel ssh?

— packetloss