Comments 4
Приветствую!
Расскажите чуть подробнее, с чем связан именно такой дизайн ipsec? Несколько ipsec политик и NAT выглядят как попытка "потушить пожар" :)
Если со стороны "customer VM" есть публичный айпи, то тогда можно же сделать классический gre-over-ipsec. Будет более прозрачно. Имеем одну политику для ipsec и отсутствие НАТа.
Если со стороны "customer VM" нет публичного айпи, то тогда можно сделать site2site для /32 адресов, поверх которых уже построить GRE. Опять таки, повышается прозрачность конфигурации, отсутствие НАТа. (Не забываем про МТУ).
Если сервер и клиент - тачки на линукс, то тогда можно посмотреть в сторону ipsec VTI, или XFRM интерфейсов (зависит от версии ядра и версии iproute2). Насколько помнится, они поддерживают mcast.
Ну и в целом, рассмотреть переход от deprecated stroke-based scenarios (ipsec.conf и ipsec команды) к swanctl :)
Виктор, спасибо за комментарий.
Наверное я зря не пояснил в статье, что:
На AWS виртуальные машины имеют локально только приватные адреса, NAT которых выполняет Internet Gateway. (Но конечно можно привязать выделенный публичный Elsatic IP для каждого приватного адреса).
Несколько политик скорее обусловлено дизайном подключения со стороны "DataCenter". Они отдельно дают классический IPsec для TCP коммуникации (настроен в conn dc-tun-tcp), и отдельно дают IPsec для построения GRE внутри (настроен в conn dc-tun-gre), как вы и предположили "site2site для /32 адресов, поверх которых уже построить GRE". По сути так и сделано. По GRE уже разрешены только кипэлайвы и мультикаст (политика с той стороны).
Со стороны "DataCenter" точно Cisco, но не скажу модель.
Спасибо что обратили внимание на swanctl, действительно, стоит переезжать.
Стало чуть яснее.
Но НАТ кажется лишним. Так как в GRE уже указаны source ip и dst ip, с которого и куда он будет строиться (который и попадает под политику). И касаемо site2site сетей, сервисы, насколько я понимаю, будут жить в сети 10.45.8.16/28 и обращаться к сети 10.15.30.0/24 (что также попадает под политику).
И мту на gre1 интерфейсе не 1476 будет. Там же у вас не чистый gre, а плюсом ipsec в туннельном режиме.
NAT для tcp был нужен, так как клиенты по tcp обращаются в 10.15.30.0/24, но source IP из многих подсетей, а та сторона (условный “DataCenter”) принимает в конфиг только одну подсеть с моей стороны.
Для GRE же NAT в принципе не нужен, но он не мешает, и облегчал отладку скрипта который слал PIM join в сторону 10.44.4.5. Я мог это делать тоже из другой подсети.
GRE + IPSec чтобы слушать multicast в облаке