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

У меня другая утилита

route у вас так же должен быть наравне с iproute2 :)

применимо только для типов tap

Тут похоже дело не в tun/tap а в topology. У tun по дэфолту net30, а у tap subnet
И повторюсь с tun все должно работать, возможно вы раздали как в моем примере т.е. 192.168.0.1 и 192.168.0.2 у net30 это подсетки /30 т.е. работать не будет.
Для сведения, вот здесь есть про topology
http://community.openvpn.net/openvpn/wiki/Topology#Topologynet30
А здесь (если лениво считать) есть табличка по адресам
https://openvpn.net/index.php/open-source/documentation/howto.html#policy

Как именно это выглядит

В конфиг openvpn (сервер) push «route 10.0.0.0 255.255.255.0» будет работать для всех клиентов. Или если нужно отдельно по климентам, то в соответствующий файл конфига клиента (на сервере) в каталоге ccd.
ЗЫ Не забывайте что раздача маршрутов в винде имеет свою особенность, но я так понимаю вам это уже известно раз работает. :)

выкинь openvpn и используй tinc. будет сильно стабильнее\проще\надежнее.

Никогда не сталкивался, может объясните в чем он:
" стабильнее\проще\надежнее." по каждому пункту?

открывай http://tinc-vpn.org/ и читай про схему и организацию сети.

route у вас так же должен быть наравне с iproute2

Кажется это уже считается устаревшей утилитой и по умолчанию дистрибутив ее не ставит.

Тут похоже дело не в tun/tap а в topology

Пожалуй.

В конфиг openvpn (сервер) push «route 10.0.0.0 255.255.255.0» будет работать для всех клиентов

Если добавить всю подсеть, то не будет связи основанной на арп, то есть внутри одной стороны?

Или если нужно отдельно по климентам, то в соответствующий файл конфига клиента (на сервере) в каталоге ccd.

То есть возможно при подключении к одному серверу, выполнить ccd из другого сервера? Как точно это проверить в ручном случае когда момент известен?

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

Не знаю, пока не пробовал таких клиентов.

Мне хотелось услышать от вас как пользователя и заявившего что он лучше. Повторю свой вопрос в чем он: " стабильнее\проще\надежнее." по каждому пункту?

Если добавить всю подсеть, то не будет связи основанной на арп, то есть внутри одной стороны?

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

Или если нужно отдельно по климентам, то в соответствующий файл конфига клиента (на сервере) в каталоге ccd.

То есть возможно при подключении к одному серверу, выполнить ccd из другого сервера? Как точно это проверить в ручном случае когда момент известен?

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

Не знаю, пока не пробовал таких клиентов.

Обычно достаточно установить «запускать от имени администратора» и в конфиг клиента route-method exe, route delay 2

Я пока тоже тогда не понимаю всю предлагаемую схему:

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

Я понимал так, что при подключении клиента1 к серверу1, клиенту1 не надо выдавать никаких маршрутов, пока нет клиентов на удаленной стороне. Пусть по умолчанию может гулять как угодно( и не надо оповещать о соседях-клиентах - в арп-таблице сами засветятся) по одной стороне. При наличии удаленных клиентов в момент подключения, клиент1 должен получить адреса удаленных клиентов и применить маршрут до каждого из них (это достигается если сервер2 скажет при подключении своего клиента адрес этого самого клиента и сервер1 соответственно применит маршрут у себя и клиент1 тоже применит маршрут до удаленного клиента у себя(загвоздка в том что непонятно как он это сделает без ссшд например)). И, так, при любом изменении каждого из клиентов, все остальные клиенты на другой стороне и сам сервер на другой стороне должны получать события и менять маршруты.

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

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

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

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

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

Возможности «пнуть» клиенту новые маршруты не разрывая соединения нет. Именно поэтому я и написал, что отправляем ему всю подсеть. Т.е. для любых адресов 10.0.0.0/24 клиент будет обращаться на свой сервер (без разницы №1 или №2), а вот уже сервер и решает куда отправить пакет или клиенту подключенному к нему напрямую или на другой сервер. Т.е. таблицы маршрутов меняются только на серверах.
Собственно сама идея не моя, я именно вспомнил что подобное используют для запуска двух копий openvpn (tcp & udp) с одной vpn подсетью на одном сервере, и предложил все тоже самое только расширить на два физически разных сервера, по факту не особо большая разница получается, два разных интерфейса на одном сервере или они на двух серверах.

