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

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

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

Это связано с ошибкой в ​​том, как реализация 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 для туннеля один, и использовать 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 (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, который можно масштабировать.

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

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

вместо того:

leftsubnets={10.43.4.0/24 10.43.6.0/24}

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