Tại sao chỉ có 3 chính sách xfrm ip cần thiết cho một đường hầm IPsec?

Tôi có một đường hầm IPsec tại chỗ và chạy giữa một phiên bản strongswan(v5.2.0) (trang A) và RouterOSbộ định tuyến (trang B). Mọi thứ đều hoạt động tốt, các máy chủ trong hai thiết lập mạng con riêng cho trang A ( 10.10.0.0/16) và B ( 10.50.0.0/16) có thể giao tiếp với nhau tốt.

Tuy nhiên, điều tôi không hiểu là đầu ra sau ip xfrm policycủa bộ định tuyến A trên trang web (IP công cộng bị xáo trộn). Các chính sách của luận án được tạo bởi strongswan, tôi không tự cài đặt hoặc sửa đổi chúng:

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

Có một chính sách cho mỗi đầu vào và đầu ra, nhưng chỉ có một chính sách để chuyển tiếp (từ trang B đến trang A). Nhưng tôi vẫn có thể ping thành công, ví dụ, 10.50.4.11từ 10.10.0.89:

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

Phần thú vị về theo dõi lộ trình này là bộ định tuyến của trang A ( 10.10.0.2) chỉ hiển thị trên tuyến trở lại từ mục tiêu ping, trong khi bộ định tuyến của trang B ( 10.50.0.1) chỉ được liệt kê cho tuyến đi.

Điều này dường như xác nhận rằng có thực sự chính sách không mong cần thiết trên router Một website về để chuyển tiếp 10.10.0.0/16để 10.50.0.0/16qua đường hầm IPsec, nhưng tôi không hiểu tại sao.

Cảm ơn cho bất kỳ lời giải thích!

Các chính sách fwd không được tạo tự động bởi kernel mà thay vào đó được cài đặt bởi daemon keying (strongSwan trong trường hợp này).

Họ được yêu cầu cho phép lưu lượng truy cập được chuyển tiếp đến và từ các máy chủ phía sau cổng VPN ở chế độ đường hầm.

Đối với gói gửi đến có địa chỉ IP không được cài đặt trên cổng, chính sách fwd được tìm kiếm sau khi giải mã. Đối với giao thông địa phương một kết hợp trong chính sách đang nhìn lên. Nếu không tìm thấy gói tin bị rơi.

Đối với lưu lượng truy cập đi không được tạo trên cổng VPN, chính sách fwd được tìm kiếm. Nếu gói không được mã hóa thì sẽ không có lỗi nếu không tìm thấy chính sách fwd phù hợp . Và nếu lưu lượng được chuyển tiếp giữa hai đường hầm, chính sách fwd gửi đến được cài đặt với một đường dẫn sẽ đóng vai trò là chính sách fwd gửi đi cho đường kia và ngược lại. Sau đó, một chính sách out được tìm kiếm để quyết định có nên tạo đường hầm cho gói không. Đó là lý do tại sao một chính sách fwd theo hướng ra ngoài thường không được yêu cầu.

Tuy nhiên, nếu có một chính sách fwd thả / chặn với mức độ ưu tiên thấp phù hợp với mọi thứ (ví dụ: để tránh lưu lượng văn bản rõ ràng đi qua cổng nếu không có đường hầm được thiết lập), chính sách fwd theo hướng đi được yêu cầu rõ ràng vì chính sách chặn sẽ mặt khác thả tất cả lưu lượng không được mã hóa. Đó là lý do tại sao StrongSwan bắt đầu cài đặt các chính sách fwd theo cả hai hướng với 5.5.0 .

Một phiên bản trước của câu trả lời này đã tuyên bố rằng chính sách fwd (trong nước) là đối xứng (nghĩa là src và dst hoạt động theo một trong hai hướng). Điều đó không đúng, nhưng như đã giải thích ở trên trong nhiều tình huống, điều này không thành vấn đề.