https://m.opennet.dev/openforum/vsluhforumID10/5559.html Коллеги.<br>Прошу совета в вопросе реализации резервирования доступности VPN-серверов.<br>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 на удаленном сервере-партнере.<br><br>И похожий второй вопрос....<br>2. На площадке поднят один сервер на ОС Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). К нему подключается самописный клиент под ОС Windows. Все как-бы работает. Но нужно обеспе https://m.opennet.dev/openforum/vsluhforumID10/5559.html#4 Mon, 09 Nov 2020 06:50:57 GMT &gt;&gt;[оверквотинг удален] <br>&gt;&gt; 1. Есть две площадки. На каждой поднято по одному серверу на ОС <br>&gt;&gt; Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). Сервера спрятаны за роутерами <br>&gt;&gt; Cisco (DNAT), при этом сервера строят IPSec на нестандартных портах, не <br>&gt; Если я хоть что-то понял, то... была похожая ситуация (без цисок и <br>&gt; vpn) в случае с построением отказоустойчивого шлюза, когда было важно обеспечить <br>&gt; удержание открытых сессий клиентов в рабочем состоянии при переключении с мастера <br>&gt; на слейва (гы, all lives matter). Но это было на фряхе, <br>&gt; и там задачка решилась при помощи pfsync. Поищи аналог на линуксе. <br>&gt; По-моему, проблемы одного поля ягоды.<br><br>Спасибо. Посмотрю pfsync.<br>Попробовал другую схему на тестовом стенде. Сервера с каждой площадки держат активные парные туннели. За ними роутеры создают GRE тунели через каждую пару серверов, а OSPF выбирает маршрут. Попробовал использовать балансировку на базе OSPF, но что-то она не впечатлила. Хотя возможно что-то упустил.<br> https://m.opennet.dev/openforum/vsluhforumID10/5559.html#3 Mon, 09 Nov 2020 06:43:14 GMT &gt; А почему не держать оба тунеля в апе, и разрулить на уровне <br>&gt; роутинга BGP?<br>&gt; Давно уходят от мастер-слейв, ECMP тебе в помощь <br><br>Уже расмотрел такой вариант, правда пока на тестовом стенде. Использовал два туннеля с GRE + OSPF (попробовал и EIGRP). <br>Так оно гораздо лучше работает. :)<br> https://m.opennet.dev/openforum/vsluhforumID10/5559.html#2 Sun, 08 Nov 2020 18:30:09 GMT А почему не держать оба тунеля в апе, и разрулить на уровне роутинга BGP?<br>Давно уходят от мастер-слейв, ECMP тебе в помощь<br> https://m.opennet.dev/openforum/vsluhforumID10/5559.html#1 Fri, 06 Nov 2020 11:53:28 GMT &gt;[оверквотинг удален]<br>&gt; 1. Есть две площадки. На каждой поднято по одному серверу на ОС <br>&gt; Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). Сервера спрятаны за роутерами <br>&gt; Cisco (DNAT), при этом сервера строят IPSec на нестандартных портах, не <br>&gt; udp/500 и udp/4500. Решено обеспечить отказоустойчивость - на каждой площадке использовать <br>&gt; по два сервера в режиме MASTER/BACKUP c использованием сервиса keepalived (VRRP). <br>&gt; Но столкнулся с проблемой "тупняка" установки нового туннеля, когда основной сервер <br>&gt; в пределах площадки уходит в состояние BACKUP (при этом стопается сервис <br>&gt; ipsec), а резервный сервер получает статус MASTER и пытается установить <br>&gt; новый туннель. Порой туннель не устанавливается пока не перезагрузить ipsec на <br>&gt; удаленном сервере-партнере.<br><br>Если я хоть что-то понял, то... была похожая ситуация (без цисок и vpn) в случае с построением отказоустойчивого шлюза, когда было важно обеспечить удержание открытых сессий клиентов в рабочем состоянии при переключении с мастера на