Decentralized OpenVPN

[Va_]

Здравствуйте!

Поставили задачу организовать защищенную сеть, в которой клиенты взаимодействуют не через центральный сервер. Во всех вариантах OpenVPN, которые я видел, трафик между хостами ходит через сервер. Серевер выпал – связи нет. Что в моём сценарии более чем возможно. Как я понимаю, теоретически достаточно чтобы у каждого клиента были открытые ключи всех остальных клиентов.

Хотелось бы, чтобы это был OpenVPN.

В какую сторону смотреть? Что гуглить?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[LimpTeaM]

в сторону TAP интерфейса думается и соединения типа мост + резервирование вторым туннелем. Но это в основном получает точка-точка(2 сети)

[Va_]

больше всего меня беспокоит, что в большинстве VPNов за аутентификацию отвечает Центральный Сервер. Но не в этом случае...

[LimpTeaM]

http://openvpn.net/index.php/open-sourc ... dging.html
попробуйте может и получится

http://forum.ixbt.com/topic.cgi?id=14:40906
здесь на русском.

В принципе в чем проблема раскидать ключи?
Например
1. канал офис1-офис2 TAP\TUN авторизует офис 1
2. канал офис2-офис1 TAP|TUN авторизует офис2

[Va_]

Дело не в резервировании каналов. Дело в том, что vpn-сервер может пропасть с концами (утонуть). Не должно быть единого узла аутентификации. Узлов N штук. Пусть их три: С1 (сервер1), К1(клиент1), К2(клиент2). И если в таком впн пропадет С1, то никакой связи К1-К2 не будет. А оно надо. Очень надо.

Нужен своего рода "безсерверный" впн.

VPN bridge сейчас тестану, но что то мне не кажется что это выход.

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

[Va_]

UPD Bridge профита не принес. Трафик через сервер.

[sidney]

купите VPS, профит будет огромный, и не только с vpn

[nnmax]

Дело не в резервировании каналов. Дело в том, что vpn-сервер может пропасть с концами (утонуть). Не должно быть единого узла аутентификации. Узлов N штук. Пусть их три: С1 (сервер1), К1(клиент1), К2(клиент2). И если в таком впн пропадет С1, то никакой связи К1-К2 не будет. А оно надо. Очень надо.

Нужен своего рода "безсерверный" впн.

VPN bridge сейчас тестану, но что то мне не кажется что это выход.

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

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

[Va_]

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

Спасибо. Я вижу сейчас только следующую схему:
Есть хост "А" , с виртуальными интерфейсами tap0..tapN. В vpn-сети 0 на интерфейсе tap0 его адрес 192.168.0.1/24. И он же является сервером.
У этого же хоста в тот же момент времени все остальные интерфейсы tap1..tapN подключены к сетям vpn1..vpnN. С адресами соответственно 192.168.1.1/24 - 192.168.N.1/24. Где хост "А" уже является клиентом.

Все остальные хосты соотвтетственно. Итого имеем N виртуальных сетей, N^2 интерфейсов и конфигурационных файлов к ним. На каждом хосте (N-1) клиентский ключ и один серверный.

Я только так вижу пока. Если можно как то иначе, то не молчите

Вообще хотелось бы по одному виртуальному интерфейсу у хоста (один интерфейс, один IP). При этом чтоб openvpn сам понимал какому хосту каким ключом шифровать. Я бы один раз распространил ключи и не настраивал бы стопятьсот сетей. Мечты-мечты..

И кстати насколько я помню в опенвпне нельзя сказать кто кого авторизует т.к проверяются оба конца,как инициатор так и отвечающая сторона.

Спасибо за инфу.

купите VPS, профит будет огромный, и не только с vpn

Не в этом случае. Я ж говорю, сервер утонуть может.

[sidney]

Код: Выделить всё

Не в этом случае. Я ж говорю, сервер утонуть может.  

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

[Гость]

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

