Làm cách nào để khắc phục sự cố nếu tôi thấy gói tin đến trong tcpdump, nhưng không phải ở ổ cắm?

Ví dụ, tôi thấy rằng gói đến tcpdump, nhưng không phải stracecho chương trình đang nghe ổ cắm thích hợp.

Làm cách nào để theo dõi "số phận" của gói đến trên Linux này?

Tôi hy vọng sẽ nhận được một báo cáo như thế này:

• ✓ Gói nhận được bởi giao diện mạng;
• ✓ Gói được giải mã thành công dưới dạng gói IPv4 (tổng kiểm tra chính xác, v.v.);
• ✓ Gói thông qua iptables (không DROP'ed);
• Gói được định tuyến đến ổ cắm cục bộ (Không, đó không phải là địa chỉ IP của chúng tôi);
•   Gói thông qua kiểm soát lưu lượng (không bị giảm do một số quá tải);
•   Gói nhận được bởi ổ cắm cục bộ

Nơi tôi có thể nhận thông tin tóm tắt mà không cần điều tra thủ công từng điểm dừng có thể (có thể tôi thậm chí không biết tất cả các điểm dừng)?

tcpdump chỉ cần tạo một bản sao dữ liệu truyền qua NIC với sự trợ giúp của ổ cắm thô, hoạt động trong ngăn xếp TCP / IP trong HĐH. Có thể thu thập dữ liệu bằng tcpdump có nghĩa là các gói thực sự đến được với NIC.

strace chỉ đơn giản là in mọi cuộc gọi hệ thống. Không thể nắm bắt nó trong phương tiện strace readhoặc writecác cuộc gọi hệ thống không được thực hiện. ví dụ, một readtòa nhà chọc trời gọi trình điều khiển NIC để di chuyển dữ liệu từ NIC sang bộ nhớ kernel được liên kết với bộ mô tả tệp ổ cắm và sau đó sao chép chúng vào bộ đệm không gian người dùng. strace có thể kiểm tra các đối số trong readcuộc gọi và sau đó in chúng.

Ngoài ra, nếu đó là một ổ cắm luồng, tôi nghĩ rằng accepttòa nhà đã được tạo và một bộ mô tả tệp được phân bổ, để khách hàng có thể gửi các gói qua và tcpdump có thể chụp chúng. Tôi có một ví dụ sống ở đây.

15:21:25.285198 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 597)
    10.93.235.127.51524 > 10.225.131.26.8040: Flags [P.], cksum 0xefc8 (correct), seq 1:546, ack 1, win 2052, options [nop,nop,TS val 633828071 ecr 2357545597], length 545
POST /api/query HTTP/1.1
Content-Type: application/json
User-Agent: PostmanRuntime/7.15.2
Accept: */*
Cache-Control: no-cache
Postman-Token: e5584554-5747-4f2c-84c4-8e621b3bfeb2
Host: 10.225.131.26:8040
Accept-Encoding: gzip, deflate
Content-Length: 256
Connection: keep-alive

{"start":1567397847315,"end":1567398147315,"queries":[{"aggregator":"avg","metric":"endpoint.status.ok","rate":true,"rateOptions":{"counter":false,"diff":false},"tags":{"dc":"*","host":"n225"},"topK":""}],"allowCoprocessor":false}
15:21:25.285210 IP (tos 0x0, ttl 64, id 17260, offset 0, flags [DF], proto TCP (6), length 52)
    10.225.131.26.8040 > 10.93.235.127.51524: Flags [.], cksum 0x83fe (incorrect -> 0xb98e), ack 546, win 7513, options [nop,nop,TS val 2357545605 ecr 633828071], length 0
5 packets captured

nhưng strace cho thấy nó chỉ accepted nhưng không read, vì vậy không thấy gói tin nào.

2524390 accept4(9, {sa_family=AF_INET6, sin6_port=htons(51524), inet_pton(AF_INET6, "::ffff:10.93.235.127", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [128->28], SOCK_CLOEXEC|SOCK_NONBLOCK) = 178687
2524390 getsockname(178687, {sa_family=AF_INET6, sin6_port=htons(8040), inet_pton(AF_INET6, "::ffff:10.225.131.26", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [128->28]) = 0
2524390 setsockopt(178687, SOL_TCP, TCP_NODELAY, [1], 4) = 0
2524390 getsockopt(178687, SOL_SOCKET, SO_SNDBUF, [65536], [4]) = 0
2524390 getsockopt(178687, SOL_SOCKET, SO_SNDBUF, [65536], [4]) = 0
2524390 setsockopt(178687, SOL_SOCKET, SO_SNDBUF, [131072], 4) = 0
2524390 getsockopt(178687, SOL_SOCKET, SO_SNDBUF, [262144], [4]) = 0
2524390 getsockopt(178687, SOL_SOCKET, SO_SNDBUF, [262144], [4]) = 0
2524390 setsockopt(178687, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
2524390 setsockopt(178687, SOL_TCP, TCP_NODELAY, [1], 4) = 0
2524390 setsockopt(178687, SOL_SOCKET, SO_RCVBUF, [131072], 4) = 0

Nó tương tự cho ổ cắm datagram.