Strongswan. Резервирование VPN-cерверов., zomka25, 06-Ноя-20, 00:36 [смотреть все]Коллеги. Прошу совета в вопросе реализации резервирования доступности 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 (1)
>[оверквотинг удален] > 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. Поищи аналог на линуксе. По-моему, проблемы одного поля ягоды.
- Strongswan. Резервирование VPN-cерверов., zomka25, 09:50 , 09-Ноя-20 (4)
>>[оверквотинг удален] >> 1. Есть две площадки. На каждой поднято по одному серверу на ОС >> Убунта 18.04 (ядро 5.3.ххх) + Strongswan (5.8.1). Сервера спрятаны за роутерами >> Cisco (DNAT), при этом сервера строят IPSec на нестандартных портах, не > Если я хоть что-то понял, то... была похожая ситуация (без цисок и > vpn) в случае с построением отказоустойчивого шлюза, когда было важно обеспечить > удержание открытых сессий клиентов в рабочем состоянии при переключении с мастера > на слейва (гы, all lives matter). Но это было на фряхе, > и там задачка решилась при помощи pfsync. Поищи аналог на линуксе. > По-моему, проблемы одного поля ягоды.Спасибо. Посмотрю pfsync. Попробовал другую схему на тестовом стенде. Сервера с каждой площадки держат активные парные туннели. За ними роутеры создают GRE тунели через каждую пару серверов, а OSPF выбирает маршрут. Попробовал использовать балансировку на базе OSPF, но что-то она не впечатлила. Хотя возможно что-то упустил.
- Strongswan. Резервирование VPN-cерверов., shadow_alone, 21:30 , 08-Ноя-20 (2)
А почему не держать оба тунеля в апе, и разрулить на уровне роутинга BGP? Давно уходят от мастер-слейв, ECMP тебе в помощь
- Strongswan. Резервирование VPN-cерверов., zomka25, 09:43 , 09-Ноя-20 (3)
> А почему не держать оба тунеля в апе, и разрулить на уровне > роутинга BGP? > Давно уходят от мастер-слейв, ECMP тебе в помощь Уже расмотрел такой вариант, правда пока на тестовом стенде. Использовал два туннеля с GRE + OSPF (попробовал и EIGRP). Так оно гораздо лучше работает. :)
|