openvpn reconnect без потери соединения

В голову приходит три соединения, первое отвалилось пойдет через второе, второе отвалилось...

В принципе в openvpn есть всё необходимое. Три опции remote в конфиге и опция restart on ping или как то так она там называется. Обрыв и следующий.

Да я вот думаю, быть может есть что-то простейшее, вида веса маршрута, время жизни кеша маршрута и т.д..?

По идее, можно сделать keepalive 2 4 , и сделать reconnect script, который будет проверять доступность сервера через разных провайдеров, где доступен, там и будет прописывать маршрут и vpn придет просто через другого провайдера. Вопрос в том, успеет ли вся эта шляпа отработать в случае tcp/ip внутри vpn? Внутренние сервисы отвалятся или нет? :) Я понимаю, что зависит от сервиса… Но, обычно вроде довольно много попыток делает клиентское приложение до сервера

remote мне не очень подходит, т.к. нужно несколько внешних ip у сервера. - Если я всё правильно понимаю. Можно купить и несколько ip, если по-другому никак.

Так я и предложил простейшее. У вас три соединения, маршруты в таблице последовательно, отвалилось первое, заработает следующее.

Подскажите, пож-та, как технически это может выглядеть. Примерно. :)

Ох, перечитал и вообще не понял, при чем тут vpn.

У тебя проблемы с isp на клиенте? Так это впн-сервер вообще никак не затрагивает.

Для начала настрой multiisp failover и затем любой vpn c reconnect и все будет работать.

В чем суть вопроса, что не работает?

Так я и пришел сюда спросить как не мудрить много, и сделать норм. :)

У меня на шлюзе уже есть три isp (очень старый linux). Вот думаю, как более грамотно переключаться между ними, в случае с vpn

У тебя проблемы с isp на клиенте?

Да.

multiisp failover

Что под этим понимать можно? Наткнулся на какой-то пакет под названием pingu…

Не уверен, что понял правильно.

Если хочешь силами VPN клиента перебирать разные IP для подключения, то в конфигурации клиента можно указать несколько remote опций и клиент будет их перебирать.

Вроде ещё remote-random опция есть + поиграться с keepalive

Для этого мне нужно будет несколько белых ip на сервере (в моём случае - три штуки). В таком случае, я смогу каждый ip привязать на свой isp. Но это как-то не особо рационально… Ну или сервер и клиент менять местами… :)

Почитай shorewall документацию на тему multiisp.

В целом тут или нужно поднимать динамическую маршрутизацию. Или пинговать сервер и переключать роутинг на другой шлюз.

Последнее проще.

Хм, перечитал.

Т.е. у вас клиент с 3 разными провайдерами и сервер с одним провайдером и белым IP.

Тогда тем более не понимаю.

На стороне клиента при падении провайдера же будет производиться переключение на резерв. Пусть силами этого-же переключения и пинается VPN-client restart.

Если долго ждать пока VPN сам поймёт, что подключение отвалилось, то вам всёравно ждать пока оно снова поднимется.

Можно изватится и держать тоннель через каждого провайдера. И уже между тоннелями использовать балансировку трафика.

Т.е. у вас клиент с 3 разными провайдерами и сервер с одним провайдером и белым IP.

Угу. Ибо связь хромает. :)

На стороне клиента при падении провайдера же будет производиться переключение на резерв. Пусть силами этого-же переключения и пинается VPN-client restart.

Сейчас оно руками делается. Когда обнаруживается падение. :) Ибо на облако нет особой подвязки. А вот с появлением облака, у меня будут биг трабл…

Если долго ждать пока VPN сам поймёт, что подключение отвалилось, то вам всёравно ждать пока оно снова поднимется.

Если юзать static key для аутотентификации + float на ovpn сервере, тоже долго будет? Я бы может и вовсе не трогал бы openvpn, а с опцией float на сервере просто маршруты менял в случае падения. Но не уверен, будет работать или нет оно так. :)

Можно изватится и держать тоннель через каждого провайдера. И уже между тоннелями использовать балансировку трафика.

Да, но не хотелось бы так усложнять. :)

Сейчас оно руками делается. Когда обнаруживается падение. :)

