Vì sao chặn toàn bộ ICMP làm hỏng một đường VPN đang hoạt động

Một đường hầm xác thực thành công, mang được một ping rồi treo ở lần truyền lớn đầu tiên là dấu hiệu kinh điển của một thông báo ICMP bị thiếu chứ không phải VPN hỏng. Bên gửi không bao giờ biết gói quá lớn, cứ thử lại cùng kích thước, và ứng dụng chờ đợi. Sửa điều này là quyết định chính sách tường lửa, không phải cài lại máy khách. Thứ tự quan trọng: đo xem ranh giới kích thước nằm ở đâu, rồi thu hẹp quy tắc đã nuốt báo cáo.

ICMP thực sự mang gì trên đường này

Khám phá MTU đường đi IPv4 dựa vào việc bộ định tuyến báo rằng gói có bit don't-fragment không thể chuyển tiếp. Báo cáo đó là thông báo ICMP Fragmentation Needed, và không có nó bên gửi không có lý do giảm kích thước phân đoạn. IPv6 nghiêm ngặt hơn: bộ định tuyến không phân mảnh khi truyền, nên thông báo ICMPv6 Packet Too Big là tín hiệu duy nhất khiến bên gửi thu nhỏ.

Cả hai thông báo đều là phản hồi của mặt phẳng điều khiển, và không cái nào là tiếng vọng chẩn đoán. Chính sách chặn ping và chính sách chặn toàn bộ ICMP trông giống nhau trong danh sách quy tắc nhưng hành xử rất khác trên mạng. Cái thứ hai có thể biến một đường hầm được định cỡ đúng thành đường một chiều cho bất cứ thứ gì lớn hơn mắt xích nhỏ nhất trong chuỗi.

Một số giao thức truyền tự thực hiện khám phá bằng gói thăm dò, như RFC 4821 mô tả, và chúng ít phụ thuộc vào phản hồi này. Đó là lý lẽ để kiểm tra bạn đang chạy giao thức truyền nào, không phải để cho rằng mọi đường hầm đều miễn nhiễm.

Lỗi phụ thuộc vào kích thước

Hỏi xem lỗi có tương quan với kích thước gói không. Trang đăng nhập, truy vấn DNS và lệnh gọi API ngắn đều qua, trong khi tải tệp lên, phản hồi lớn hoặc tải ảnh xuống bị treo. Kiểu mẫu đó chỉ ra một giới hạn kích thước ở đâu đó giữa hai đầu, không phải xác thực hay định tuyến. Một ping nhỏ thành công hầu như không nói gì về vị trí ranh giới đó.

Bên trong đường hầm có hai lớp cần xem xét: gói tải trọng và gói đóng gói bên ngoài. Bên gửi bên trong có thể hành xử đúng trong khi đường bên ngoài nhỏ hơn mức đường hầm giả định, vì vậy cả thiết lập MTU của chính đường hầm lẫn liên kết vật lý bên dưới đều quan trọng.

Đo trước khi sửa quy tắc

Thăm dò bằng bit don't-fragment và kích thước tải trọng do bạn chọn, từ máy khách lỗi về phía một địa chỉ được bảo vệ:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

Tải trọng 1472 byte cộng 28 byte tiêu đề tạo thành gói 1500 byte. Nếu phép thăm dò lớn thất bại với lỗi phân mảnh và cái nhỏ đi qua, bạn đã tìm ra ranh giới; điều chỉnh theo chi phí phụ của đường hầm và lặp lại cho đến khi kích thước hoạt động ổn định.

Sau đó xác nhận rằng khoảng trống chính là báo cáo. Nếu phép thăm dò thất bại im lặng, không lỗi và không trả lời, thông báo có lẽ đang bị bỏ chứ không được giao, và quy tắc là đối tượng tình nghi.

Thu hẹp quy tắc, rồi kiểm tra lại công việc

Bản sửa phải cho phép các thông báo điều khiển cụ thể, không phải toàn bộ giao thức. Trên máy chủ iptables hình thức là chấp nhận theo loại; điều chỉnh cú pháp cho phù hợp với thứ quản lý tường lửa trên nền tảng của bạn:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Hãy để trả lời tiếng vọng vẫn bị chặn nếu đó là chính sách cục bộ, vì đường không cần chúng. Sau đó kiểm tra lại lần truyền đã thất bại ban đầu, từ kết nối mới, và xác nhận rằng bộ đếm của quy tắc cho thấy thông báo đang đến.

Nếu lần truyền lớn vẫn treo sau khi thông báo được cho phép, giới hạn còn lại nằm ở chỗ khác: MTU đường hầm đặt quá cao, proxy ghi lại gói, hoặc hộp trung gian bỏ gói thay vì báo cáo. Quy tắc ICMP là cần thiết, chưa đủ.