Pacote de dados descartados na conexão via satélite

Temos vários PCs incorporados em fazendas no Reino Unido e nos EUA. Entre outras conexões, eles conversam com o nosso servidor enviando um pequeno pacote de dados (100 - 600 bytes) a cada 20 segundos.

Sobre DSL, tudo bem. Em conexões via satélite, perdemos a maioria dos pacotes.

Estamos usando o TCP e o tcpdump no cliente mostra a sequência:

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

O servidor, no entanto, vê:

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

Acho que estou certo ao dizer que as contas extras que o cliente recebe são falsificadas pelo ponto final do satélite para acelerar a conexão

Temos ~ 100 sites DSL e 3 satélites. O DSL está bem, e os satélites estão quebrados da mesma maneira.

O que está acontecendo com os dados? Talvez supere uma vez em 20.

editar Posso executar ping no servidor do cliente em questão. Todos os clientes têm um túnel ssh reverso para o servidor, que está funcionando bem. Podemos fazer o ssh e também baixar dados. É apenas esse upload que tem problemas.

Conexão DSL - bem-sucedida

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

Conexão via satélite - sem ê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

Não havia tráfego ICMP em nenhum dos casos.

tcp packet-loss

— Johan
fonte

Algum tráfego chega aos servidores? ie pingando eles?

— 21814 GerryEgan #

Sim, posso executar ping no servidor do cliente em questão. Todos os clientes têm um túnel ssh reverso para o servidor, e isso está funcionando bem. Podemos fazer o ssh e também baixar dados. É apenas esse upload que não funciona.

— 13134 Johan Johan

Ajudaria se tivéssemos dois pcaps de comparação da mesma máquina: A) através do DSL e B) através do satélite. As informações na pergunta não são suficientes para ajudar no diagnóstico. Por favor capturar TCP e ICMP ... dar-nos uma caixa de depósito, o Google Drive ou outro link "nuvem" para os pcaps se possível

— Mike Pennington

Não temos máquinas com DSL e satélite. Posso executar o tcpdump em duas máquinas separadas, uma com DSL e o outro satélite, ambas com o mesmo software e conversando com o mesmo servidor.

— 13742 Johan Johan

Esses são os dados que você precisava? Eu só vi a sua sugestão dropbox, então eu estou supondo que você espera mais dados ...

— Johan

Os registros de data e hora nas entradas do satélite pcap implicam falsificação de reconhecimento tcp. A maioria dos dispositivos que executam falsificação de reconhecimento pode ser configurada para ignorar a aceleração com base em alguma combinação de endereço IP de origem / destino, porta de origem / destino; conceitos padrão da ACL. Esse pode ser um recurso configurável nos modems por satélite (ou dispositivo próximo) no seu hub e locaitons spoke.

Soluções de otimização de área ampla ou aceleração também são comuns nessas arquiteturas de rede. Novamente, essas soluções devem fornecer um método para contornar o tráfego que está tendo problemas. Dispositivos como Riverbed Steelhead, Cisco WAAS, Bluecoat e Citrix Cloudbridge / Wanscaler são exemplos de tecnologias que podem impactar seu aplicativo. Uma discussão com seu provedor (ou funcionário da rede) deve revelar se essas tecnologias estão em uso na sua rede; Nesse caso, solicite o desvio do tráfego afetado nesses dispositivos para ver se o comportamento muda. Boa sorte.

— perda de pacotes
fonte

Esta é uma boa teoria; A aceleração da WAN é uma tática comum na tentativa de impedir conexões de alta latência (satélite).

— Ryan Foley

Dado que o cliente estava recebendo acusações que o servidor não estava enviando, presumi que fosse uma falsificação. Isso faria com que os pacotes fossem descartados, no entanto?

— Johan

Johan, isso seria muito difícil de solucionar problemas ainda sem 1) informações do cabeçalho tcp (os números de sequência são importantes aqui) e 2) a cadeia de equipamentos, incluindo modems por satélite, proxies de aprimoramento de desempenho e / ou equipamentos de otimização de WAN. Apenas um pensamento aqui, dado que o ssh não parece ser afetado, você pensou em encapsular seus dados de aplicativos personalizados através de um túnel ssh?

— packetloss