Đường hầm VPN lồng nhau: vì sao lớp bên trong đơ với gói tin lớn

DNS phân giải được, phiên SSH vẫn duy trì, rồi một lần tải lên lớn bị đơ trong khi ping đến cùng máy chủ vẫn trả lời. Sự tách biệt đó chỉ vào kích thước gói tin chứ không phải một đường hầm hỏng. Các đường hầm lồng nhau chạm tới điều đó ở kích thước mà không đường hầm nào một mình chạm tới. Phiên bên trong vẫn ổn; nó chỉ được giao những gói tin không còn vừa nữa.

MTU của đường đi thực sự đi đâu

Mỗi lớp đóng gói tiêu tốn byte trước khi lớp kế tiếp đến lượt. Một đường Ethernet dành 1500 byte cho gói bên ngoài, và đường hầm bên ngoài lấy phần của nó trước khi bất cứ thứ gì bên trong có thể được đánh địa chỉ. Một giá trị overhead ước đoán sẽ sai đúng bằng lượng quan trọng.

Liệt kê các lớp theo thứ tự: đường truy cập, vận chuyển bên ngoài, đường hầm bên ngoài, vận chuyển bên trong, đường hầm bên trong, ứng dụng. Đếm mỗi tiêu đề một lần, và giữ UDP tách khỏi tiêu đề và thẻ của chính đường hầm.

Hai lớp WireGuard, đếm một lần

Lấy một đường truy cập IPv4 với một đường hầm WireGuard nằm trong một đường hầm khác. Lớp bên ngoài tốn 20 byte IPv4, 8 byte UDP và 32 byte cho tiêu đề dữ liệu WireGuard cùng thẻ xác thực của nó. Bên trong đó, đường hầm bên trong cần tiêu đề IPv4 20 byte và tiêu đề UDP 8 byte của riêng nó trước 32 byte overhead WireGuard thứ hai. Phần còn lại chứa tiêu đề IPv4, tiêu đề TCP và dữ liệu. Một đường bên ngoài IPv6 tốn 40 thay vì 20 và để lại 1320.

Phép tính kết thúc ở 1340 byte. Một lớp theo cùng quy tắc để lại 1400 cho tải trọng TCP, tức là 1500 trừ 20, 8, 32, 20 và 20, và chênh lệch 60 byte chính là phần đóng gói bên trong mà đường hầm thứ hai thêm vào.

Áp 1400 cho một đường lồng nhau và đường hầm bên trong thiếu 60 byte, không nhìn thấy cho đến khi gói tin đủ lớn để cần chúng. Phần đệm và tùy chọn phân mảnh của chính giao thức lại dịch chuyển các con số, nên hãy tin vào bảng.

MTU, MSS và phân mảnh tác động ở những nơi khác nhau

MTU của giao diện giới hạn những gì giao diện sẽ phát ra, trong khi việc kẹp MSS của TCP thay đổi những gì một đối tác TCP sẵn sàng gửi. Việc kẹp sửa các phiên TCP và không làm gì cho một datagram UDP lớn, đó là cách một bản sửa trông thành công với một ứng dụng và lặng lẽ bỏ sót ứng dụng kế tiếp. Tùy chọn phân mảnh của chính giao thức là đòn bẩy thứ ba với những thất bại riêng. MTU của giao diện là bước đi đầu tiên phổ biến và thô nhất.

Đường hầm cầu nối và định tuyến mang các khung khác nhau, nên các con số từ một triển khai khác hiếm khi chuyển được. Việc dò MTU đường đi, được mô tả trong RFC 8201, chỉ giúp ích khi các thông điệp ICMP mà nó phụ thuộc được cho đi qua.

Tìm lớp còn thiếu

Xác minh từng đường hầm riêng lẻ trước khi lồng chúng, nếu yêu cầu cho phép so sánh. Một phép dò kích thước cố định quyết định điều đó: ping -M do -s 1472 -c 3 10.8.0.1 gửi một gói IPv4 đầy đủ 1500 byte bên trong lớp đó. Thêm lớp thứ hai và lặp lại cùng phép dò, để bất kỳ lỗi nào thuộc về một thay đổi đã biết.

Khi một lần truyền bị kẹt, hãy thay đổi từng tham số đã ghi tài liệu một và ghi lại kích thước gây lỗi. Kiểm tra cả đường về, vì đệ quy tuyến lồng nhau có thể mô phỏng vấn đề kích thước gói đủ sát để tốn cả một buổi chiều. Một phản hồi ICMP bị lọc có thể che giấu giới hạn thật, nên phép dò quan trọng hơn lập luận.

Viết ngân sách ở nơi người tiếp theo sẽ tìm thấy

Một bảng với một hàng cho mỗi lớp sống lâu hơn một quy tắc ngón tay cái. Giữ nó bên cạnh sơ đồ đường hầm để không ai phải làm lại phép tính dưới áp lực.

Nhiều đường hầm nghĩa là nhiều phụ thuộc, nên một kế hoạch khôi phục xứng đáng có chỗ bên cạnh ngân sách. Nếu các con số vẫn không khớp, hãy đo đường đi thay vì đoán lại. Mục tiêu là một con số bạn có thể bảo vệ, không phải ghi nhớ.