 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).
Так оно гораздо лучше работает. :)
|
Версия для распечатки