Вот это и надо автоматизировать, а в vpn-клиенте просто делать reconnect.

Если нужен failover без простоев, то тут либо BGP(дорого и для конкретно этой задачи - избыточно), либо SCTP(не так чтобы много кто его умеет)

приложения работающие внутри vpn ничего не подозревали о ре коннекте.

static key для аутотентификации + float на ovpn сервере, тоже долго будет

Тут уже смотреть будет ли вашим приложениям это долго или нет.

Сейчас оно руками делается. Когда обнаруживается падение.

Хороший повод придумать что-то для автоматизации.

Network Manager по дефолту умеет.
Если ISP падает (перестает быть там интеренет), то он ему метрику роутинга ставит в диапазоне 20000..21000. если же интеренет там есть , то метрика <1000.
В openvpn сделай всякие ping,reconnect.

Если нужен failover без простоев, то тут либо BGP(дорого и для конкретно этой задачи - избыточно), либо SCTP(не так чтобы много кто его умеет)

Openvpn в режиме TCP поверх обычного MPTCP на клиенте и сервере хватит, работает из коробки, подхватывает автоматом все gateway's прописанные в главной таблице роутинга, главное ядро MPTCP на клиенте и сервере установить и пару штук в sysctl. Оно держит связь клиент-сервер по нескольким TCP сессиям. Можно прозрачно добавлять/удалять интерфейсы.

Openvpn в режиме TCP поверх обычного MPTCP на клиенте и сервере хватит, работает из коробки

Да, решение интересное, но я как-то не решился из-за большого overhead. Но тоже держу как вариант.

Если ISP падает (перестает быть там интеренет), то он ему метрику роутинга ставит в диапазоне 20000..21000. если же интеренет там есть , то метрика <1000

Полагаю, это должна упасть последняя миля. А у меня последняя миля за редким исключением всегда ОК. :)

Да, про MPTCP я как-то подзабыл, спасибо за напоминание

ip r add default table isp1
ip r add default table isp2
ip ru add priority 10000 via $IP1 table isp1
ip ru add priority 10100 via $IP2 table isp2
Вроде примерно так. Да и как повторяет vel, в таблице main не должно быть defroute

Полагаю, это должна упасть последняя миля. А у меня последняя миля за редким исключением всегда ОК. :)

нет, именно интернет. Там в NM встроенная пинговалка интернета , делает запросы на http://connectivity-check.ubuntu.com/ ( само умеет в policy based routing) через каждый линк, который у него висит как default route. И упавшему линку повышает метрику, чтоб понизить приоритет.
Например в пакете network-manager-config-connectivity-ubuntu

Плохое решение гонять tcp поверх tcp, тем более в инете.

поднимал миллионы проксей tcp-over-tcp , проблем не было.
единственный баг, который есть сейчас, это когда curl запрашивает HTTPS:// сайт через HTTPS:// же прокси. С браузерами такой проблемы нет.

С проксей и не будет. Предполагаю что анон намекает или на фрагментацию(что совсем не гуд) или на вынужденное занижение mss.

И более того, если канал не стабилен, то будет больше всевозможных ретрансмитов, дупаков и реордеров на обоих уровнях. Лучше использовать в качестве транспорта udp.

Если вы говорите про сферичность udp vs tcp в вакууме, то вроде как да. Но не забывайте про конечную реализацию.

Что значит «про конечную реализацию» ?

Что значит «про конечную реализацию» ?

Если нас интересует доставка без потерь, то в случае tcp мы заранее знаем накладные расходы. В случае udp же - уж как посчитает реализация конкретной софтины. Представим ftp по udp с подсчетом контрольной суммы файла после передачи. Файлики допустим размером в 1Гб. В 1Гб ошибка? Фигня, перегоним заново. Что, опять ошибка? Не вопрос, повторим... и так много раз.
Или другой вариант, будем на каждый полбайта подтверждение слать... Упарыватся можно по всякому.

Так я об этом и говорю - транспорт udp , а всё, что бегает по нему (по большей части это tcp) будет разруливаться в рамках tcp.

Почти верно. Но бывают, они не настолько редкие, исключения. Когда даешь 443/tcp и-не-имеет :)