Khung jumbo không làm cho đường VPN chở được gói 9000 byte

Bạn đã bật khung 9000 byte trên LAN và mong VPN nhanh hơn. Nó lại chậm đi, hoặc ngừng truyền các lần chuyển lớn hoàn toàn. Khung jumbo là một thỏa thuận liên kết cục bộ; chúng không mở rộng đường đi mà đường hầm băng qua.

Ngân sách khả dụng do ranh giới nhỏ nhất trên tuyến quyết định, bao gồm cả phần đóng gói mà đường hầm thêm vào.

Khung jumbo thực sự thay đổi điều gì

MTU là thuộc tính của một giao diện. Nâng nó trên một máy chủ và switch của nó nghĩa là hai bên đó có thể trao đổi khung lớn hơn mà không cần phân mảnh. Điều đó không nói gì về router phía sau switch, về nhà cung cấp dịch vụ, hay về đầu bên kia của đường hầm. Những thiết bị đó có giới hạn riêng, và một gói vượt quá một trong số đó sẽ bị bỏ hoặc bị phân mảnh theo những quy tắc bạn không đặt ra.

Thỏa thuận cục bộ, hệ quả toàn cục. Đó là toàn bộ sự nhầm lẫn.

Thuế đóng gói

Đường hầm bọc gói của bạn vào trong một gói khác. WireGuard trên IPv4 UDP thêm khoảng 60 byte chi phí; chế độ UDP của OpenVPN nằm trong cùng khoảng đó, còn IPsec thay đổi theo chế độ và thuật toán. Những byte đó lấy từ ngân sách của tuyến ngoài, không phải từ trên trời rơi xuống.

Vì vậy một liên kết ngoài 1500 byte không thể chở một gói bên trong 1500 byte khi đã thêm phần đầu của đường hầm.

Phép tính này đáng làm một lần. Trên tuyến 1500 byte, giao diện WireGuard muốn MTU khoảng 1420 để gói đã đóng gói vừa khít. Đặt giao diện bên trong thành 9000 và mọi gói lớn sẽ cần phân mảnh mà đường hầm không làm được, hoặc bị bỏ.

Tìm liên kết nhỏ nhất trên tuyến

Đi dọc tuyến và tìm MTU thấp nhất. LAN thường là 1500 hoặc 9000, WAN thường là 1500, và một liên kết di động hoặc PPP có thể còn thấp hơn. Sau đó trừ đi chi phí thêm của đường hầm. Nếu kết quả nhỏ hơn MTU của giao diện bên trong thì đó là câu trả lời của bạn. Việc dò MTU đường đi có thể tìm ra điều này tự động, nhưng chỉ khi các thông điệp ICMP mà nó phụ thuộc được cho đi qua.

ICMP bị lọc là lý do kinh điển khiến một lần chuyển lớn bị treo trong khi các yêu cầu nhỏ vẫn chạy tốt.

Kiểm tra sự phụ thuộc vào kích thước mà không mở rộng thay đổi

Dùng một lần chuyển tiêu biểu và giữ lại các giá trị ban đầu để có thể đặt lại. ping -M do -s 1472 thử một gói 1500 byte với bit DF được bật; giảm kích thước cho đến khi nó đi qua. Nếu chỉ các gói lớn thất bại thì bạn gặp vấn đề kích thước chứ không phải định tuyến.

Hãy cảnh giác với offload phía máy chủ khi đọc bản ghi. Offload phân đoạn có thể hiển thị những khung lớn hơn nhiều so với thứ thực sự đi qua dây, khiến một tuyến đang chạy trông như hỏng và một tuyến hỏng trông như ổn.

Khi nào MTU lớn là thiết kế đúng

Một mạng riêng được kiểm soát có thể chạy khung lớn hơn từ đầu đến cuối một cách hợp lệ, miễn là mọi thiết bị trên tuyến đồng ý và chi phí thêm của đường hầm được tính đến. Đó là một thiết kế phối hợp với giá trị được ghi lại cho từng liên kết, chứ không phải một con số lớn gõ vào máy khách.

Với một lối ra công cộng thông thường, hãy giả định 1500 hoặc ít hơn và để đường hầm chọn một MTU bên trong an toàn. RFC 8201 đề cập việc dò MTU đường đi cho trường hợp IPv6 và là tài liệu tham khảo hữu ích về cách phản hồi nên hoạt động.