IMHO.WS

IMHO.WS (http://www.imho.ws/index.php)
-   Сети (http://www.imho.ws/forumdisplay.php?f=145)
-   -   Вопрос по организации OpenVPN между серверами и клиентами (http://www.imho.ws/showthread.php?t=148393)

metrim 29.08.2016 02:04

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

Почитал статейку https://habrahabr.ru/post/233971/ но там несмотря на то что на картинках рисуется (на сколько я понял) прописывается схема где один основной сервер, а все остальные устройства подключаются как клиенты

Мне же нужно, что был равнозначный канал между серваками, что бы по нему происходила репликация доменов, обмен данными и т.п. Ну а пользователи извне что бы подключались как клиенты к этой "облачной инфраструктуре"

Borland 29.08.2016 03:47

metrim
В любом случае при установлении соединения один из компьютеров будет выступать в роли сервера, второй в роли клиента. It's by design. :gigi:
Причём любой из компьютеров может выступать одновременно и как сервер, и как клиент (это определяется наличием и содержимым конфигов в папке программы).
Для межсерверного линка, в общем-то, без разницы кто сервер а кто клиент.
Для подключения пользователей тоже без разницы, но, как правило, всё-таки клиент на стороне пользователя, сервер на стороне сервера.

SinClaus 29.08.2016 09:33

BTW, openvpn не слишком любит пересылать широковещательные пакеты, которыми так любит разбрасываться винда, провайдер не умеет строить канал между ЦД?

metrim 30.08.2016 03:12

Цитата:

Сообщение от Borland (Сообщение 1786967)
Для межсерверного линка, в общем-то, без разницы кто сервер а кто клиент.

Хорошо, а допустим что будет коли "сервер" отвалится?
Можно ли как то обеспечить что бы существовали резервные узлы?

Plague 30.08.2016 10:21

Цитата:

Сообщение от metrim (Сообщение 1786975)
Хорошо, а допустим что будет коли "сервер" отвалится?

Какая-то странная постановка вопроса, имхо. :idontnow:
если сервер отвалится - работать не будет. Разве есть ещё какие-то варианты в аналогичном случае, например, с ftp, mail или smb? :confused: Так уж заведено. Есть устройство, которое подключается; и есть устройство к которому подключаются. другой схемы как-то не придумывается.

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

ps. теоретически, само приложение OpenVPN может одновременно коннектиться к нескольким серверам, и так же само являться сервером. Можно нагородить перехлест друг на друга, но как оно будет вести себя в плане распределения сетевых адресов - самому интересно :biggrin:

добавлено:
вообще, в конфиге есть вот такая ремарка:
Код:

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.

;remote 10.152.199.133 1194

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

Borland 30.08.2016 11:30

Цитата:

Сообщение от Plague (Сообщение 1786976)
Можно нагородить перехлест друг на друга, но как оно будет вести себя в плане распределения сетевых адресов - самому интересно

Можно, но бессмысленно. Отпад сервиса OpenVPN на устройстве автоматом порвёт все его соединения: что клиентские, что серверные. Так же, к слову, как и обрыв канала связи провайдера. "Померла так померла"...
При этом ничто не мешает пользователям коннектиться одновременно к двум (и более) серверам, и отпад одного из серверов никоим образом не скажется на коннекте со вторым.
Цитата:

Сообщение от metrim (Сообщение 1786975)
Можно ли как то обеспечить что бы существовали резервные узлы?

Если вы подразумеваете, что два сервера должны образовывать отказоустойчивый кластер - то OpenVPN здесь вообще не при делах, она только обеспечивает шифрованный канал связи (весьма, к слову, надёжный). Отказоустойчивость же серверов/кластера осуществляется совершенно другими средствами...

Plague 30.08.2016 11:54

Цитата:

Сообщение от Borland (Сообщение 1786977)
Можно, но бессмысленно. Отпад сервиса OpenVPN на устройстве автоматом порвёт все его соединения: что клиентские, что серверные.

я имел в виду не "друг другу навстречу" (бессмысленность этого абсолютно очевидна), а "на соседа слева, справа, и напротив". Эдакая пентаграмма, даже похлеще.

SinClaus 30.08.2016 12:22

Проще и надёжнее провайдерская L3 vpn для серверов и шлюзы в неё для клиентов. А в идеале - и сервера и клиенты в закрытой L3 vpn. Все доступны всем, и недоступны снаружи.
Полный mesh средствами openvpn дело довольно тёмное...

metrim 30.08.2016 12:29

Цитата:

Сообщение от Borland (Сообщение 1786977)
Отпад сервиса OpenVPN на устройстве автоматом порвёт все его соединения

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

Меня просто не греет идея, что остановился "сервер" и все, больше коннекта в сети нема.

Еще такой вопрос: а как с точки зрения безопасности установка опенВПН сервера на контроллере домена?

Borland 30.08.2016 12:39

Цитата:

Сообщение от Plague (Сообщение 1786978)
пентаграмма, даже похлеще.

Тогда уж проще как SinClaus предлагает: всё хозяйство в облаке, включая клиентские рабочие места, а клиенты подключаются туда через VPN-гейт и работают по RDP. Резервирование всего хозяйства в целом и VPN-гейта в частности при этом обеспечивается провайдером, причём прозрачно для потребителя услуги...
Избыточные же соединения клиентов между собой надёжности нисколько не прибавляют (хотя схема и может быть реализована): как я уже говорил, "померла так померла". К "мёртвому" серверу никакие ухищрения с обходным роутингом добраться не позволят.
Скрытый текст (только для групп: Administrator :: 6):
У вас нет прав чтобы видеть скрытый текст, содержащийся здесь.
Цитата:

Сообщение от metrim (Сообщение 1786980)
Хамачи вроде конектила всех туннелями (как чего в ней щас - не знаю). выбыль из строя любой из машин не преводил к распаданию сети.

Через себя коннектила. Выпадение из сети VPN-гейта той же хамачи обрушит сеть ничуть не хуже, чем выпадение вашего собственного...
Цитата:

Сообщение от metrim (Сообщение 1786980)
как с точки зрения безопасности установка опенВПН сервера на контроллере домена?

Точно так же, как подключение контроллера домена к дополнительной сети. Безопасность сервера снижается, ибо вы проделываете в его защите дополнительную "дырку" (открытый порт, проброшенный в интернет). Не очень существенно (если, конечно, всё правильно настроено), но снижается.

Plague 30.08.2016 12:42

SinClaus, провайдерская отдельных денег стоит ;)
к тому же весьма не символических. Например я за провайдерский VLAN 10 мбит плачУ практически столько же, сколько ему же за просто интернет-канал 12 мбит.
Другое дело, что интернет в том конце, куда идёт VLAN, как таковой отдельно вообще не нужен (в "потребительских масштабах", по крайней мере), так что выбор между "кидаем в разные точки интернет, и потом городим всё сами" / "просто покупаем VLAN у провайдера" был очевиден. Если же во всех удалённых концах интернет заведен в силу других потребностей, то покупать ещё и поверх всего этого VLAN - умножать расходы почти вдвое. Хотя, с другой стороны, при этом толщина канала становится уже независима друг от друга.... ХЗ, тут надо смотреть на реальные задачи. У меня например, тот же VLAN работает на 40% канала всего час в сутки (в этот час оно критично), все остальное время юзается время от времени, и скорость 10 мбит там задарма не нужна. Ну, в смысле, мне как-то по-барабану: будет файл в 1 мегабайт туда пролетать за секунду или за 5, а больше в остальное время там не ходит.


Цитата:

Сообщение от Borland (Сообщение 1786981)
К "мёртвому" серверу никакие ухищрения с обходным роутингом добраться не позволят.

дык если он помер, или линк на него у прова подох - его и VLAN не спасёт ;)

Цитата:

Сообщение от metrim (Сообщение 1786980)
Хамачи

точно такой же принцип, что и своей VPN, с той лишь разницей что на своей - конектимся к своему серверу, а с хамачи - куда-то в туево-кукуево.
Цитата:

Сообщение от Borland (Сообщение 1786981)
открытый порт, проброшенный в интернет

VPN-сервер не обязательно ставить на тот же комп, что и контроллер домена, если они в одной локали.

metrim 30.08.2016 14:45

Цитата:

Сообщение от Plague (Сообщение 1786982)
VPN-сервер не обязательно ставить на тот же комп, что и контроллер домена, если они в одной локали

Это был вероятно ответ на мой вопрос "высказанный в порядке бреда"
Просто есть компьютер с контроллером домена стоящий "в интернете" , вне организации, которая за NAT. Кроме того "снаружи" - еще несколько серверов.

Plague 30.08.2016 15:07

metrim, это был ответ на цитату там же выше мной приведённую, а именно, если брать полней:
Цитата:

Сообщение от Borland (Сообщение 1786981)
Цитата:

Сообщение от metrim (Сообщение 1786980)
как с точки зрения безопасности установка опенВПН сервера на контроллере домена?

Точно так же, как подключение контроллера домена к дополнительной сети. Безопасность сервера снижается, ибо вы проделываете в его защите дополнительную "дырку" (открытый порт, проброшенный в интернет). Не очень существенно (если, конечно, всё правильно настроено), но снижается.

---

Цитата:

Сообщение от metrim (Сообщение 1786985)
есть компьютер с контроллером домена стоящий "в интернете" , вне организации, которая за NAT.

То есть, он имеет вообще прямой IP? тогда и никаких пробросов порта не нужно, разумеется.

Кстати говоря, ему ВСЁ РАВНО не обязательно быть сервером VPN. Он может быть и клиентом - и стучаться к любой другой машине, которая выступает в качестве vpn-сервера.
По-моему, не доходит главного: с точки зренья топологии VPN - пофиг где сервер, где клиент, в своей сети они имеют IP из одного сетевого сегмента (задается в конфиге сервера) и видят друг друга так, как будто они стоят в одном помещении на одном свиче (у нас с Борландом такое благополучно фунциклирует уж лет 5, а то и больше). А с точки зренья безопасности - я бы делал сервером менее нагруженную важными данными и трафиком машину, ибо сервер держит открытым порт для входящих соединений, клиент - нет. Но, разумеется, если сервер будет за NAT, то на него порт придется на роутере прописывать. И конечно, желательно сервером делать более энерго-защищённую машину. Такой вот баланс "за/против"

Plague 30.08.2016 16:13

Чуть не упустил еще один момент про "провайдерский VLAN": это всё работает в случае если все наши точки сидят на одном провайдере и в одном населенном пункте. ХЗ, сможет ли например, какой-то гигант типа Билайна сгородить VLAN между разными своими филиалами/городами, но думается мне, что это будет стоять ещё более дополнительных денег ;)

