Pacchetto di dati abbandonato sulla connessione satellitare

Abbiamo diversi PC incorporati nelle fattorie nel Regno Unito e negli Stati Uniti. Tra le altre connessioni, queste parlano al nostro server inviando un piccolo pacchetto di dati (100 - 600 byte) ogni 20 secondi.

Su DSL va bene. Su connessioni satellitari, perdiamo la maggior parte dei pacchetti.

Stiamo usando TCP e tcpdump sul client mostra la sequenza:

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

Il server, tuttavia, vede:

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

Penso di essere corretto nel dire che gli accessi extra che il client riceve sono falsificati dall'endpoint satellitare al fine di accelerare la connessione

Abbiamo ~ 100 siti DSL e 3 satelliti. Il DSL sta bene e i satelliti sono tutti rotti allo stesso modo.

Cosa sta succedendo ai dati? Passa forse una volta su 20.

modifica Posso eseguire il ping del server dal client in questione. Tutti i client dispongono di un tunnel SSH inverso al server che funziona correttamente. Possiamo inviare e anche scaricare dati. È solo questo upload che ha problemi.

Connessione DSL - riuscita

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

Connessione satellitare - non riuscita

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

Non c'era traffico ICMP in entrambi i casi.

tcp packet-loss

— Johan
fonte

C'è del traffico che raggiunge i server? cioè il ping?

— GerryEgan,

Sì, posso eseguire il ping del server dal client in questione. Tutti i client hanno un tunnel SSH inverso al server e questo funziona bene. Possiamo inviare e anche scaricare dati. È solo questo upload che non funziona.

— Johan,

Sarebbe d'aiuto se avessimo due pcap comparativi dalla stessa macchina: A) su DSL e B) su satellite. Le informazioni nella domanda non sono sufficienti per aiutare nella diagnosi. Acquisisci sia TCP che ICMP ... forniscici un dropbox, google drive o altri link "cloud" ai pcaps, se possibile

— Mike Pennington,

Non abbiamo macchine con DSL e satellite. Posso eseguire tcpdump su due macchine separate, una con DSL e l'altra via satellite, entrambe con lo stesso software e parlando con lo stesso server.

— Johan,

Sono i dati di cui hai bisogno? Ho appena visto il tuo suggerimento su Dropbox, quindi immagino che ti aspettassi ulteriori dati ...

— Johan,

I timestamp sulle voci del pcap satellitare implicano lo spoofing del riconoscimento tcp. La maggior parte dei dispositivi che eseguono lo spoofing di riconoscimento possono essere configurati per bypassare l'accelerazione in base a una combinazione di indirizzo IP di origine / destinazione, porta di origine / destinazione; concetti ACL standard. Questa potrebbe essere una funzione configurabile nei modem satellitari (o nei dispositivi vicini) nell'hub e nelle locazioni dei raggi.

In tali architetture di rete sono comuni anche soluzioni di ottimizzazione o accelerazione su vasta area. Ancora una volta, queste soluzioni dovrebbero fornire un metodo per aggirare il tuo traffico che sta avendo problemi. Dispositivi come Riverbed Steelhead, Cisco WAAS, Bluecoat e Citrix Cloudbridge / Wanscaler sono esempi di tecnologie che potrebbero influire sull'applicazione. Una discussione con il tuo provider (o ragazzo di rete) dovrebbe rivelare se tali tecnologie sono in uso sulla tua rete; in tal caso, richiedere di ignorare il traffico interessato in questi dispositivi per vedere se il comportamento cambia. Buona fortuna.

— perdita di pacchetti
fonte

Questa è una buona teoria; L'accelerazione della WAN è una tattica comune nel tentativo di contrastare le connessioni ad alta latenza (satellite).

— Ryan Foley,

Dato che il client si stava accorgendo che il server non stava inviando, ho pensato che dovesse essere lo spoofing. Ciò causerebbe la caduta dei pacchetti, tuttavia?

— Johan,

Johan, sarebbe molto difficile risolvere ulteriormente senza 1) informazioni sull'intestazione tcp (i numeri di sequenza sono importanti qui) e 2) la stringa dell'apparecchiatura, inclusi modem satellitari, proxy di miglioramento delle prestazioni e / o attrezzatura di ottimizzazione WAN. Solo un pensiero qui, dato che ssh non sembra essere interessato, hai mai pensato di tunnelizzare i dati delle tue applicazioni personalizzate attraverso un tunnel ssh?

— packetloss,