Объединить два сервера

Что мешает иметь две подсети и соединение между серверами? У меня есть в чем-то похожая схема (но более заморочная), где клиент соединяется с двумя серверами при этом бывают ситуации когда один из серверов не доступен со стороны клиента, НО зато этот недоступный сервер доступен со стороны второго сервера. И в зависимости от ситуации трафик идет или напрямую или через другой сервер.

Конечно предложу не лучший вариант, но всего то надо менять доменные имена, если один сервер обнаруживает что другой не активен, то он присваивает себе доменное имя, например server.local

Здесь предполагается, что один сервер может быть выключен, но когда включены оба, то связь между ними надежная.

Если делать два сегмента, то клиенты могут иметь один из двух адресов что усложнит логику клиентов, которые должны думать что им нужно перебирать адреса клиентов же из двух возможных. Даже если поместить внутрь локальный днс-сервер, клиенты все-равно должны будут уметь перебирать множественные A-записи.

Да, и предполагается что любые сервера доступны для любых клиентов всегда, лишь бы были включены.

Хотя, на счет множественных записей возможно ошибаюсь. Но, тоже усложнение тем, что клиенты должны будут регистрироваться в днс-сервере.

Если делать два сегмента

Разве я 2 сегмента предлагал сделать?

keepalived???

Нет, это про предыдущее сообщение.

А как он поможет, что отслеживать и что потом делать (если это приведет к вынужденному гашению сервиса для принудительного реконнекта клиентов на другой сервер, то это тоже не желательно так как хотелось бы минимизировать реконнекты)?

Частично повторяю, так как ошибся обьединив ответ:

Здесь предполагается, что один сервер может быть выключен, но когда включены оба, то связь между ними надежная.

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

Даже если поместить внутрь локальный днс-сервер, клиенты все-равно должны будут уметь перебирать множественные A-записи.

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

А когда основной сервер вновь станет доступен, и некоторые клиенты будут подключаться к нему, и получится присутствие клиентов на двух серверах одновременно, что делать без бриджа и вынуждаемых реконнектов?

А когда основной сервер вновь станет доступен, и некоторые клиенты будут подключаться к нему, и получится присутствие клиентов на двух серверах одновременно, что делать без бриджа и вынуждаемых реконнектов?

Я не знал что тебе МОЖНО вынуждать рассоединения. Тогда просто руби их останавливая сервис на резервном сервере.

Как раз не желательно рвать и вынуждать реконнекты.

Хотелось бы прозрачно сделать как в случае единственного сервера. Может быть у кого-то уже есть успешный опыт с бриджингом?

Не учел, этого момента. У меня-то общение по внутренним адресам.

Не очень понял, но клиенты тоже имеют приватные адреса внутри впн'а.

Я не о том. У меня за ними подсетки, общение идет не адресам впн :)

Как раз не желательно рвать и вынуждать реконнекты.

Ну тогда ты хочешь невозможного. Ты уж определись, тебе нужно мягко распределять нагрузку или что бы все клиенты были подключены к одному серверу?

Я наверно не знаю чего ты там желаешь, но разве не вариант реализовать свои желания на прикладном уровне? Модифицировать программу так что бы она подключалась сразу к 2 серверам.

Ты опиши точно. А то я телепат не самого высокого уровня.

Могу телепать, могу не телепать.

Я ТС отвечал о том почему мое предложение не верно.

Ни то, ни другое. Хотелось бы иметь прозрачную ситуацию как в случае единственного сервера. Вначале ищутся варианты не нарушающие прямого поведения, когда будет убеждение что бридж не подходит или не найдется еще чего, то будут прорабатываться обходные варианты (в том числе возможно с модификацией и т.д.).

Ни то, ни другое. Хотелось бы иметь прозрачную ситуацию как в случае единственного сервера. Вначале ищутся варианты не нарушающие прямого поведения, когда будет убеждение что бридж не подходит или не найдется еще чего, то будут прорабатываться обходные варианты (в том числе возможно с модификацией и т.д.).

Тогда тебе не мост нужен, а прокси который будет сам обрабатывать подключение и отключение делая для клиентов неприрывную сессию. Но это прикладной уровень.

Про прокси непонятно, когда выключится один прокси , выключится и доступ к двум серверам, или предлагается два прокси, совмещенные с двумя серверами. И чем это выигрывается, когда нужно вводить логику присутствия разных клиентов на двух серверах одновременно, опять идем к взаимодействию между серверами.

Додумался еще вариант: отключить возможность присутствия клиентов на двух серверах и соответственно вынужденность общения серверов между собой, а именно каждый сервер смотрит на соседа и если сервис соседа выключен, то включить собственный сервис. Если соседский сервис включен, то собственный не включать. Это когда собственное состояние «без сервиса». При включенном собственном сервисе, и обнаружении включенного сервиса у соседа(какая либо ошибка, вероятно потеря связи, хотя она должна быть надежная(или еще чего-то не учлось)), выключить сервис с 50 процентной вероятностью (а если нет активных клиентов то просто гасить сервис) и уменьшить временные промежутки в цикле обнаружения состояния соседа.

Тред не читал, но tinc поиском не нашел. tinc?

Кажется эта технология не совместима с openvpn, или можно совместить? Если нет, вряд ли подойдет..

Еще костыльный вариант. Опять-таки две сети, но клиентам общаться между собой по dns, а не ip и соответственно заводить записи с коротким временем жизни.

