IPv4 phân mảnh trên đường đi; IPv6 thay vào đó gửi thông báo gói quá lớn

Các lỗi IPv6 thường bị quy cho giao thức nhiều hơn là kích thước gói đã gây ra chúng. Hai họ thực sự xử lý một gói quá lớn theo cách khác nhau, và đường hầm chính là thứ khiến sự khác biệt đó trở nên quan trọng. Bộ định tuyến IPv4 có thể phân mảnh một gói khi các quy tắc cho phép, trong khi bộ định tuyến IPv6 không được phân mảnh trên đường đi chút nào. IPv6 thay vào đó nói với bên gửi, và bên gửi được kỳ vọng sẽ phản ứng. Mọi thứ hỏng sau đó đều phụ thuộc vào việc thông báo ấy có đến hay không.

Mỗi họ làm gì

Bảng là cơ chế trong bốn dòng, và một dòng giải thích phần lớn sự nhầm lẫn.

IPv6 không có phân mảnh trên đường đi và không có cờ DF để xóa, nên không có gì để dựa vào khi gói quá lớn. Phải nói cho bên gửi biết, và bên gửi phải tin điều đó.

Đường hầm thu hẹp đường đi một cách lặng lẽ

VPN thêm các tiêu đề bên ngoài, và trong trường hợp mã hóa cả dữ liệu toàn vẹn, trước khi gói rời khỏi máy chủ. Gói bên trong có thể vừa với MTU của giao diện mà nó thấy trong khi gói bên ngoài vượt quá giới hạn của liên kết tiếp theo, và đó là lý do hiện tượng này xuất hiện trước tiên trong một đường hầm. Hãy chủ động hạ MTU của giao diện đường hầm, hoặc siết TCP MSS trên đường đi, và ghi lại con số bạn chọn cùng lý do.

Phần phụ trội ESP phụ thuộc vào chế độ và thuật toán, nên MTU đường hầm đúng là một phép tính chứ không phải quy ước. Dù bạn chọn gì, nó phải chừa chỗ cho một gói IPv6 bên trong đầy đủ 1280 byte, vì mọi liên kết IPv6 đều phải mang được chừng đó. Một đường hầm không mang được 1280 byte IPv6 không phải là vấn đề tinh chỉnh; đó là đường đi hỏng cho họ giao thức đó. Chính ràng buộc ấy biến mất khi một giá trị MTU được sao chép từ một triển khai chỉ dùng IPv4.

Vì sao triệu chứng trông như bị treo

Sự cố không phải là một lỗi sạch sẽ, và đó là lý do nó bị chẩn đoán sai. Một bắt tay TCP hoàn tất, các phản hồi nhỏ đến, và kết nối đứng lại ngay khi một phản hồi lớn hoặc một lần tải lên lớn bắt đầu, vì đó là những gói đầu tiên đủ lớn để bị bỏ. SSH kết nối rồi treo ở lần xuất lớn đầu tiên, và phần đầu của trang tải được trong khi phần thân không bao giờ xong.

Nếu các thông báo gói quá lớn của ICMPv6 bị lọc, bên gửi không bao giờ biết và cứ thử lại cùng kích thước. Đó là một lỗ đen chứ không phải đường chậm, và dấu hiệu của nó là một ranh giới kích thước lặp lại được chứ không phải mất mát ngẫu nhiên. Cho phép lưu lượng điều khiển liên quan là một phần của triển khai IPv6 hoạt động được, không phải một cử chỉ lịch sự.

Đừng tắt những thông báo mà đường đi của chính bạn phụ thuộc vào rồi mô tả kết quả như một lỗi IPv6. Lập luận tương tự áp dụng cho các thông báo Fragmentation Needed của IPv4, vốn cũng không được lòng tác giả tường lửa và cũng cần thiết như vậy.

Đo ranh giới, rồi sửa tầng

Hãy kiểm chứng thay vì đoán: dùng cờ don't-fragment trên IPv4 và các kích thước tải trọng cố định trên IPv6, và ghi lại nơi các phản hồi dừng lại. ping -M do -s 1472 và ping -6 -s 1400 là đủ để xác định hình dạng của vấn đề, và tracepath báo cáo MTU đường đi đã phát hiện trên đường.

Sau đó sửa tầng sở hữu con số đó: MTU của giao diện đường hầm, việc siết MSS cho TCP, hoặc chính đường đi. RFC 8200 là tài liệu tham chiếu cho quy tắc IPv6, và nó ngắn hơn sự cố mà nó ngăn ngừa.

Hãy kiểm tra họ giao thức mà ứng dụng thực sự dùng, vì một tên hai ngăn xếp có thể trả lời trên một họ và không trả lời trên họ kia, và ứng dụng có thể chuyển sau một thay đổi mạng. Ghi lại địa chỉ bạn đã kiểm tra, vì kết quả với bản ghi A không nói gì về bản ghi AAAA.

Coi ranh giới kích thước là bằng chứng

Một ranh giới kích thước lặp lại được là một trong số ít sự cố mạng tái hiện chính xác, ở cùng số byte, từ cùng nguồn, mỗi lần. Điều đó biến nó thành một món quà chứ không phải điều bí ẩn, và cũng có nghĩa là một bản sửa có thể được xác minh thay vì hy vọng.

Ghi vào phiếu MTU đã phát hiện, MTU đường hầm bạn đã cấu hình và bài kiểm tra đã chứng minh sự khác biệt. Người tiếp theo sẽ gặp đúng phép tính đó trên một liên kết khác.