IPsec nhiều subnet mất lưu lượng quay về? Đếm các reqid

Lưu lượng rời một điểm và không bao giờ quay lại, cả hai cổng đều báo cáo thương lượng đã hoàn tất, và manh mối duy nhất là một đống gói tin đi ra không có phản hồi. Trên một điểm cuối Linux, nguyên nhân thông thường không phải là độ mạnh mã hóa, MTU hay bảng định tuyến. Đó là độ chi tiết của các mục chính sách và con số liên kết mỗi chính sách với một hiệp hội bảo mật. Quy trình dưới đây đọc hai cơ sở dữ liệu đó trước khi chạm vào bất cứ thứ gì khác.

Tách triệu chứng trước khi thay đổi bất cứ điều gì

Một sự cố một chiều với thương lượng IKE đã hoàn tất thu hẹp vấn đề vào đường dữ liệu. Hoặc chính sách đi ra khớp và phản hồi bị loại bỏ, hoặc phản hồi không bao giờ đến vì phía bên kia không có gì để gửi nó. Từ góc nhìn ứng dụng, cả hai trông giống nhau, và các cơ sở dữ liệu xfrm phân biệt chúng.

Đừng bắt đầu với MTU. MTU sai gây ra tắc nghẽn và triệu chứng phân mảnh, không phải sự tách hướng sạch sẽ với bộ đếm đi ra tăng lên.

Đọc cơ sở dữ liệu chính sách và cơ sở dữ liệu trạng thái

Trên Linux, mã hóa do các mục chính sách quyết định, vì vậy một chính sách khớp, không phải một tuyến đường, mới đưa gói tin vào đường hầm. Chạy ip xfrm policy để xem bộ chọn, hướng, mức ưu tiên và mẫu của từng mục, và ip xfrm state để xem các hiệp hội đã thiết lập cùng reqid của chúng. Chính sách và hiệp hội được nối với nhau bằng reqid đó.

Xem cả ba hướng. Đi ra và đi vào bao phủ lưu lượng đến và từ máy này; hướng chuyển tiếp quan trọng khi máy định tuyến cho người khác. Một mục thiếu hoặc không khớp ở một hướng giải thích kết quả một chiều mà không có lỗi mật mã nào.

Bất đối xứng kinh điển: một reqid cho nhiều subnet

Một sự cố phổ biến đến từ một đối tác cài đặt chính sách cho tất cả subnet đã thương lượng dưới một reqid duy nhất, điều xảy ra với generate_policy require của racoon. Lưu lượng sau đó đi ra qua hiệp hội được thiết lập cuối cùng, trong khi phía bên kia giữ một hiệp hội riêng cho mỗi subnet. Phản hồi đến trên một hiệp hội mà reqid không chỉ ra chính sách lẽ ra phải chấp nhận chúng, và nhân loại bỏ chúng sau khi giải mã.

Cách sửa là thay đổi cấu hình, không phải quy tắc tường lửa: generate_policy unique; cấp cho mỗi chính sách reqid riêng, để các hiệp hội theo chính sách của đối tác có các đối tác khớp. Hãy áp dụng, thương lượng lại, và đếm các reqid khác nhau cho các subnet bạn mong đợi trước khi tuyên bố thành công.

Nếu hai subnet vẫn chia sẻ một reqid trong khi phía bên kia mong đợi hai, bạn đã tìm ra bất đối xứng. Ghi lại ánh xạ, vì đó là bằng chứng rằng thay đổi tiếp theo đã sửa hoặc giữ nguyên nó.

Bộ chọn đến từ thương lượng, không phải từ cấu hình của bạn

Các dải được bảo vệ là những gì cả hai đầu đã đồng ý, không phải những gì một bên yêu cầu. Một máy khách đề nghị một cặp máy so với một dải từ xa rộng sẽ nhận phiên bản thu hẹp của cổng, và máy khách không thể mở rộng nó. Đọc các bộ chọn đã cài đặt thay vì những bộ trong tệp cục bộ của bạn.

Khi mục tiêu là ngược lại, giữ một đích ngoài đường hầm, hãy thêm một chính sách bỏ qua với số ưu tiên thấp hơn để nó thắng mục được cài tự động. Một chính sách không có mẫu cho phép văn bản rõ, điều này biến nó thành một ngoại lệ có chủ ý cho hồ sơ thay đổi thay vì một bước gỡ lỗi.

Xác minh theo thứ tự này, và biết cách quay lại

Liệt kê chính sách cho mỗi subnet ở cả hai hướng, bao gồm chuyển tiếp nếu máy định tuyến. Đếm các reqid khác nhau và xác nhận một reqid cho mỗi chính sách ở phía mong đợi nó. So sánh các bộ chọn đã cài đặt với những bộ đã thương lượng. Đọc lại bộ đếm theo hiệp hội sau khi gia hạn khóa, vì hiệp hội bạn đã kiểm tra có thể đã biến mất. Kiểm tra tuyến đường sau cùng, vì thiếu tuyến đến subnet từ xa tạo ra triệu chứng một chiều tương tự với bộ đếm chính sách sạch.

Trước khi thay đổi đối tác, hãy lưu đầu ra hiện tại của cả hai lệnh xfrm. Nếu cài đặt mới không khôi phục hướng quay về, khôi phục đầu ra đó là cách hoàn tác nhanh hơn so với xây dựng lại đường hầm từ trí nhớ, và nó giữ cho việc so sánh trung thực.