Спасибо. Я вижу сейчас только следующую схему:
Есть хост "А" , с виртуальными интерфейсами tap0..tapN. В vpn-сети 0 на интерфейсе tap0 его адрес 192.168.0.1/24. И он же является сервером.
У этого же хоста в тот же момент времени все остальные интерфейсы tap1..tapN подключены к сетям vpn1..vpnN. С адресами соответственно 192.168.1.1/24 - 192.168.N.1/24. Где хост "А" уже является клиентом.

Все остальные хосты соотвтетственно. Итого имеем N виртуальных сетей, N^2 интерфейсов и конфигурационных файлов к ним. На каждом хосте (N-1) клиентский ключ и один серверный.

Я только так вижу пока. Если можно как то иначе, то не молчите

Вообще хотелось бы по одному виртуальному интерфейсу у хоста (один интерфейс, один IP). При этом чтоб openvpn сам понимал какому хосту каким ключом шифровать. Я бы один раз распространил ключи и не настраивал бы стопятьсот сетей. Мечты-мечты..

И кстати насколько я помню в опенвпне нельзя сказать кто кого авторизует т.к проверяются оба конца,как инициатор так и отвечающая сторона.

Спасибо за инфу.

купите VPS, профит будет огромный, и не только с vpn

Не в этом случае. Я ж говорю, сервер утонуть может.

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

[nnmax]

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

Спасибо. Я вижу сейчас только следующую схему:
Есть хост "А" , с виртуальными интерфейсами tap0..tapN. В vpn-сети 0 на интерфейсе tap0 его адрес 192.168.0.1/24. И он же является сервером.
У этого же хоста в тот же момент времени все остальные интерфейсы tap1..tapN подключены к сетям vpn1..vpnN. С адресами соответственно 192.168.1.1/24 - 192.168.N.1/24. Где хост "А" уже является клиентом.

Все остальные хосты соотвтетственно. Итого имеем N виртуальных сетей, N^2 интерфейсов и конфигурационных файлов к ним. На каждом хосте (N-1) клиентский ключ и один серверный.

Я только так вижу пока. Если можно как то иначе, то не молчите

Тут у вас опять появляются звенья клиент-сервер, а желательно получить так чтобы любая из точек могла быть инициатором туннеля, умеет так опенвпн?

Вообще хотелось бы по одному виртуальному интерфейсу у хоста (один интерфейс, один IP). При этом чтоб openvpn сам понимал какому хосту каким ключом шифровать. Я бы один раз распространил ключи и не настраивал бы стопятьсот сетей. Мечты-мечты..

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

[snorlov]

Va_
Простите, но я, например не понял, что вы хотите, то, что вы обзываете сервером, на самом деле создает шифрованный канал между собой и другим устройством, добавляя дополнительно маршрутизацию и инкапсуляцию, вы можете реализовать это кроме openvpn и простым ipsec'сом в транспортном режиме.

[Va_]

Я снова тут

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

Спасибо. Можно линк на пример такого конфига? Я с ipsec'ом дела не имел ещё. Начинать с манов некогда. Посоветуйте "боевую" статью, пожалуйста.

Тут у вас опять появляются звенья клиент-сервер, а желательно получить так чтобы любая из точек могла быть инициатором туннеля, умеет так опенвпн?

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

кстати в вашей схеме хосты это просто хосты за ними нет никаких сетей которые должны через этот впн бегать?

Никаких сетей, никаких других хостов. Один ПК, где будет много чего крутиться. Поэтому транспортный режим не хочется. В крайнем случае возможен единичный проброс отдельных портов во внутреннюю сеть (NAT за хостом).

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

Под сервером понимаю каждый отдельновзятый ПК, который работает как openVPN-сервер. А ещё этот ПК является openVPN-клиентом в других openvpn-сетях. И на этом же ПК работают всякие сервисы, БД и прочее.

[nnmax]

Нужно тестировать, готовый конфиг разве что на site-2-site можно без труда найти.

[nnmax]

Кстати тут ковырял isakmpd и наткнулся на пример настройки для трех узлов файл лежит в /usr/local/share/examples/isakmpd/VPN-3way-template.conf

Код: Выделить всё

# In pseudographics:   XXX --- YYY
#                         \   /
#                          ZZZ
#