Gói IPv6 quá lớn: vì sao các lần truyền VPN lớn bị treo

Ping hoạt động, trình duyệt tải một trang nhỏ và việc truyền tệp bị treo, tất cả qua IPv6 trong cùng một đường hầm. Kiểu này thường có nghĩa là bên gửi chưa bao giờ biết kích thước thật của đường đi, chứ không phải đường hầm chậm. IPv6 kỳ vọng các bộ định tuyến báo cáo sự cố bằng thông điệp Packet Too Big, và việc đóng gói thêm phần chi phí trước khi gói tin đến mạng bên ngoài. Nếu thông điệp đó bị lọc, bên gửi tiếp tục lặp lại một kích thước không thể đi qua.

Yêu cầu nhỏ, treo lớn

Một đường hầm bọc mỗi gói tin trong một tiêu đề khác, nên kích thước dùng được bên trong nhỏ hơn kích thước bên ngoài. Gói tin được đo cho liên kết vật lý trước khi đóng gói sẽ trở nên quá lớn sau đó. Bộ định tuyến IPv4 có thể phân mảnh trên đường, trong khi bộ định tuyến IPv6 không làm vậy thay cho bên gửi, nên bên gửi phải tự điều chỉnh. Và việc điều chỉnh đó phụ thuộc hoàn toàn vào việc nhận được phản hồi.

Chỉ một thông điệp bị mất là đủ để tạo ra triệu chứng kinh điển: bắt tay và các phản hồi nhỏ thành công, còn danh sách thư mục hoặc tải lên bị treo ở cùng một điểm mỗi lần. Người dùng mô tả đó là VPN chậm, và nhật ký không cho thấy gì sai trong xác thực. Cả hai quan sát đều đúng và không cái nào xác định được vị trí lỗi.

Packet Too Big là phản hồi, không phải lưu lượng

Thông điệp ICMPv6 Packet Too Big mang kích thước mà bước nhảy tiếp theo có thể chấp nhận, và bên gửi dùng nó để hạ ước lượng của mình. Lọc nó tương đương với việc gỡ một biển báo đường rồi đổ lỗi cho tài xế. Một quy tắc loại bỏ toàn bộ ICMPv6 trông có vẻ nghiêm ngặt nhưng lại phá vỡ việc khám phá đường đi trên mọi liên kết cần đến nó. Thông điệp là thông tin điều khiển về đường đi, không phải dữ liệu tải của ứng dụng.

Lọc chọn lọc vẫn hợp lý. Yêu cầu echo và khám phá hàng xóm đóng vai trò khác với thông điệp lỗi, và chính sách có thể xử lý chúng khác đi. Hãy làm theo hướng dẫn lọc đã được tài liệu hóa của nền tảng thay vì chấp nhận hoặc loại bỏ toàn bộ giao thức, vì RFC 8201 định nghĩa cách phản hồi đó dẫn dắt việc khám phá.

Kiểm tra riêng từng họ địa chỉ

Hãy kiểm tra IPv6 riêng lẻ, vì một lần truyền IPv4 thành công không chứng minh được gì về đường đi IPv6. Sau đó bắt các thông điệp điều khiển trong khi lần truyền lớn bị treo. Hai bản ghi cùng nhau hoặc cho thấy phản hồi đang đi ra, hoặc chứng minh nó chưa bao giờ đến.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Bộ dò gửi một gói tin có đặt bit do-not-fragment và báo cáo kích thước mà tại đó nó thất bại, đó là con số mà đường hầm phải chứa. Truy vấn tuyến đường nêu tên giao diện sẽ mang đích đến, nên bạn biết MTU của liên kết nào đang áp dụng. Bản bắt lọc ICMPv6 loại 2, thông điệp Packet Too Big, và cho thấy nó có đến được máy chủ này hay không. Nếu thông điệp xuất hiện trong bản bắt mà việc truyền vẫn treo, bên gửi đang bỏ qua nó, điều này chuyển cuộc điều tra sang ngăn xếp thay vì mạng.

Chỉ chỉnh kích thước đường hầm sau khi có bằng chứng

Hạ MTU của đường hầm có thể che giấu một thông điệp bị lọc và làm triệu chứng biến mất, với cái giá là chi phí cao hơn trên mỗi gói tin. Đó là cách lách chứ không phải chẩn đoán, và nó nên theo sau bản bắt thay vì thay thế bản bắt. Một giá trị thấp tùy tiện cũng không phá vỡ gì nhìn thấy được, đó là lý do nó tồn tại trong cấu hình hàng năm. Hãy thay đổi nó một cách có chủ đích, ghi lại giá trị và ghi chú phép đo nào đã biện minh cho nó.

Khi bạn kiểm soát cổng, hãy xem xét quy tắc loại bỏ thông điệp thay vì tắt tường lửa. Một quy tắc đã sửa hẹp hơn một ngoại lệ chính sách và dễ bảo vệ hơn nhiều về sau. Lập luận tương tự áp dụng cho thời gian chờ: không phải mọi lần dừng là vấn đề kích thước, và bản bắt là thứ phân biệt hai điều đó.