Failover, не сбрасывает соединения на WAN2, после "возврата" WAN1
-
@roman777
Попробуйте так
-
Проблема решилась изменением "стоимости шлюза:
было Tier1 для основного, и Tier2 для резерва
Рабочая конфигурация Tier1 для основного и Tier5 для резерва. -
Tier - это про другое:
https://docs.netgate.com/pfsense/en/latest/routing/multi-wan.html
https://docs.netgate.com/pfsense/en/latest/book/multiwan/load-balancing-and-failover.htmlЕсли у вас ВНЕШНИЕ соединения не сбрасываются, то тут не к Tier-у вопросы. ВНЕШНИЕ точно не сбросятся сами собой. Только если этот WAN не "упадет".
У меня 2 ВАНа - оптика и адсл. Оптика - дефолтный линк. Внешние клиенты первым делом коннектятся к оптике. Если оптика "лежит" - пробуют адсл. Если подк. к адсл, то к оптике они переподключатся, если: 1) умрет мой адсл; 2) что-то случится с их каналом. С чего бы им автоматом на мою дефолтную оптику возвращаться?
-
@werter спасибо за Ваш ответ.
Видимо так работает логика pfsense. После того, как основной канал падает (OFFLINE), всех перекидывает на резерв.
НО, когда основной канал возвращается в статус ONLINE, дефолтный шлюз не меняется с резерва на основной канал( при Tier 1 и Tier2) в "System/Routing/Gateways" резервный шлюз висит со статусом default (хотя дефолтным должен быть основной шлюз, а не резерв)
После того, как я изменил переменные Tier на 1 и 5, после возвращения основного шлюза он СРАЗУ становится дефолтным.
В триггерах стоит "потери пакетов" и "высокая латентность". -
@werter как можно сделать принудительное переключение всех клиентов на основной WAN при его восстановлении? У нас SIP и провайдер пускает его только из своих подсетей. Т.е. на резервном WAN он не работает.
-
@roman777
Клиентов каких? ВНЕШНИХ? Или вы про своих ВНУТРЕННИХ толкуете?
Если про внутренних, то решаемо. Рисуйте правило fw на ЛАН, где явно укажите в Src- LAN net, в GW - GW_WAN1(или оставьте дефолтный), в Dst - имя\адрес сип-сервера. Поставьте это правило выше всех.После того, как я изменил переменные Tier на 1 и 5, после возвращения основного шлюза он СРАЗУ становится дефолтным.
Вернется на дефолтный и при Tier 1 и 2. Почитайте про логику Tier.
В триггерах стоит "потери пакетов" и "высокая латентность".
У меня стоит "Member down".
-
@roman777 у меня в качестве default gw выбран не конкретный шлюз, а группа шлюзов, и все переключается моментально. Как только основной шлюз возвращается в UP - все соединения переключаются на него, вплоть до vpn туннелей.
-
@roman777 said in Failover, не сбрасывает соединения на WAN2, после "возврата" WAN1:
(хотя дефолтным должен быть основной шлюз, а не резерв)
Для Failover не обязательно переключение default gateway. На самом деле default gateway нужен только для самого PF для получения времени, обновлений и т.п.
При организации Failover средствами gateway group Default gateway switching не нужен.If the default gateway goes down, switch the default gateway to another available one. This is not enabled by default, as it's unnecessary in most all scenarios, which instead use gateway groups.
-
@Renat said in Failover, не сбрасывает соединения на WAN2, после "возврата" WAN1:
@roman777 у меня в качестве default gw выбран не конкретный шлюз, а группа шлюзов, и все переключается моментально. Как только основной шлюз возвращается в UP - все соединения переключаются на него, вплоть до vpn туннелей.
А вот у меня не так,
те соединения которые были подключены УЖЕ на резервном WAN2 не отключаются ( WAN2 же живой ) и продолжают работать, вновь созданные используют шлюз WAN1. -
@roman777 said in Failover, не сбрасывает соединения на WAN2, после "возврата" WAN1:
те соединения которые были подключены УЖЕ на резервном WAN2 не отключаются ( WAN2 же живой )
Да, так и есть. Так как шлюз не падал, states через этот шлюз продолжают жить.
Пока не сделаешь Reset states
Есть опция State Killing on Gateway Failure, но при живом шлюзе она не поможет.