Возможности «пнуть» клиенту новые маршруты не разрывая соединения нет.

Тогда, при подключении нового клиента будет достаточно обновить информацию о нем на серверах только, и проблемы односторонних клиентов нет, и будет все работать?

Да, именно об этом я и писал «Т.е. таблицы маршрутов меняются только на серверах.»

А как будет выглядеть команда на стороне ближайшего сервера для увиденья соседа?

Я же выше писал уже.
Специально для вас вроде нашел то о чем я говорил, вариант две копии openvpn на одном сервере с одной подсеткой. http://thomas.gouverneur.name/2014/02/openvpn-listen-on-tcp-and-udp-with-tun/ модифицируйте применительно к варианту два сервера ну и поменяйте/добавьте то что конкретно вам нужно.

Я же выше писал уже.

Было описано добавлении маршрута до клиента на удаленном сервере. Теперь выясняется, что нужно еще и на локальном.

Вопрос был как раз про локальный, типа 10.0.0.99 via 10.0.0.1

А попробовать предложенный вариант с устройством tap, мне кажется, должно сработать.

Теперь выясняется, что нужно еще и на локальном.

само должно добавиться. во всяком случае когда ставил эксперементы с раздачей сети не из пула прописанного в конфиге усе работало как надо, достоточно ifconfig-push в ccd

это свободный форум, читайте документацию и вам всё будет понятно. если нужна личная консультация - то в job. :)

В конфиг openvpn (сервер) push «route 10.0.0.0 255.255.255.0» будет работать для всех клиентов

выдается ошибка: RTNETLINK answers: File exists

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

Хотя, вероятна какая какая-то из директив сервера подразумевает исполнение этой строчки и делает это неявно.

Идем дальше.

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

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

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

Ну и зачем тогда было выеживаться, что оно лучше? Это вроде как Admin где вы предложили (заметьте, сами предложили) альтернативу, а на вопрос чем лучше, слились как первоклассница в талксе.

Ну и зачем тогда было выеживаться, что оно лучше? Это вроде как Admin где вы предложили (заметьте, сами предложили) альтернативу, а на вопрос чем лучше, слились как первоклассница в талксе.

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

Лучше бы перейти на «личности» т.е. конфиги в студию и ip r с серверов. ) Но пока могу предположить это client-to-client убрать если есть.
Будет конкретика, готов сам тестовый вариант прогнать, даже интересно стало, а вдруг я в чем-то не прав :)

Ну поясните же, все ждут. Я не пользовал в проде, описание, ну мало ли описание, вы чем-то кроме «заглавной» убедите что оно лучше (третий раз повторюсь это вы сказали что оно лучше). А то по заглавной и softether просто самолет, но чей-то большинству в прод сыкотно его тыкать.

Всё на виртуалках vbox с bridge. Всё без путей на файлы.

сервер1 192.168.1.23

сервис для клиентов:

port 1194
proto udp
dev tap
server 192.168.88.0 255.255.255.0
push "route 192.168.88.0 255.255.255.0"
keepalive 1800 4000
cipher DES-EDE3-CBC # Triple-DES
comp-lzo
max-clients 10
persist-key
persist-tun
verb 0
mute 20

сервис для сервера2:

port 1195
proto udp
dev tap
server 10.0.0.0 255.255.255.0
keepalive 1800 4000
cipher DES-EDE3-CBC # Triple-DES
comp-lzo
max-clients 10
persist-key
persist-tun
mute 20

клиенты (полученный адрес подключенного к серверу2 заменяется для непересечения диапазона после подключения): два клиента подключены к remote 192.168.1.23, один к 192.168.1.24 всего три клиента:

proto udp
port 1194
dev tap
tls-client
topology subnet
mtu-test
pull
nobind
resolv-retry infinite
persist-key
persist-tun
ns-cert-type server
comp-lzo
mute 20
cipher DES-EDE3-CBC
auth-nocache

