Hố đen MTU: vì sao yêu cầu nhỏ hoạt động nhưng tải lên bị treo

Một trang tải xong, một lệnh gọi API nhỏ trả về, rồi một tệp tải lên bị treo cho đến khi ứng dụng khách bỏ cuộc. Không có gì trong nhật ký máy chủ giải thích điều đó, vì các gói tin đã bị bỏ giữa đường mà không gửi lại câu trả lời hữu ích nào. Mẫu đó là một hố đen MTU: một liên kết hẹp hơn bên gửi giả định, cộng với việc im lặng từ chối nói ra điều đó. Kích thước gây lỗi có thể lặp lại, và đó là điều khiến nó có thể chẩn đoán được.

Điều gì làm hố trở nên đen

Mỗi liên kết có một đơn vị truyền tối đa, và một gói lớn hơn giới hạn của chặng kế tiếp phải được phân mảnh hoặc bị từ chối bằng thông điệp ICMP nói rõ điều đó. Việc phát hiện MTU đường đi phụ thuộc vào việc thông điệp đó đến nơi và được tôn trọng. Lọc hoặc phớt lờ nó khiến bên gửi lặp lại một gói không bao giờ vừa.

Đóng gói làm điều này trở nên phổ biến quanh VPN, vì đường hầm thêm một tiêu đề ngoài vào gói vốn đã được định cỡ cho liên kết vật lý. Gói bên trong hợp lệ ở 1500 byte còn gói được đóng gói thì không, nên nó chết ở ranh giới trong khi các gói nhỏ đi qua. Một bắt tay hoàn tất và một trang đăng nhập hoạt động chỉ chứng minh rằng các gói nhỏ hoạt động. Gói lớn nhất mà ứng dụng cố gửi mới là điều quan trọng.

Tìm kích thước nơi nó đứt

Tìm kiếm nhị phân kích thước tải trọng bằng phép thử không phân mảnh, từ một máy chủ ở một phía đường hầm đến máy chủ ở phía kia. Tải trọng lớn nhất đi qua là MTU đường đi dùng được của bạn trừ đi phần phụ trội tiêu đề.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Một tải trọng 1472 byte đi qua trên một đường Ethernet sạch 1500 byte khi thêm 28 byte của tiêu đề IPv4 và ICMP. Khi cùng phép thử chỉ thành công với tải trọng nhỏ hơn sau khi đường hầm được dựng lên, khác biệt là phần phụ trội đóng gói, và ranh giới đường hầm là nơi lẽ ra thông điệp từ chối phải được tạo ra. Ghi lại cả hai con số, trước và sau khi kết nối, vì cặp đó là bằng chứng. Lặp lại phép thử cho IPv6 khi ứng dụng dùng nó, vì tiêu đề lớn hơn và ngưỡng lỗi dịch chuyển.

Đọc bằng chứng trước khi đổ lỗi cho đường hầm

Lỗi ứng dụng từ xa, tắc nghẽn và mất mát thông thường cũng làm tải lên bị treo, nên một lần truyền thất bại không xác định được hố đen. Điều phân biệt chúng là quan hệ kích thước: thành công lặp lại ở 1200 byte và treo lặp lại ở 1400 byte, cùng hướng, qua cùng điểm cuối.

Bản bắt gói ở hai đầu cho thấy các gói lớn rời đi và không bao giờ đến, không có từ chối ở giữa. Đó là lúc nhìn vào thiết bị ranh giới thay vì máy chủ, vốn đang trả lời mọi yêu cầu nó thực sự nhận được. Tắc nghẽn cũng làm treo, nhưng nó làm treo các kích thước khác nhau vào các thời điểm khác nhau, và đó là một chữ ký khác.

Kiểm tra bản sửa trên cả hai giao thức truyền

Cách sửa được hỗ trợ là để ranh giới báo cáo giới hạn thật, hoặc kẹp kích thước đoạn tối đa của TCP tại đó để không đoạn quá lớn nào bị thử. Hạ mọi MTU trên mạng, hoặc tắt tường lửa, che giấu triệu chứng và để lại một cấu hình mà sau này không ai có thể lý luận được.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Xác minh bằng cùng phép thử kích thước, rồi bằng ứng dụng đã thất bại, và kiểm tra một giao thức thứ hai, vì ứng dụng UDP không bao giờ nhận được hiệu chỉnh kích thước đoạn của TCP. Giữ các giá trị ban đầu trong phiếu, vì một cách sửa không thể hoàn tác là vấn đề thứ hai đang chờ xảy ra. Nếu phép thử kích thước qua và tải lên vẫn treo, hố đen không phải nguyên nhân, và cuộc điều tra nên tiếp tục thay vì mở rộng thay đổi.