Но НАТ кажется лишним. Так как в GRE уже указаны source ip и dst ip, с которого и куда он будет строиться (который и попадает под политику). И касаемо site2site сетей, сервисы, насколько я понимаю, будут жить в сети 10.45.8.16/28 и обращаться к сети 10.15.30.0/24 (что также попадает под политику).
И мту на gre1 интерфейсе не 1476 будет. Там же у вас не чистый gre, а плюсом ipsec в туннельном режиме.
Расскажите чуть подробнее, с чем связан именно такой дизайн 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 :)
Когда мы поднимали ip/mpls в облаке для L3VPN, вторая головная боль после отладки и настройки этого дела -- была настройка сервисов после ребута "коробки" (создание VRFa и "помещения" интерфейсов внутрь него).
Сначала тоже юзали самописные скрипты, но потом начали копать в сторону штатных средств systemd-networkd или NetworkManager. Остановились на 2м :)
Стало чуть яснее.
Но НАТ кажется лишним. Так как в GRE уже указаны source ip и dst ip, с которого и куда он будет строиться (который и попадает под политику). И касаемо site2site сетей, сервисы, насколько я понимаю, будут жить в сети 10.45.8.16/28 и обращаться к сети 10.15.30.0/24 (что также попадает под политику).
И мту на gre1 интерфейсе не 1476 будет. Там же у вас не чистый gre, а плюсом ipsec в туннельном режиме.
Приветствую!
Расскажите чуть подробнее, с чем связан именно такой дизайн 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 :)
Ну и еще, если нужен LDP
Скорее в vrf :) С systemd вместе с dummy интерфейсами что-то не заладилось, уже точно не вспомню что
Да, отчасти согласен.
Когда мы поднимали ip/mpls в облаке для L3VPN, вторая головная боль после отладки и настройки этого дела -- была настройка сервисов после ребута "коробки" (создание VRFa и "помещения" интерфейсов внутрь него).
Сначала тоже юзали самописные скрипты, но потом начали копать в сторону штатных средств systemd-networkd или NetworkManager. Остановились на 2м :)