metrim 30.08.2016 17:09

Цитата:

Сообщение от Plague (Сообщение 1786986)
По-моему, не доходит главного

Скорее ИМХО тут каждый о своей специфике говорит ;)

У меня ситуация: есть сеть предприятия, в которой стоит сервер, контроллер домена ПК, оборудование и пр. Все это дело находится за несколькими NAT , с весьма недружелюбными сисадминами, которые препятствовать мне не будут ,но и помогать - отказываются. Прикидыываются валенками. Что тут, отчего и почему - особенности гиганской и слабо контролируемой организации. Резюме: никакой возможности прописать маршруты извне к "сети предприятия" - у меня нема, соответственно и сервер ОпенВПН внутри сети существовать просто не может, никто "извне" - к нему не достучится.
До кучи еще и весь канал "сети предприятия" в интернет - крайне неустойчив. Када угодно его могут просто по хотелке обрубить на неустановленное время

Так же, в рамках развития инфраструктуры я обзавелся:

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

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

Plague 31.08.2016 00:17

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

на всякий случай: для того чтоб поднять несколько серверов/клиентов на одной машине - не нужно ставить несколько экземпляров приложения. Сколько оно файлов *.ovpn (для виндового варианта) в своей директории config найдет - столько соответственно конфигов и будет обслуживать. Хоть десяток серверов и десяток клиентов.

