IPsec 터널에 3 개의 IP xfrm 정책 만 필요한 이유는 무엇입니까?

strongswan(v5.2.0) 인스턴스 (사이트 A)와 RouterOS라우터 (사이트 B) 사이에 사이트 간 IPsec 터널이 실행 중 입니다. 사이트 A ( 10.10.0.0/16) 및 B ( 10.50.0.0/16) 에 대한 두 개의 프라이빗 서브넷 설정의 호스트는 서로 올바르게 통신 할 수 있습니다.

내가 이해하지 못하는 것은 ip xfrm policy사이트 A의 라우터 (공용 IP가 난독 화 된) 의 다음 출력입니다 . 이 정책은에 의해 작성되었으며 strongswan수동으로 설치하거나 수정하지 않았습니다.

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

입력 및 출력에 대한 정책이 각각 있지만 사이트 B에서 사이트 A로 전달하는 정책은 하나뿐입니다. 하지만 난 여전히 성공적으로, 예를 들어, Ping 할 수 있습니다 10.50.4.11에서 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

이 경로 추적에 대한 흥미로운 부분은 사이트 A의 라우터 ( 10.10.0.2)가 Ping 대상에서 되돌아 오는 경로에만 표시되고 사이트 B의 라우터 ( 10.50.0.1)는 발신 경로에 대해서만 나열 된다는 것 입니다.

이것은 실제로 사이트 A의 라우터에 IPsec 터널 10.10.0.0/16을 10.50.0.0/16통해 전달하는 데 필요한 정방향 정책이 없음 을 확인하는 것처럼 보이지만 그 이유를 이해하지 못합니다.

설명해 주셔서 감사합니다!

FWD 정책은 하지 자동으로 커널에 의해 생성 된 대신 키잉 데몬 (이 경우 strongSwan)에 의해 설치 얻을.

터널 모드에서 VPN 게이트웨이 뒤의 호스트로 트래픽을 전달할 수 있어야합니다.

게이트웨이 자체에 설치되지 않은 IP 주소 인 인바운드 패킷의 경우 암호 해독 후 fwd 정책이 검색됩니다. 로컬 트래픽의 경우 정책 에서 일치하는 항목 을 찾습니다. 아무것도 발견되지 않으면 패킷이 삭제됩니다.

VPN 게이트웨이 자체에서 생성되지 않은 아웃 바운드 트래픽의 경우 fwd 정책이 검색됩니다. 패킷이 암호화되지 않은 경우 일치하는 fwd 정책이 없으면 실패하지 않습니다 . 두 터널 사이에 트래픽이 전달되면 하나의 방화벽으로 설치된 인바운드 fwd 정책 이 다른 방화벽의 아웃 바운드 fwd 정책으로 작동 하고 그 반대의 경우도 마찬가지입니다. 그 후, 패킷을 터널링할지 여부를 결정하기 위한 아웃 정책이 조회됩니다. 그렇기 때문에 아웃 바운드 방향 의 fwd 정책이 필요하지 않은 경우가 많습니다.

그러나 모든 우선 순위와 일치하는 우선 순위가 낮은 드롭 / 블록 fwd 정책이있는 경우 (예 : 터널이 설정되지 않은 경우 일반 텍스트 트래픽이 게이트웨이를 통과하지 못하도록) 차단 정책 에 따라 아웃 바운드 방향 의 fwd 정책이 명시 적으로 필요합니다. 그렇지 않으면 암호화되지 않은 모든 트래픽을 삭제하십시오. strongSwan 설치를 시작하는 이유입니다 FWD 와 양쪽 방향으로 정책을 5.5.0 .

이 답변의 이전 버전에서는 단일 (인바운드) fwd 정책이 대칭 적이라고 설명했습니다 (즉, src 및 dst 가 어느 방향 으로든 작동 함). 사실이 아니지만 많은 상황에서 위에서 설명한 것처럼 이것은 중요하지 않습니다.