MTU hay MSS? Thay đổi VPN thực sự sửa điều gì

Ping thành công, các lần truyền lớn bị treo, và đường hầm báo cáo rằng nó khỏe mạnh. Ai đó hạ MTU của giao diện, người khác giới hạn MSS, và đôi khi sự cố biến mất vì những lý do không ai ghi lại. Hai con số mô tả những đối tượng khác nhau, nên thay đổi sai cái sẽ tạo ra một bản sửa trông như may mắn. Đây là quy trình: xác định tầng, áp dụng điều chỉnh tương ứng, rồi kiểm tra trên một kết nối mới.

Hai con số, hai đối tượng

MTU thuộc về một liên kết hoặc một giao diện: đó là gói lớn nhất có thể được chuyển đi mà không bị chia nhỏ. MSS thuộc về TCP: đó là lượng tải trọng TCP lớn nhất mà một phân đoạn có thể chở, và nó loại trừ cả phần đầu TCP lẫn IP. Trên một liên kết Ethernet thông thường dùng IPv4, MTU 1500 byte cho MSS quen thuộc 1460 byte. Những con số này mô tả các tầng khác nhau và được trao đổi bằng các cơ chế khác nhau. Rất dễ nhầm lẫn vì cả hai đều đo bằng byte và cả hai đều ở gần 1500.

Một cái đến như một thiết lập giao diện. Cái kia đến như một tùy chọn bên trong phân đoạn SYN, được thương lượng giữa các đầu mút không bao giờ nhìn thấy giao diện của bạn.

Chi phí phụ bên ngoài rơi vào đâu

VPN đặt gói bên trong vào một gói khác, và gói bên ngoài phải vừa với đường đi vật lý. Các phần đầu đóng gói, phần đầu IP bên ngoài, phần đầu giao vận và bất kỳ thẻ xác thực nào đều tiêu thụ những byte mà gói bên trong không thể dùng. Để giao diện đường hầm ở 1500 và gói bên ngoài thường xuyên vượt quá những gì đường đi có thể chở. Khi bit 'không phân mảnh' được đặt, bộ định tuyến bỏ gói đó và đáng lẽ phải gửi trả một lỗi ICMP; nếu lỗi đó bị lọc, bên gửi không bao giờ biết.

Đó là lý do sự cố trông có vẻ chọn lọc. Các yêu cầu nhỏ hoàn tất và bất cứ thứ gì lấp đầy một phân đoạn đều bị kẹt, vì chỉ những gói lớn mới bị bỏ. Một đường hầm cho ping đi qua không phải là đường hầm chở dữ liệu.

Giới hạn MSS, và nơi nó áp dụng

Việc giới hạn MSS viết lại giá trị trong phân đoạn SYN khi nó đi qua một điểm được chọn, khiến cả hai đầu chọn tải trọng nhỏ hơn mà không biết vì sao. Trên Linux, đây là một đích của bảng mangle được áp dụng bằng một quy tắc rõ ràng, và nó phải đánh trúng các gói SYN theo hướng bạn muốn. Giới hạn nó trong giao diện đường hầm và dải địa chỉ, vì một quy tắc rộng sẽ thay đổi hành vi của lưu lượng không bao giờ đi vào đường hầm.

Tác động chỉ với TCP. Một ứng dụng UDP, một phiên QUIC và bất kỳ giao thức nào tự dựng datagram của mình đều không bị ảnh hưởng.

Chẩn đoán bằng một đường đi cố định

Giữ một biến tại một thời điểm. Kiểm tra bằng một gói mà bạn tự chọn kích thước, và đặt cờ 'không phân mảnh' để nhân hệ điều hành báo kết quả thay vì che giấu nó.

Ghi lại sự cố bắt đầu ở đâu: bên trong đường hầm, tại giao diện đường hầm, hay trên đường đi vật lý sau khi đóng gói. Sau đó đổi một con số và lặp lại đúng bài kiểm tra đó, không phải bài khác. Các kết nối hiện có giữ MSS đã thương lượng, nên thay đổi chính sách chỉ thấy trên kết nối mới, và đó là lý do một trang trong bộ nhớ đệm không chứng minh được gì theo hướng nào. Nếu một lần tải lên lớn bắt đầu hoạt động, bạn đã học về đường đi đó chứ không phải về mọi giao thức trên nó.

Mỗi thay đổi không sửa điều gì

Hạ MTU của giao diện không thay đổi MSS của một phiên đã được thiết lập. Giới hạn MSS không giúp một luồng UDP và không sửa một đường đi nơi lỗi ICMP chỉ bị lọc theo một hướng. Mỗi thay đổi sửa một lớp vấn đề và để phần còn lại y nguyên như cũ.

Ghi lại bạn đã áp dụng điều chỉnh nào, ở đâu và bài kiểm tra nào cho thấy khác biệt, vì nếu không thì kỹ sư tiếp theo áp dụng cả hai và mất khả năng nói cái nào mới quan trọng. Nếu ràng buộc là thật và lâu dài, hãy chọn MTU đường hầm phản ánh nó thay vì một giới hạn che giấu nó. Nếu buộc phải giới hạn, hãy để quy tắc có phạm vi hẹp và có chú thích, vì một quy tắc mangle không được giải thích sẽ trở thành vĩnh viễn theo mặc định.