Почему для туннеля IPsec необходимы только 3 политики ip xfrm?

У меня есть туннель IPsec между strongswanсайтами и работает между экземпляром (v5.2.0) (сайт A) и RouterOSмаршрутизатором (сайт B). Все работает нормально, узлы в двух частных подсетях, настроенные для сайтов A ( 10.10.0.0/16) и B ( 10.50.0.0/16), могут нормально общаться друг с другом.

Что я не понимаю, хотя это следующий вывод ip xfrm policyна маршрутизаторе сайта А (общедоступные 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). Но я все еще могу успешно пинговать, например, 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) указан только для исходящего маршрута.

Это подтверждает , что есть на самом деле нет необходимости вперед политика на маршрутизаторе узла А для перенаправления 10.10.0.0/16на 10.50.0.0/16через туннель IPsec, но я не понимаю , почему.

Спасибо за любые объяснения!

В FWD политика не автоматически генерируется ядром , но вместо того, чтобы получить установлен на манипуляция демона (strongSwan в данном случае).

Они необходимы для того, чтобы трафик передавался на хосты и позади хостов за шлюзом VPN в туннельном режиме.

Для входящего пакета, который является адресом IP, который не установлен на самом шлюзе, политика fwd ищется после расшифровки. Для локального трафика ищется соответствие в политике. Если ничего не найдено, пакет отбрасывается.

Для исходящего трафика, который не был сгенерирован на самом шлюзе VPN, ищется политика fwd . Если пакет не был зашифрован, это не будет ошибкой, если не найдена соответствующая политика fwd . И если трафик передается между двумя туннелями, политика входящего fwd, установленная с одним, будет действовать как политика исходящего fwd для другого и наоборот. После этого ищется политика out, чтобы решить, следует ли туннелировать пакет. Вот почему политика FWD в исходящем направлении часто не требуется.

Однако, если, например, существует политика удаления / блокировки fwd с низким приоритетом, которая соответствует всему (например, чтобы избежать прохождения трафика через открытый текст, если не установлены туннели), политика fwd в исходящем направлении явно требуется, так как политика блокировки будет в противном случае отбросьте весь незашифрованный трафик. Вот почему strongSwan начал устанавливать политики fwd в обоих направлениях с 5.5.0 .

В предыдущей версии этого ответа говорилось, что единая (входящая) политика fwd является симметричной (т. Е. Что src и dst работают в любом направлении). Это не так, но, как объяснялось выше, во многих ситуациях это не имеет значения.