О! Вспомнилось, мне кажется то что вам нужно. Не прописывайте сразу сетку на tun/tap, а меняйте роут до хоста при соединении.

Да, вариант не совсем прозрачный и придется заводить внутренний днс сервер. И кажется например как с noip время вне сервиса сделать короче чем минута в лучшем случае не получится. Ну и учить клиентов регистрироваться наверное придется.. Спасибо.

О! Вспомнилось, мне кажется то что вам нужно. Не прописывайте сразу сетку на tun/tap, а меняйте роут до хоста при соединении.

Пока не понимается, просьба подробнее описать ситуацию.

Предположим клиент А конектится к серверу 1, соответственно на сервере 2 надо поднять роут до него т.е. на сервер 1 и наоборот.

Про прокси непонятно, когда выключится один прокси , выключится и доступ к двум серверам, или предлагается два прокси, совмещенные с двумя серверами. И чем это выигрывается, когда нужно вводить логику присутствия разных клиентов на двух серверах одновременно, опять идем к взаимодействию между серверами.

Ты не понял. Это должен быть умный прокси реализующий часть логики сервера отвечающей за сеансовое взаимодействие. Хотя я тоже не понял чего ты хочешь на самом деле.

Так и не удалось понять мне:

Для какой схемы предлагается отложенно прописывать маршрут и с какой целью, и как узнает второй сервер о том что подключились клиенты к первому и какой в этом смысл.

В общем в чем идея не понимаю, если есть возможность опишите детально всю схему и шаги настройки.

Это переусложнение.

Цель ввести второй сервер прозрачно для клиента(но правки клиентских конфигов допустимы) без модификации внутренней инфраструктуры и введением дополнительных внутренних сервисов, и с поведением при отрубании первого сервера:сразу успешный коннект ко второму.

Поправки:

изменения любых конфигов в рамках опенвпн разрешены;

на самих серверах можно городить все что угодно, но в рамках линукса, не затрагивая сетевое оборудование;

при разрыве успешный коннект к любому из серверов без привязки к последовательности: первый это или второй;

не допустима открытая передача данных без шифрования между серверами (если требуется);

Из того как я тебя понял. Скажу что это не возможно. Компьютер - это не магия.

Сервера соединяем через vpn. Cервер1 192.168.0.1 сервер2 192.168.0.2 клиент получает адрес 10.0.0.21.
При соединении к сервер1 на сервере2 надо добавить маршрут 10.0.0.21 gw 192.168.0.1
При соединении к сервер2 на сервере1 надо добавить маршрут 10.0.0.21 gw 192.168.0.2
Так общий смысл понятен?

При соединении к сервер1 на сервере2 надо добавить маршрут 10.0.0.21 gw 192.168.0.1

А как сервер2 узнает о подсоединении клиента к серверу1?

Тут надо от обратного, сервер1 должен это сделать. А как, это уже вопрос реализации, начиная с обычного ssh.

И возможно ли регулировать часть сегмента чтобы заставить отправиться через гейт к другой части одного и того же сегмента(10.0.0.0/24)?

Понятно, что кроме как самому серверу1 события подключения клиентов к самому себе никому не известны, пока он не соизволил сообщить об этом. Вопрос как именно надо оповещать от сервера1 к серверу2, м.б. есть готовые механизмы в рамках технологии openvpn?

Даже если нет и предлагается делать внешний независимый сервис для этого, то тоже вариант хороший, лишь бы получился не переусложненный.

Почему нет?

Я же написал, например тот же ssh.

Сделал маршрут на сервере1 (на котором находится клиент1) до клиента2 через адрес интерфейса серверного впн сервера1(общение между серверами). Ошибка при добавлении маршрута возникает в случае если попробовать добавлять маршрут через адрес удаленного серверного интерфейса сервера2.

И обратно.

При попытке пинговать с клиента1 к клиенту2, трафик ловится на обоих виртуальных интерфейсах сервера1 , но до сервера2 не доходит.

Форвардинг пакетов на обоих серверах включен, фаервол по умолчанию разрешает все.

?

Бррр, не распарсил причем все. Куда подключен клиент2 ? Вот это что означает «добавлять маршрут через адрес удаленного серверного интерфейса сервера2.» ?

Клиент1 подключен к серверу1, клиент2 к серверу2.

При попытке на сервере1 добавить маршрут для клиента2 через адрес сервера2 возникала ошибка. Ошибка возникала при конфигурации интерфейсах как tun. Для tap типов сработало нормально.

Но клиеты по-прежнему не видят друг друга.

Маршрут на сервере2 для клиента1 тоже добавлен.

tun/tap роли играть не должно. Вернемся к схеме которую я описывал.
У Клиент1 будет адрес 10.0.0.21, у Клиент2 адрес 10.0.0.22
На сервере1 надо выполнить route add -host 10.0.0.22 gw 192.168.0.2
На сервере2 надо выполнить route add -host 10.0.0.21 gw 192.168.0.1
Не забыть то что клиентам нужно раздавать маршрут до 10.0.0.0/24

У меня другая утилита, поэтому для данных адресов так:

На сервере1 (применимо только для типов tap: 192.168.0.1,10.0.0.1):

ip route add 10.0.0.22/32 via 192.168.0.2 И аналогично.

Не забыть то что клиентам нужно раздавать маршрут до 10.0.0.0/24

Как именно это выглядит( и тут не надо забывать что есть условие, что на клиентах доступны правки только опенвпн конфига, запускать на нем ссш для распространения маршрута возможности нет ) ?