Tôi đang gặp sự cố lạ với kết nối có dây tới bộ định tuyến trên mạng LAN, nơi lưu lượng TCP bị ngắt và được ghi dưới dạng gói bị phân mảnh.
Kịch bản có MTU được đặt ở 1500 trên các máy khách mạng và trên bộ điều hợp ethernet của bộ định tuyến (theo địa chỉ ip hiển thị).
Ví dụ về gói thông báo bị hủy (được chia thành nhiều dòng để dễ đọc):
Ngày 12 tháng 5 09:44:05 kernel: DROP IN=eth0 OUT=tun11 MAC=<đã xóa>
SRC=<IP máy tính để bàn> DST=<IP đích bên ngoài>
LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=54356 DF PROTO=TCP SPT=53370 DPT=443 SEQ=3216568911 ACK=0
WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080A002E76880000000001030307) MARK=0x8000000
Từ một số đọc nhẹ trên TCP/IP, tôi có thể thấy rằng opt 0204 đề cập đến MSS và kích thước dường như là 1460, mặc dù tôi đang cố gắng hiểu những byte còn lại đề cập đến cái gì (0402 080A 002E 7688 0000 0000 0103 0307). Tôi có thể thấy không có quy tắc tường lửa nào trên bộ định tuyến áp dụng nhãn hiệu nào cả, nhưng kiến thức về bộ lọc mạng chi tiết còn hạn chế.
Khi tôi thử tính toán kích thước MTU tối đa thông qua ping -M do <IP bộ định tuyến> -c 2 -s 1500 phản hồi của khách hàng là lỗi cục bộ: tin nhắn quá dài, mtu=1500 hoặc khi ping cmd sử dụng kích thước MTU nhỏ hơn để kiểm tra, không có phản hồi/tất cả các gói bị lỗi.
Trước đây, tôi giảm MTU xuống 28 và sau đó nhận được kịch bản sau. Tôi cho rằng điều này có nghĩa là MTU phù hợp nhưng gói vẫn bị hủy. Mục nhập nhật ký bộ định tuyến ví dụ của lần thả này:
12 tháng 5 13:01:01 kernel: DROP IN=eth0 OUT= MAC=<đã xóa>
SRC=<IP máy tính để bàn> DST=<IP bộ định tuyến>
LEN=1378 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=ICMP TYPE=8 CODE=0 ID=5 SEQ=1 MARK=0x8000000
Khi tôi xác định một MTU phù hợp hơn bằng cách sử dụng ping kiểm tra và khởi động lại máy tính để bàn, các gói tiếp tục bị phân mảnh và ping test sau đó trả về MTU thấp hơn (ít hơn 28 byte mỗi lần).
Máy tính để bàn chạy Kubfox 20.04.4.
Sau một thời gian đáng kể để cố gắng hiểu thêm về tình huống này, tôi đã thử thêm tuân theo các quy tắc iptables trên bộ định tuyến:
-A INPUT -m conntrack --ctstate LIÊN QUAN, THÀNH LẬP -j CHẤP NHẬN
-A FORWARD -m conntrack --ctstate DNAT -j CHẤP NHẬN
Nhưng điều này đã không giải quyết được vấn đề.
Điều này không không phải xảy ra trên các thiết bị Android được kết nối với cùng một bộ định tuyến qua WiFi. Bộ định tuyến được khởi động lại qua đêm theo lịch trình và Xbox gặp phải tình huống phân mảnh / rớt gói tương tự cho đến khi chúng được khởi động lại ít nhất một lần. Một XBox kết nối qua WiFi, một kết nối với bộ định tuyến được nối với bộ định tuyến có vấn đề.
Lưu lượng giữa bộ định tuyến WiFi và bộ định tuyến biên dường như không bị ảnh hưởng - không có dấu hiệu gói tin nào bị hủy do phân mảnh ở lớp đó.
cách giải quyết
Tôi đã phát hiện ra rằng chạy một đường theo dõi từ đánh đập trên máy tính để bàn bằng cách nào đó giải quyết vấn đề
Trước và sau khi 'sửa lỗi' này, bộ điều hợp LAN của máy tính để bàn được liệt kê với cùng một MTU, trong khi nếu MTU cần được điều chỉnh, tôi sẽ mong đợi giá trị này được thay đổi (và sau đó tôi có thể đặt nó làm mặc định):
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
Tuy nhiên tôi không hiểu tại sao các đường theo dõi rõ ràng khắc phục vấn đề. Bất kỳ đề nghị sẽ được biết ơn nhận vào thời điểm này.
