IPSEC и States через два WAN автоматически
-
2.4.4-RELEASE-p2
Возникло два вопроса, как и возможно ли вообще.
-
Имеется IPSEC тоннель между двумя PFsense с множеством фаз2 (если это важно).
На первом PFsense есть два GW основной и резервный, возможно ли настроить так, чтобы автоматически при падении первого GW и автоматеского переключения на второй, тоннель тоже переподнимался через второй GW, ну и возвращался обратно через первый, когда тот поднимется и переключится автоматом опять в дефолтный?
Автоматическое переключение гейтов понятно как настроить, а вот с IPSEC нет. Сейчас если что приходится вручную переподнимать тоннель. -
А вот вторая проблемка возникла со стейтами при автопереключения между GW, после переключения на второй, астериска цепляет транки через него и при возвращении первого так и висит на втором, что приводит к косякам со связью.
Те настройки которые есть со стейтами не спасают, или есть еще какие то настройки о которых я пока не знаю )
-
-
@alex82
Доброго вечера
По первому вопросу , теоретически я бы лично попробовал сделать так
1 Вместо классического ipsec туннеля со множеством фаз 2 , я бы сделал 2 VTI туннеля (по одному на каждый GW) со вторым PF.
2 Эти 2 туннеля также объединить в отказоустойчивую группу , в которой при падении 1 туннеля трафик бы шел через второй туннель ) -
- Делаете failover GW group, выбираете его в качестве интерфейса в первой фазе IPSec. Заводите учетку на Dyn DNS провайдере по выбору - например, freedns.afraid.org и создаете DynDNS клиента на пфсенсе c интерфейсом failover GW group. На этом пфсенсе (с двумя шлюзами) My identifier в P1 IPsec будет Distinguished name с доменным именем, заведенным на Dynamic DNS провайдере. Соответственно, на удаленном пфсенсе Peer identifier будет это самое доменное имя. При падении основного шлюза DynDNS должен проапдейтить Dyn DNS сервер, чтобы он разрешал доменное имя в айпи второго шлюза. Переключение будет не мгновенным, так как DNS серверам в сети интернет нужно будут время на обновление записей.
А вообще, если есть 2 пфсенса с 2.4.4 - надо смотреть в сторону routed IPsec - https://www.youtube.com/watch?v=AKMZ9rNQx7Y - с ним такая задача решается гораздо проще.
- При восстановлении основного шлюза существующие стейты на сбрасываются. Я так понимаю, чтобы астериск снова нормально коннектился , приходится убивать стейты, чтобы они поднялись уже по основному шлюзу?
-
@vladimirlind Да по стейтам так, висят на втором гейте, там есть галки
Reset all states if WAN IP Address changes
и
Flush all states when a gateway goes downЭто все что нашли относящееся к стейтам, но в нашей ситуации это не тот сценарий при котором они срабатывают при обратном переключении, когда падает основной, судя по всему, по второй настройке срабатывает.
-
@alex82
По второму вопросу , опять же теоретически
Насколько я понимаю , при поднятии основного шлюза , должен запускаться скрипт rc.newwanip. Тогда в него можно добавить строчку , которая бы запускала команду pfctl с ключом -k и адресом хоста , которая бы убивала бы все стейты для этого хоста . -
@Konstanti said in IPSEC и States через два WAN автоматически:
2 Эти 2 туннеля также объединить в отказоустойчивую группу , в которой при падении 1 туннеля трафик бы шел через второй туннель )
Насколько я знаю, reply-to на VTI не работает - есть такая проблема. Поэтому обратный трафик дропнется без маршрутов, скорее всего. Лучше делать с протоколом динамической маршрутизации - ospf, bgp.
Или уж тогда вообще openvpn использовать - там такое работает. -
@vladimirlind Если использовать исходящий НАТ на концах VTI туннелей, то reply-to особо и не нужен будет.
В любом случае , надо пробовать и эксперементировать -
@Konstanti said in IPSEC и States через два WAN автоматически:
В любом случае , надо пробовать и эксперементировать
Коллеги пробовали такой сетап - не работает именно по причине неработающего reply-to. NAT в VPN наверное все-таки предполагается избежать, раз мы удаленные внутренние сети связываем.
-
Спасибо народ :) надо теперь всю эту инфу осмыслить )
-
@vladimirlind
Тут уже была куча тем , связанная именно с этой проблемой . Что в PF поломана функция reply-to на виртуальных интерфейсах ( и на openvpn туннелях , в частности) . Единственным выходом было решение - использование исходящего НАТа , чтобы PF отправлял ответный пакет именно в виртуальный туннель , а не в шлюз по умолчанию . -
Попробуйте поднять на первом пф ДВА OpenVPN сервера.
На втором - два клиента. Затем объявить ЯВНО эти впн-интерфейсы на этом клиенте и создать FAILOVER-группу из них с разными Tier. Далее использовать эту FAILOVER-группу в правилах fw на ЛАН пф-клиента для адреса Астериска.Зы. Как вариант поднять на первом пф ОДИН OpenVPN-сервер на 127.0.0.1 (https://docs.netgate.com/pfsense/en/latest/routing/multi-wan-openvpn.html). И использовать одновременно только ОДИН впн-туннель на клиенте. Второй внешний адрес этого же впн-сервера указать доп. директивой "remote ..." в Адвансед настройках впн на этом же клиенте. Тогда при падение и недоступности 1-го адреса ВПН-сервера клиент будет пытаться поднять линк до 2-го адреса этого же ВПН-сервера.
-
@Konstanti said in IPSEC и States через два WAN автоматически:
@alex82
По второму вопросу , опять же теоретически
Насколько я понимаю , при поднятии основного шлюза , должен запускаться скрипт rc.newwanip. Тогда в него можно добавить строчку , которая бы запускала команду pfctl с ключом -k и адресом хоста , которая бы убивала бы все стейты для этого хоста .А можете подсказать, как правильно это прописать?
Пробовал в etc/rc.newwanip
просто в конец добавлять pfctl -F all (через консоль все работает)
при обработке скрипта выдает ошибку в этой строке, как правильно это туда прописать? -
@alex82 Понятно почему ошибку выдает
это же PHP- скрипт
попробуйте такую строку добавить
exec("pfctl -F all");
