3 точки vpn

Если я все правильно понял, то единственное решение это соединить клиентов еще одним тунелем, больше никак.

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

И да, а если клиентов будет больше.... Это будет приводить к экспоненциальному росту количества тунелей. Плюс писанина скрипта который будет их поднимать забирая участников с сервера, плюс проблема исключения при отсоединении клиента.
Хотелось бы решение которое умеет это из коробки или после допиливания напильником.

Если ip статика, то тут ipsec скорее больше подходит, с тунелями все ко всем. Если предполагается большое кол-во клиентов, то еще замутить какую нибудь систему управления конфигурациями, чтобы в случае изменений не руками у них править.

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

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

А вот роутинг не используется вообще.

Маршрутизацию не предлагать - это и так понятно.

И NAT еще... Хочется на втором уровне сделать и этим ограничиться.
Но это хочется. :-(

PS:
1. Все участники обмена предоставляют в сеть свой сервис.
2. Некоторый сервис одинаков для некоторых участников.
3. Надо, что-бы клиенты получали искомый сервис через свой сервер если он его предоставляет или через сервер партнера.
4. При этом что-бы путь к сервису не лежал через промежуточную точку (и не перегружал ее).
прим.: Разделение и определение наличия сервиса уже есть но пока ходит через сервер т.е. общую точку.

Наличие маршрутизации предполагает дополнительные правила доступа для разных подсетей+конфигурация iptables.
Можно конечно, но чем проще - тем лучше.

А вот роутинг не используется вообще.

Я может чего-то не понял, но простите как пакетики то бегают? :)

Я выше написал, если я правильно понял, то ближе(удобнее) ipsec все ко всем поднять. Исключение, не будет работать если предполагается наличие более одного тунеля к одному серверу через один и тот же нат.

Внутри тонеля это выглядит как одна подсеть /24 и центральный узел VPN как свич в который воткнуты все клиенты как локальный tapX (в моем случает tap1) так и на всех клиентах tapX соответственно. При подключении нового клиента никаких дополнительных настроек не требуется. Просто его tapX получает адрес с сервера через DHCP и на этом процесс активации клиента заканчивается и клиенты видят друг-друга через сервер.

Да и еще.

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

Ой, простите, это же в шапке написано было. Я думал про вариации на тему большого кол-ва сетей за сервером/клиентами. Так что мои предложения не верны, еще раз простите мою не внимательность.
Вспомнил про существование softether, сам его не тыкал, но вдруг в нем есть что-то подобное из каробки.

В рамках задачи можно считать что этот несколько машин подключенных к Internet и имеющих статические реальные адреса

Тогда возвращаясь к ipsec, я не готов поручиться что заработает (не делал такого никогда), но можите попробовать. Мысли вслух:
1. Первый туннель, сервер-клиенты. Выдавать клиентам адреса статикой, т.е. прописать в конфиг ipsec (если за центральным серваком есть еще хосты в локалке, можно урезать пул dhcp оставив адреса для ipsec) но при этом в *subnet прописать всю /24
2. Второй между клиентами. Таже прописать жестко left/rightsourceip но другие (отличные от первого тунеля) т.е. у клиентов получиться по два ip, один для общения с серваком, второй между собой но с уже урезанной *subnet.
За поведение не ручаюсь, боюсь даже предположить, что получиться из этого и как будут гулять броадкасты по всей /24 :) Можите попробовать потом нам расскажите :)

PS Это только мысли вслух, но возможно натолкнет вас на правильное решение.

Второй вариант, тот же openvpn со скриптами, это уже при условии что на всех концах не винда/телефоны/etc и геморойно.
Не ваш случай но, в этой теме Объединить два сервера я привел вполне работоспособный вариант с использованием скриптов, смотрите на второй странице ближе к концу.

Посмотрел, но это не совсем то.

Тут, у меня возникла другая идея, а именно порыться в исходниках openvpn.
А именно глянуть в сторону как он обменивается MAC-адресами. Далее запустить 3 копии в серверном режиме и заставить коннектится друг на друга и обмениваться MAC'ами. т.е. таким образом, что бы он передавал только маки свои и принимал рядом стоящие <что по сути одно и тоже>. Остальной функционал по идее там уже должен быть реализован.
Ну да и забыл про направления... хотя возможно и это там есть.

Посмотрю - отпишусь.

fastd?

может быть...
full mesh && multi tap буду смотреть. Возможно это и будет жить.

После кружения вокруг да около - решил посмотреть в сторону
B.A.T.M.A.N. http://www.open-mesh.org

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

Соответственно вопрос:
Кто сталкивался с open-mesh и B.A.T.M.A.N. в частности - поделитесь впечатлениями.