сервер2 192.168.1.24

сервис для клиента:

port 1194
proto udp
dev tap
server 192.168.88.0 255.255.255.0
keepalive 1800 4000
cipher DES-EDE3-CBC # Triple-DES
comp-lzo
max-clients 10
persist-key
persist-tun
verb 0
mute 20

клиент-сервер2 для сервера1

proto udp
port 1195
dev tap
remote 192.168.1.23
tls-client
topology subnet
mtu-test
pull
nobind
resolv-retry infinite
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 0
mute 20
cipher DES-EDE3-CBC

Как и обещал, накостылил рабочий вариант. В конфигах буду приводить только необходимые опции. Тестировал на tun
Сеть клиентов 10.3.0.0 сеть между серверами 10.5.0.0
Роутинг на серверах прописывается через ssh
Сервера работают от пользователя openvpn
Сервер1
Конфиг сервера для клиентов

dev               tun1
server            10.2.0.0 255.255.255.0
learn-address    /etc/openvpn.test/cl-up.sh

ifconfig-push 10.3.0.5 10.3.0.6
push "route 10.3.0.0 255.255.255.0"
push "route 10.5.0.0 255.255.255.0" # это осталось от тестирования

ifconfig-push 10.3.0.9 10.3.0.10
push "route 10.3.0.0 255.255.255.0"
push "route 10.5.0.0 255.255.255.0" # это осталось от тестирования

action=$1;
addr=$2;
case ${action} in
  add)
   /usr/bin/sudo /sbin/ip ro del ${addr}
   /usr/bin/sudo /sbin/ip ro add ${addr} dev ${dev}
   /usr/bin/ssh $IP_SERVER2 /usr/bin/sudo /sbin/ip ro del ${addr}
   /usr/bin/ssh $IP_SERVER2 /usr/bin/sudo /sbin/ip ro add ${addr} dev tun17
   ;;
 delete)
   /usr/bin/sudo /sbin/ip ro del ${addr}
   /usr/bin/ssh $IP_SERVER2 /usr/bin/sudo /sbin/ip ro del ${addr}
   ;;
esac
exit 0

dev               tun5
server            10.5.0.0 255.255.255.0

ifconfig-push 10.5.0.17 10.5.0.18
iroute 10.3.0.0 255.255.255.0

openvpn ALL=(ALL:ALL) NOPASSWD: /sbin/ip

Сервер2
Конфиг сервера для клиентов скопирован с Сервер1

dev               tun12
server            10.7.0.0 255.255.255.0

action=$1;
addr=$2;
case ${action} in
  add)
   /usr/bin/sudo /sbin/ip ro del ${addr}
   /usr/bin/sudo /sbin/ip ro add ${addr} dev ${dev}
   /usr/bin/ssh $IP_SERVER1 /usr/bin/sudo /sbin/ip ro del ${addr}
   /usr/bin/ssh $IP_SERVER1 /usr/bin/sudo /sbin/ip ro add ${addr} dev tun5
   ;;
 delete)
   /usr/bin/sudo /sbin/ip ro del ${addr}
   /usr/bin/ssh $IP_SERVER1 /usr/bin/sudo /sbin/ip ro del ${addr}
   ;;
esac
exit 0

dev tun17
up /etc/openvpn.test-cl/vpnup

/bin/su openvpn -c "/usr/bin/ssh $IP_SERVER1 /sbin/ip r s dev tun1 |
                                               /bin/grep '10.3.0' |
                                               /bin/cut -d ' '  -f 1" |
while read A; do
 /sbin/ip ro add $A dev $1
done

Куда доставлять пиво?

Рад был помочь.

ЗЫ Вся эта хрень была протестирована на вполне удаленных друг от друга машинках (не на отдельно взятой лаборатории в виртуалках), одна из которых еще и по pptp работает. Вобщем вполне рабочий вариант... только «долизать» скрипты. Ну или если совсем параноя то методы общения между серверами для получения/прописывания роутинга. Что тоже на такая уж проблема как кажется большинству, например «накалякать» свой демон который будет выполнять нужные команды.
Успехов.

Сработал пока вариант с мостами.

Так куда доставлять пепси или чего еще?