Коллеги.
Прошу совета в вопросе реализации резервирования доступности VPN-серверов.
1. Есть две площадки. На каждой поднято по одному серверу на ОС Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). Сервера спрятаны за роутерами Cisco (DNAT), при этом сервера строят IPSec на нестандартных портах, не udp/500 и udp/4500. Решено обеспечить отказоустойчивость - на каждой площадке использовать по два сервера в режиме MASTER/BACKUP c использованием сервиса keepalived (VRRP). Но столкнулся с проблемой "тупняка" установки нового туннеля, когда основной сервер в пределах площадки уходит в состояние BACKUP (при этом стопается сервис ipsec), а резервный сервер  получает статус MASTER и пытается установить новый туннель. Порой туннель не устанавливается пока не перезагрузить ipsec на удаленном сервере-партнере.

И похожий второй вопрос....
2. На площадке поднят один сервер на ОС Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). К нему подключается самописный клиент под ОС Windows. Все как-бы работает. Но нужно обеспечить безотказность работы клиента. Не очень хочется использовать VRRP
Есть альтернативные варианты резервирования серверов?

• Strongswan. Резервирование VPN-cерверов.,Аноним, 14:53 , 06-Ноя-20
  • Strongswan. Резервирование VPN-cерверов.,zomka25, 09:50 , 09-Ноя-20
• Strongswan. Резервирование VPN-cерверов.,shadow_alone, 21:30 , 08-Ноя-20
  • Strongswan. Резервирование VPN-cерверов.,zomka25, 09:43 , 09-Ноя-20

>[оверквотинг удален]
> 1. Есть две площадки. На каждой поднято по одному серверу на ОС
> Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). Сервера спрятаны за роутерами
> Cisco (DNAT), при этом сервера строят IPSec на нестандартных портах, не
> udp/500 и udp/4500. Решено обеспечить отказоустойчивость - на каждой площадке использовать
> по два сервера в режиме MASTER/BACKUP c использованием сервиса keepalived (VRRP).
> Но столкнулся с проблемой "тупняка" установки нового туннеля, когда основной сервер
> в пределах площадки уходит в состояние BACKUP (при этом стопается сервис
> ipsec), а резервный сервер  получает статус MASTER и пытается установить
> новый туннель. Порой туннель не устанавливается пока не перезагрузить ipsec на
> удаленном сервере-партнере.

Если я хоть что-то понял, то... была похожая ситуация (без цисок и vpn) в случае с построением отказоустойчивого шлюза, когда было важно обеспечить удержание открытых сессий клиентов в рабочем состоянии при переключении с мастера на слейва (гы, all lives matter). Но это было на фряхе, и там задачка решилась при помощи pfsync. Поищи аналог на линуксе. По-моему, проблемы одного поля ягоды.

>>[оверквотинг удален]
>> 1. Есть две площадки. На каждой поднято по одному серверу на ОС
>> Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). Сервера спрятаны за роутерами
>> Cisco (DNAT), при этом сервера строят IPSec на нестандартных портах, не
> Если я хоть что-то понял, то... была похожая ситуация (без цисок и
> vpn) в случае с построением отказоустойчивого шлюза, когда было важно обеспечить
> удержание открытых сессий клиентов в рабочем состоянии при переключении с мастера
> на слейва (гы, all lives matter). Но это было на фряхе,
> и там задачка решилась при помощи pfsync. Поищи аналог на линуксе.
> По-моему, проблемы одного поля ягоды.

Спасибо. Посмотрю pfsync.
Попробовал другую схему на тестовом стенде. Сервера с каждой площадки держат активные парные туннели. За ними роутеры создают GRE тунели через каждую пару серверов, а OSPF выбирает маршрут. Попробовал использовать балансировку на базе OSPF, но что-то она не впечатлила. Хотя возможно что-то упустил.

А почему не держать оба тунеля в апе, и разрулить на уровне роутинга BGP?
Давно уходят от мастер-слейв, ECMP тебе в помощь

> А почему не держать оба тунеля в апе, и разрулить на уровне
> роутинга BGP?
> Давно уходят от мастер-слейв, ECMP тебе в помощь

Уже расмотрел такой вариант, правда пока на тестовом стенде. Использовал два туннеля с GRE + OSPF (попробовал и EIGRP).
Так оно гораздо лучше работает. :)