ESP giải mã tốt nhưng gói bên trong vẫn không đi đến đâu

Bộ đếm nhận ESP tăng lên, đường hầm vẫn hoạt động, và ứng dụng không bao giờ thấy gói tin. Việc giải mã đã chạy, kiểm tra toàn vẹn đã qua, rồi bên nhận phải quyết định phần tải được bảo vệ thực sự là gì. Chính ở bước cuối đó mới xuất hiện sự không khớp định dạng, và nhìn từ bên ngoài nó không giống một vấn đề tường lửa chút nào.

Bạn thấy gì khi nhãn nói dối

Không có gì trong nhật ký máy khách phân biệt được điều này với một hố đen định tuyến. Cả hai đều tạo ra thời gian chờ của ứng dụng bên cạnh một đường hầm khỏe mạnh, nên bộ đếm là thứ bị đổ lỗi trước.

Bộ đếm nhận tăng lên thực sự là tin tốt: các gói đến và được xác thực. Nhưng đó không phải bằng chứng rằng gói bên trong có ý nghĩa với bất cứ thứ gì phía trên lớp mã hóa.

Kiểu nằm trong trailer

Trong chế độ đường hầm IPsec thông thường, phần tải được ESP bảo vệ chứa một gói IP bên trong hoàn chỉnh. Trường tiêu đề tiếp theo trong trailer xác định phần tải đó là gì, và nó không phải cổng TCP, không phải số giao thức trong tiêu đề ngoài, và không phải một phần của trường SPI cùng số thứ tự ban đầu. RFC 4303 mục 2.6 định nghĩa nó là trường kiểu tải, một cái tên chính xác cho một công việc chính xác.

Các giá trị bạn sẽ gặp đều nhỏ và đáng ghi nhớ: IPv4 là 4 (0x04) và IPv6 là 41 (0x29).

Những con số đó đến từ việc phân bổ số giao thức của IANA chứ không phải từ quy ước địa phương. Một bên gửi khai báo IPv4 trong khi đóng gói gói IPv6 đã tạo ra sự không nhất quán về định dạng, và không quy tắc tường lửa nào sửa được những byte mâu thuẫn với nhãn của chính chúng.

Cách phân biệt với những nghi phạm thường gặp

Phần lớn gói bị mất không phải lỗi mã hóa. Hãy kiểm tra bộ chọn trước, vì một bộ chọn lưu lượng loại trừ tiền tố IPv6 sẽ bỏ lưu lượng trước khi bất cứ thứ gì được đóng gói. Sau đó kiểm tra định tuyến, rồi lọc cục bộ trên máy nhận. Chỉ sau khi loại trừ những điều đó thì sự không khớp định dạng tải mới trở thành lời giải thích hợp lý.

Một bản bắt gói đã mã hóa sẽ không giải quyết được, vì tiêu đề tiếp theo được bảo vệ nằm bên trong phần tải đã mã hóa. Bạn cần chẩn đoán của bản triển khai hoặc một điểm quan sát đã giải mã được hỗ trợ, và cả hai đều cần được phép trước khi dùng.

Nếu không ai đưa ra được bằng chứng đó, bạn không có lỗi định dạng. Bạn có một giả thuyết, và bộ chọn vẫn là đặt cược tốt hơn.

Điều mà việc sửa chữa không phải là

Đừng tắt các kiểm tra toàn vẹn để lưu lượng đi qua. Đừng ghi lại các gói đã mã hóa trên bộ định tuyến trung gian, vì việc đó không thể hoạt động và sẽ làm hỏng luồng trong khi trông có vẻ hữu ích trong bản bắt gói. Đừng mở một quy tắc tường lửa ứng dụng rộng hơn với giả thuyết rằng một cổng đang bị chặn. Không điều nào trong số đó chạm tới sự không khớp nhãn.

Nếu một sự không khớp đã được xác nhận đến từ bản triển khai đối tác, hãy giữ một bản tái hiện tối thiểu đã làm sạch và mang nó tới kênh hỗ trợ của bản triển khai đó.

Hãy kiểm chứng luồng, không phải bộ đếm

Sau khi sửa, hãy thử luồng IPv6 thực tế từ đầu đến cuối: một yêu cầu của ứng dụng qua đường hầm, phản hồi của nó, và cặp địa chỉ mà mỗi bên quan sát. Bộ đếm ESP tăng chỉ chứng minh rằng các gói đang được nhận và xác thực. Nó không nói gì về việc gói bên trong có dùng được hay không.

Ghi cả hai kết quả vào phiếu. Bộ đếm chuyển động cùng một luồng hoạt động là đã sửa; chỉ bộ đếm chuyển động thì đúng là tình trạng bạn có trước khi bắt đầu.