openswan несколько проблем маршрутизации подсетей

Когда вы используете leftsubnets , вы должны использовать rightubnet , а не rightubnet . Как указано на http://linux.die.net/man/5/ipsec.conf :

Если оба leftsubnets = и rightsubnets = определена, будут созданы все комбинации туннелей подсети.

Попробуйте использовать:

leftsubnets={10.43.4.0/24,10.43.6.0/24,}

вместо:

leftsubnets={10.43.4.0/24 10.43.6.0/24}

Примечание: добавьте две запятые. После первого и последнего тоже.

Это связано с ошибкой в ​​том, как реализация IPSec в AWS обрабатывает SPI (индексы параметров безопасности). Вы можете подробно прочитать об этом на веб-сайте libreswan , но в результате libreswan работает с двумя диапазонами, устанавливая два туннеля (в вашем случае, вероятно, aws-vpc / 1x1 и aws-vpc / 1x2 ). OpenSWAN и StrongSWAN делают то же самое.

Каждый из этих туннелей имеет свою собственную SA (ассоциацию безопасности), каждый из которых идентифицируется парой SPI, один для трафика, который вы отправляете (ваш SPI), а другой для трафика, отправляемого Amazon (их SPI). Amazon, несмотря на то, что установил свой SPI # 1 для любого туннеля, появляющегося первым, заменяет его на SPI # 2, когда появляется второй туннель (вместо того, чтобы сохранить SPI # 1 для туннеля 1 и использовать SPI # 2. просто для туннеля два, как надо). Трафик отправляется в первый нижний туннель AWS с использованием вашего SPI №1, но Amazon шифрует ответы своим SPI №2, что, естественно, приводит к сбою расшифровки трафика на вашей стороне.

Вот почему первый туннель работает очень недолго, пока не появится второй туннель. Если через некоторое время вы заставите на своей стороне регенерацию SPI для туннеля 1, он начнет работать, но новый SPI № 1 Amazon заменит их старый SPI для туннеля 2, а туннель 2 перестанет работать, как только туннель 1 возобновит обслуживание. .

Я сталкивался с этим дважды с разницей в несколько лет, последний раз вчера, поэтому я не думаю, что AWS сможет это исправить. Похоже, что это не влияет на коммерческие реализации IPSec (или AWS уже исправил бы это к настоящему времени), я предполагаю , потому что они действительно не имеют концепции туннелей между подсетями, а просто объединяют кучу все туннели хост-хост используют одни и те же SPI. Однако это только предположение.

Изменить : как ни странно, благодаря тому, что я потратил неделю на работу над этим для клиента, у которого был хороший контракт на поддержку AWS, я теперь подтвердил, что libreswan сказал о последнем SPI, неправильно заменяющем любые ранее установленные. . Amazon также подтвердила, что они это делают, и что одна сущность vpn- может, по их мнению, поддерживать только одну пару SPI. Их совет - настроить S / WAN так, чтобы создавался только один туннель, а затем направлять по нему трафик к определенным адресатам.

К счастью, libreswan теперь поддерживает это в версии 3.18 или новее, при условии, что у вас достаточно новое ядро ​​Linux. Я могу подтвердить, что CentOS 7 удовлетворяет обоим пунктам.

Их подробное описание в их вики , но в результате вы устанавливаете туннель с очень широкими диапазонами источника и назначения ( 0.0.0.0/0 ), используя Linux Virtual Устройство туннельного интерфейса ( vti ), затем скажите libreswan не настраивать маршрутизацию через него ( vti-routing = no ). Затем вы можете выбрать места назначения для достижения через этот туннель с помощью простых операторов маршрута ( ip route add 10.0.0.0/8 dev vti01 ).

У меня это работает в производстве. Он даже поддерживает несколько одновременных туннелей, более поздние из которых используют различные параметры конфигурации mark = и vti-interface = . Amazon также теперь поддерживает связывание VPN с транзитным шлюзом (TGW), с которым, в свою очередь, могут быть связаны многие VPN в одном регионе AWS, поэтому вам действительно нужен только один VPN на регион AWS, который можно масштабировать.