У меня есть туннель IPsec между сайтами, который работает между strongswan (v5.2.0) экземпляр (сайт A) и RouterOS роутер (сайт Б). Все работает нормально, хосты в двух частных подсетях настроены для сайта 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). Но я все еще могу успешно пинговать, например, 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 для пересылки 10.10.0.0/16 к 10.50.0.0/16 через туннель IPsec, но я не понимаю почему.
Спасибо за любые объяснения!
В вперед политика не автоматически генерируется ядром, но вместо этого устанавливается демоном ключей (в данном случае strongSwan).
Они необходимы для того, чтобы разрешить пересылку трафика к узлам за шлюзом VPN и от них в туннельном режиме.
Для входящего пакета, который является адресом IP, который не установлен на самом шлюзе, вперед политика ищется после расшифровки. Для местного трафика соответствие в политика ищется. Если ничего не найдено, пакет отбрасывается.
Для исходящего трафика, который не был создан на самом шлюзе VPN, вперед политика ищется. Если пакет не был зашифрован, это не ошибка, если нет соответствия вперед политика найдена. И если трафик пересылается между двумя туннелями, входящий вперед установленная политика будет действовать как исходящая вперед политика для другого и наоборот. Впоследствии вне политика просматривается, чтобы решить, следует ли туннелировать пакет. Вот почему вперед политика в исходящем направлении часто не требуется.
Однако, если есть, например, капля / блок вперед политика с низким приоритетом, которая соответствует всему (например, чтобы избежать прохождения трафика открытого текста через шлюз, если не установлены туннели) вперед политика в исходящем направлении явно требуется, поскольку блокировать В противном случае политика сбросит весь незашифрованный трафик. Вот почему strongSwan начал устанавливать вперед политики в обоих направлениях с 5.5.0.
В предыдущей версии этого ответа говорилось, что одиночный (входящий) вперед политика симметрична (т.е. src и dst работать в любом направлении). Это неправда, но, как объяснялось выше, во многих ситуациях это не имеет значения.