ещё рекомендуется поднять ему приоритет на максимум:
Код:

[HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN]
"priority"="HIGH_PRIORITY_CLASS"
[HKEY_LOCAL_MACHINE\SOFTWARE\OpenVPN-GUI]
"priority"="HIGH_PRIORITY_CLASS"

для винды
Код:

openvpn_flags="--nice -20"
для никсы.

metrim 31.08.2016 04:44

Цитата:

Сообщение от Plague (Сообщение 1786999)
на всякий случай: для того чтоб поднять несколько серверов/клиентов на одной машине - не нужно ставить несколько экземпляров приложения.

Я тоже так думал
Однака:
Цитата:

All TAP-Windows adapters on this system are currently in use.
Exiting due to fatal error
Типа програма цстановила ток один адаптер, а откедова дополнительные то брать?

добавлено через 10 минут
Кстати, а какими параметрами можно управлять присвоением айпи подключающихся к серверу клиентов, что бы хотя бы изобразить более-менее статическую адресацию?

добавлено через 11 минут
Ну и вообще: где почитать краткои нубо-доступно по настройкам ОпенВПН DHCP параметров, прописыванию DNS, маршрутов, изоляции клиентов и т.д.?
Что то совсем простое, доступное далекому от айти человеку, т.е. мне

Borland 31.08.2016 11:32

