Gói lớn biến mất qua IPsec trong khi ping nhỏ vẫn hoạt động

Các shell từ xa vẫn phản hồi, các phép thử nhỏ vẫn trả lời, rồi một bản sao tệp bò chậm và đình trệ mà không có lỗi nào để ai đó chỉ ra. Ping với tải trọng lớn hơn tái hiện điều đó ngay lập tức, và cùng một lần truyền lại chạy được từ mạng cục bộ. Không có gì chậm trong việc mã hóa; một số gói không bao giờ đến. Hai cách chia khác nhau có thể tạo ra dấu hiệu đó, và chúng để lại bằng chứng khác nhau.

Hai nơi có thể chia một gói

Trước khi mã hóa, router có thể chia một gói bên trong quá lớn và bảo vệ từng phần riêng biệt. Sau khi mã hóa, thứ bị chia là gói bên ngoài đã hoàn chỉnh, và đầu xa phải lắp lại nó trước khi giải mã được bất cứ thứ gì. Cùng triệu chứng, công việc khác cho bên nhận và các nút điều chỉnh khác cho bạn.

Sự phân biệt này quan trọng vì một bản sửa nhắm vào phía sai chỉ đổi một con số mà không di chuyển lỗi. Gói bị từ chối ở giao diện không bao giờ trở thành gói bên ngoài, nên không cấu hình nào ở phía ngoài cứu được nó.

Quyết định kích thước thực sự được đưa ra ở đâu

Một giao diện đường hầm mang một IP MTU, và giá trị đó có thể từ chối một gói bên trong quá lớn rất lâu trước khi giai đoạn IPsec nhìn thấy nó. Đặt một bit trên tiêu đề bên ngoài không xem xét lại quyết định trước đó, vì gói đã bị từ chối. Đó là lý do việc tăng MTU bên trong đôi khi làm mọi thứ tệ hơn thay vì tốt hơn. Hãy đọc giá trị giao diện và hành vi bên ngoài trước khi thay đổi bất kỳ cái nào, vì thay đổi rẻ hơn thường là cái giải thích triệu chứng.

Kiểm tra giá trị giao diện trước, rồi đến hành vi bên ngoài. Hai con số, hai giai đoạn, và thường chỉ một trong hai chịu trách nhiệm.

Ngân sách bên ngoài không phải ngân sách bên trong

Mỗi lần đóng gói tiêu tốn byte cho tiêu đề, và lượng này phụ thuộc vào giao thức vận chuyển, họ địa chỉ và việc có NAT traversal hay không. Một gói bên trong vừa với liên kết cục bộ vẫn có thể tạo ra gói bên ngoài không vừa với đường đi phía sau nó. Hãy đo phần phụ trội thay vì giả định, vì mỗi tiêu đề tùy chọn đều cộng vào hóa đơn. Một đường hầm có NAT traversal trả nhiều hơn đường hầm trần, và chênh lệch đủ để phá một lần truyền đã chạy hôm qua.

Khi gói bên ngoài mang bit cấm phân mảnh, một chặng không thể chuyển tiếp sẽ bỏ nó và nên trả về thông điệp ICMP. Nếu thông điệp đó bị lọc ở đâu đó, bên gửi tiếp tục thử lại và người dùng thấy đình trệ mà không có lời giải thích. Chính việc bỏ im lặng đó là lý do thường gặp khiến một vấn đề kích thước bị báo cáo như vấn đề tốc độ.

IPv6 loại bỏ một trong các tùy chọn

Router IPv6 không phân mảnh khi truyền, nên gói bên ngoài hoặc vừa hoặc biến mất cùng thông điệp Packet Too Big. Thông điệp đó trở thành kênh phản hồi duy nhất, và chặn nó sẽ phá việc tìm đường cho mọi lần truyền lớn tiếp theo. Router IPv4 có thể phân mảnh gói lớn khi bit được xóa, điều này che giấu lỗi cho đến khi có thứ khác đặt bit đó.

Trên một ngăn xếp hỗn hợp, cùng một đường hầm có thể hành xử khác nhau với hai họ, vì thế một phép thử trên IPv4 không giải quyết khiếu nại về IPv6. Một kiểm tra chỉ luyện một họ để nửa câu trả lời không được đo.

Chính sách phân đoạn TCP không phải câu trả lời chung

Giới hạn kích thước phân đoạn tối đa giúp các luồng TCP, và đó là biện pháp chính đáng khi vấn đề chỉ giới hạn ở chúng. Nó không có tác dụng với UDP, giao thức mang DNS, một số giao thức thoại và phần ngày càng lớn của lưu lượng web.

Hãy áp dụng rồi thử lại khối lượng công việc đã thất bại. Nếu trường hợp UDP vẫn thất bại thì chính sách phân đoạn chưa bao giờ là câu trả lời và ngân sách giao diện vẫn cần được chú ý. Trước hết hãy xác định giao thức của khối lượng thất bại, rồi chọn biện pháp phù hợp với nó.

Thứ tự làm việc

Ghi lại tải trọng lớn nhất còn sống, rồi MTU giao diện, rồi việc gói bên ngoài có mang bit cấm phân mảnh hay không, và cuối cùng là phản hồi ICMP có tới được bên gửi hay không. Trình tự đó thu hẹp lỗi mà không phải đoán. Giữ mọi quan sát kèm dấu thời gian và điểm cuối, vì cả bốn con số đều dịch chuyển khi đường đi thay đổi.

Đổi một giá trị, thử lại lần truyền ban đầu và giữ kết quả. Một đường hầm qua được phép thử lớn nhưng vẫn đình trệ ở ứng dụng đã chuyển sang vấn đề khác, và đó là tiến bộ đáng ghi lại. Người tiếp theo muốn các con số hơn là kết luận.