Gói dữ liệu bị mất trên kết nối vệ tinh

Chúng tôi có một số chiếc nhúng trong các trang trại ở Anh và Mỹ. Trong số các kết nối khác, chúng nói chuyện với máy chủ của chúng tôi gửi một gói dữ liệu nhỏ (100 - 600 byte) cứ sau 20 giây.

Trên DSL điều này là tốt. Qua kết nối vệ tinh, chúng tôi mất hầu hết các gói.

Chúng tôi đang sử dụng TCP và tcpdump trên máy khách hiển thị trình tự:

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

Tuy nhiên, máy chủ thấy:

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

Tôi nghĩ rằng tôi đã đúng khi nói các acks bổ sung mà khách hàng nhận được bị giả mạo bởi điểm cuối vệ tinh để tăng tốc kết nối

Chúng tôi có ~ 100 trang DSL và 3 vệ tinh. DSL đều ổn và các vệ tinh đều bị hỏng theo cùng một cách.

Điều gì đang xảy ra với dữ liệu? Nó có thể thông qua một lần trong 20.

chỉnh sửa Tôi có thể ping máy chủ từ máy khách trong câu hỏi. Tất cả các máy khách đều có đường hầm ssh ngược tới máy chủ đang hoạt động tốt. Chúng tôi có thể ssh in, và cũng tải dữ liệu. Chỉ là tải lên này có vấn đề.

Kết nối DSL - thành công

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

Kết nối vệ tinh - không thành công

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

Không có lưu lượng ICMP trong cả hai trường hợp.

Dấu thời gian trên các mục pcap vệ tinh của bạn có nghĩa là giả mạo xác nhận tcp. Hầu hết các thiết bị thực hiện giả mạo xác nhận có thể được cấu hình để vượt qua khả năng tăng tốc dựa trên một số kết hợp địa chỉ IP nguồn / đích, cổng nguồn / đích; khái niệm ACL tiêu chuẩn. Đây có thể là một tính năng có thể định cấu hình trong các modem vệ tinh (hoặc thiết bị gần đó) tại trung tâm của bạn và các vị trí nói.

Các giải pháp tối ưu hóa hoặc tăng tốc diện rộng cũng phổ biến trong các kiến ​​trúc mạng như vậy. Một lần nữa, các giải pháp này sẽ cung cấp một phương pháp để bỏ qua lưu lượng truy cập của bạn có vấn đề. Các thiết bị như Riverbed Steelhead, Cisco WAAS, Bluecoat và Citrix Cloudbridge / Wanscaler là những ví dụ về công nghệ có thể ảnh hưởng đến ứng dụng của bạn. Một cuộc thảo luận với nhà cung cấp của bạn (hoặc anh chàng mạng) sẽ tiết lộ nếu các công nghệ đó được sử dụng trên mạng của bạn; nếu vậy, hãy yêu cầu bỏ qua lưu lượng truy cập bị ảnh hưởng của bạn trong các thiết bị này để xem hành vi có thay đổi không. May mắn nhất.