Цитата:

Сообщение от metrim (Сообщение 1787002)
откедова дополнительные то брать?

Пуск->Все программы->TAP-Windows->Utilities->Add a new TAP virtual ethernet adapter (от имени администратора под осями свежее чем 2003 сервер).
Рекомендую переименовать TAP-адаптеры из стандартного "Подглючение по локальной сети N" во что-нибудь типа "TAP_N". Для удобства. Используется в конфигах
Цитата:

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
dev-node Tap_0
На каждый клиентский и на каждый серверный конфиг требуется отдельный TAP-адаптер.

Цитата:

Сообщение от metrim (Сообщение 1787002)
а какими параметрами можно управлять присвоением айпи подключающихся к серверу клиентов, что бы хотя бы изобразить более-менее статическую адресацию?

В конфиге сервера
Цитата:

# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
Файлик (в данном случае ipp.txt) будет сохранять соответствие IP клиенту.
Сервер будет использовать первый IP из сети, задаваемой параметром
Цитата:

# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 192.168.11.0 255.255.255.0
Остальные будут выделяться клиентам.
Цитата:

Сообщение от metrim (Сообщение 1787002)
где почитать

Например тут и тут.

metrim 03.09.2016 06:45

Ок, спасибо всем откликнувшимя !
Разбираюсь, вроде работает, но подглючивает зверски.
Рытье в интернете натнуло еще на идею попытаться пролезть через ipv6, много многообещающих описаний по этому поводу с применением gogoCLIENT , только сам сервис уже вроде недостпен.
Какие есть варианты по данному поводу ?

Plague 03.09.2016 10:27

Цитата:

Сообщение от metrim (Сообщение 1787049)
подглючивает зверски

оно не любит SMB-шары с большим к-вом файлов в них (причем именно читать. если копировать туда или оттуда "вслепую", то всё нормально вроде), да и как написал SinClaus, широковещательные пакеты, которыми страдает Netbios. Я бы посоветовал его вырубить, и юзать обращения по IP, если возможно.


Часовой пояс GMT +4, время: 15:46.

Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.