Khám phá MTU đường đi qua VPN: kích thước và khoảng trống ICMP

Một đường hầm hoàn tất bắt tay, các yêu cầu nhỏ quay về, và lần truyền lớn đầu tiên bị kẹt. Mẫu hình đó chỉ vào MTU đường đi sớm hơn nhiều so với chỉ vào thông lượng. Mỗi liên kết dọc tuyến giới hạn kích thước gói, và việc đóng gói tiêu tốn một phần hạn mức đó cho các tiêu đề bên ngoài, nên gói bên trong phải nhỏ hơn mức tuyến thô gợi ý. Sự cố diễn ra âm thầm, và chính điều đó khiến việc chẩn đoán tốn kém.

MTU đường đi thực sự đo cái gì

MTU đường đi là MTU liên kết nhỏ nhất trên tuyến giữa hai máy chủ, không phải MTU in trên giao diện cục bộ của bạn. Giá trị cục bộ là nơi bắt đầu ước lượng, và tuyến quyết định nơi nó phải kết thúc. Đó là lý do một đường hầm giống hệt có thể chạy trên mạng truy cập này và kẹt trên mạng khác: tuyến đã thay đổi, cấu hình thì không. Đo một lần rồi giả định ở mọi nơi là sai lầm nuôi sống vấn đề này.

Với một đường hầm, con số quan trọng là MTU bên trong, tức hạn mức của tuyến ngoài trừ đi phần mà việc đóng gói tiêu thụ. WireGuard thêm một tiêu đề IP ngoài và một tiêu đề UDP; các giao thức truyền tải khác thêm phần của chúng. Đặt kích thước bên trong quá cao và mỗi gói cỡ đầy đủ sẽ cần phân mảnh mà có thể không bao giờ xảy ra.

Vì sao đường hầm thu nhỏ gói dùng được

Nếu giao diện đường hầm giữ MTU của liên kết vật lý, mỗi gói lớn phụ thuộc vào việc ai đó ở phía dưới sẵn sàng phân mảnh nó. IPv4 về nguyên tắc cho phép điều đó, nhưng một bộ định tuyến được bảo không phân mảnh sẽ trả về lỗi thay thế. Các bộ định tuyến IPv6 không bao giờ phân mảnh khi truyền, nên cùng một thiết lập hành xử khác nhau theo họ địa chỉ. Dù thế nào, bên gửi không học được gì cho đến khi có thứ gì đó báo về.

Hệ quả thực tế là một kích thước vừa với bắt tay nhưng không vừa với tải trọng. Một TLS ClientHello hay một truy vấn DNS đủ nhỏ để đi qua tuyến đã thu hẹp mà không bị chạm, trong khi một lần truyền lớn thì không. Vì vậy các triệu chứng tụ lại quanh những thao tác cụ thể chứ không phải những máy chủ cụ thể.

Khám phá chỉ hoạt động khi phản hồi đến

Khám phá IPv4 dựa vào bit don't-fragment: bộ định tuyến không thể chuyển tiếp gói sẽ trả về ICMP fragmentation-needed kèm MTU của bước nhảy kế tiếp, và bên gửi hạ ước lượng của mình. IPv6 dùng thông điệp Packet Too Big thay vào đó, vì các bộ định tuyến không phân mảnh khi truyền. Cả hai cơ chế đều giả định thông điệp tìm được đường về bên gửi, xuyên qua đường hầm và vượt qua bất kỳ tường lửa nào trên tuyến về. Khi giả định đó thất bại, bên gửi tiếp tục thử lại một kích thước mà tuyến không thể mang.

Một tường lửa cho phép echo request và echo reply chưa chắc đã cho phép những loại lỗi đó. ICMP là một họ, và thành viên quan trọng ở đây là các lỗi, không phải cặp echo. Hãy kiểm tra chính sách lưu lượng điều khiển ở cả hai đầu đường hầm và trên tuyến giữa chúng, và tuân theo hướng dẫn được nền tảng hỗ trợ thay vì cho phép mọi loại ICMP ở mọi nơi.

Cùng việc lọc đó có thể nằm bên trong đường hầm. Nếu tuyến trong loại bỏ lỗi nhưng tuyến ngoài mang nó đi, bên gửi có thể thích nghi với một giới hạn mà lưu lượng được đóng gói không bao giờ thực sự thấy.

Hãy thử tuyến thay vì đoán một con số

Giữ cố định đích đến, mạng truy cập và đường hầm, rồi chỉ thay đổi kích thước gói. Một thử nghiệm don't-fragment thất bại kèm gợi ý MTU cho bạn giới hạn của bước nhảy kế tiếp; lặp lại cho đến khi một kích thước đi qua, và ghi lại cả kích thước lẫn họ địa chỉ.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Một ping vừa khít không chứng minh rằng các phân đoạn cỡ đầy đủ của ứng dụng thật vừa khít, nên hãy lặp lại thử nghiệm với lần truyền đã thực sự thất bại. So sánh thử nghiệm lớn nhất đã thành công với MTU đường hầm bạn đã cấu hình, và giữ hai con số tách biệt trong ghi chú của bạn. Nếu chúng khác nhau khoảng một tiêu đề, bạn đã tìm ra phần chi phí thêm của việc đóng gói chứ không phải một khiếm khuyết.

PLPMTUD, được mô tả trong RFC 4821, thăm dò lên trên và dùng các xác nhận của tầng truyền tải thay vì tin vào các lỗi được chuyển đến. Nó hữu ích trên những tuyến lọc ICMP, nhưng mức hỗ trợ khác nhau theo ngăn xếp và theo ứng dụng. Một luồng TCP có thể tự phục hồi trong khi một ứng dụng UDP với kích thước datagram cố định tiếp tục thất bại.

Chọn một giá trị và ghi lại lý do

Hạ MTU của đường hầm vừa là chẩn đoán vừa là bản sửa hợp lý khi bạn đã biết tuyến. Nó không thay thế việc biết tuyến nào và cơ chế phản hồi nào đã tham gia, vì một giá trị được chỉnh cho liên kết di động sẽ nhỏ quá mức không cần thiết trên kết nối cáp quang. Ghi lại kích thước đã chọn, thử nghiệm đã biện minh cho nó và bước hoàn tác.

Cơ chế IPv4 được mô tả trong RFC 1191 và hướng dẫn đóng gói IPv6 trong RFC 8201; nêu cả hai giúp kỹ sư tiếp theo không phải suy ra lại giả định. Nếu lần truyền vẫn kẹt ở kích thước bạn chọn, hãy ngừng hạ con số và nhìn sang tầng tiếp theo. Một tuyến thất bại ở mọi kích thước không phải là vấn đề MTU.