[решено] Связать три филиала по Openvpn

[CJ F.A.N.]

Всем привет! Хочу проконсультироваться. Стоит задача связать три филиала организации между собой. Решил применить Openvpn, есть сервер со статикой, куда и накатил openvpn server. Что необходимо сделать, чтобы пользователи с одного филиала имели доступ к сети другого филиала (точнее к файловому серверу)? Можно, знаю, установить всем сотрудникам openvpn, сделать подключение, но сотрудников очень много. Можно ли как-то смаршрутизировать сети на уровне прокси-серверов (в каждом филиале есть шлюз прокси на debian 7)?Можно ли обойтись установкой и подключением openvpn только на шлюзы?Необходимо делать разные подсети в филиалах?

Добавлено:
Частично реализовал. Расскажу подробнее.
Сервера - шлюза 2 штуки на данный момент. Сервер1 = 192.168.1.51, Сервер2=192.168.2.1.
Сеть, к которой все филиалы должны получать прямой доступ: 1) 192.168.1.0 (конкретно интересует файловый сервер 192.168.1.2, пока что).
На одном филиале сменил подсеть на 192.168.2.0. Сервер Openvpn стоит на сервере1. Так вот, в конфиге Опенвпн сервера прописал push "route 192.168.1.0 255.255.255.0" , теперь шлюз "Сервер2", подключенный через Openvpn к серверу1 пингует его Ip адреса. и конкретно 192.168.1.2. Но клиенты локальной сети шлюза "Сервер2" ничего не знают об 192.168.1.2. Как настроить маршрутизацию на шлюзе "Сервер2"? Или надо только прописывать маршруты вручную у всех клиентов подсети 192.168.2.0 на их машинах ????

[MakaBooka]

Или надо только прописывать маршруты вручную у всех клиентов подсети 192.168.2.0 на их машинах ???? »
Прописывание маршрутов вручную это порочная практика. Есть dhcpd, который умеет в случае необходимости раздавать маршруты клиентам. Это как раз такая задача. Клиенты 192.168.2.0/24 должны знать маршрут на 192.168.1.0/24 только если их маршрут по умолчанию отличается от 192.168.2.1.

[CJ F.A.N.]

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

[MakaBooka]

если у вас венда и домен, я думаю есть способ всем централизованно поменять настройки сети на DHCP. если не венда - можно наваять скрипт, который обойдёт всем клиентов и поменяет настройки сети опять-таки на DHCP. если структура сети сделана неверно изначально, надо переделывать. разговаривать с начальством, объяснять, почему "сейчас всё работает" не устраивает, объяснять что малейшие изменения в неправильно построенной сети могут привести к проблемам, либо препятствующим решить конкретную задачу (пример - соединить два филиала), либо к простоям. что решение костылями возможно, но вызовет ещё большие осложнения в будущем. Кроме душеспасительной говорильни должен быть в наличии план-график исправления ситуации, с отдельно красным цветом выделенным даунтаймом. с вариантами предложений как его сократить или избежать. Потому что неразрешимые технически проблемы можно решить организационным методом.

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

соответственно потом все переводятся на DHCP, при чём на DHCP-сервере прописаны IP-MAC лишь для некоторых, остальные просто берут из диапазона. В каждой сети свой DHCP. Ну вот после установления порядка в том, что есть, связывание филиалов выглядит легко и просто, и в сети прекращается цепочка подпирания костылей костылями.

[CJ F.A.N.]

все понял. У нас на заводе собран мною Samba4 PDC, в принципе он работает, групповые политики создает, но к нему подключены лишь с десяток компьютеров (домен новый, раньше там все было без домена). В офисе есть контроллер домена, опять таки не все в нем((((изначально структура сети неверная была, да и нужны все таки статические IP у сотрудников, так как приходится цепляться к ним по VNC, так что привязку IP-MAC делать придется

[MakaBooka]

да и нужны все таки статические IP у сотрудников, так как приходится цепляться к ним по VNC »
Вас спасёт DNS. А ещё точнее - DDNS (https://wiki.debian.org/DDNS). Этот вариант - хороший, особенно если имя компьютера назначается со смыслом, типа dep02ws03 (отдел второй, рабочая станция №3) или cab12ws07 (кабинет 12, рабочее место №7). Некоторые админы называют рабочие станции по номерам (это не очень удобно, в название можно поместить больше информации) или по фамилиям пользователей (ИМХО это совсем никуда не годится, потому что переходы сотрудников, увольнения и внезапное замужество сотрудниц штука нередкая).
На крайний случай - берёте файлик dhcp.leases и из него изготавливаете записи для конфига dhcpd. Тогда все получают жёстко заданные IP. Этот вариант - плохой, потому что при смене компьютера/сетевухи от админа требуются телодвижения, а это в высшей степени неправильно. Включение компьютеров в домен нужно, ясное дело, ускорить.
Я бы предложил работы в таком порядке:
- настроить DDNS;
- включать оставшиеся компьютеры в домен;
- выкидывать шары с локальных машин на сервер. попутно настроить бэкап;
- введённые в домен без локальных шар компьютеры перевести на DHCP;
- раздавать маршруты по DHCP, завершая объединение филиалов
Как-то так.

[Rezor666]

CJ F.A.N., Почитайте документацию по OpenVPN, там все расписано.
И еще, совет MakaBooka ерундовый.
Когда кто-то из сети 2 посылает пакет в сеть 1, именно шлюз должен принимать решения что делать с данным пакетом, у пользователей ничего трогать не надо.

[CJ F.A.N.]

Rezor666, да вроде читаю, то ли понять не могу, то ли не исправно что-то. В общем задача то какая. Ндао при минимальных затратах соединить филиалы с одним сервером. Решил: поставить на каждый шлюз филиалов openvpn, и подлключить к нашему серверу, и надо чтобы сеть нашего шлюза видела все сети филиалов, и чтобы сети филиалов видели нашу сеть. Вроде настроил, но только работает, что филиалы нас видят. Но мы филиалы не видим, какие опции ввести надо?
Вот конфиг. Задача: чтобы подсеть 2.0 видела подсеть 3.0 и наоборот
mode server

port 9375
proto tcp
dev tap
client-config-dir /etc/openvpn/ccd
push "route 192.168.3.0 255.255.255.0"
;push "route 192.168.2.0 255.255.255.0"

;push "route 192.168.3.0 255.255.255.0"

;push "route-gateway 10.8.0.1"

;push "dhcp-option DNS 10.8.0.1"

route 192.168.2.0 255.255.255.0
;iroute 192.168.2.0 255.255.255.0
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server 10.8.0.0 255.255.255.0
;server-bridge 192.168.3.1 255.255.255.0 192.168.3.100 192.168.3.252

ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
tls-auth ta.key 0
client-to-client
cipher DES-EDE3-CBC
verb 3
;push "route 10.8.0.0 255.255.255.0"

[MakaBooka]

Когда кто-то из сети 2 посылает пакет в сеть 1 »
Я написал - если шлюз не дефолтный, то маршрут надо раздать пользователям. Что не так?

Вроде настроил, но только работает, что филиалы нас видят. »
кинь сюда трейс
Но мы филиалы не видим »
кинь сюда трейс

заодно посмотришь сам :)

[CJ F.A.N.]

Трейс со шлюза филиала на наш сервер:
traceroute to 192.168.3.2 (192.168.3.2), 30 hops max, 60 byte packets
1 10.8.0.1 (10.8.0.1) 69.069 ms 138.920 ms 138.936 ms
2 192.168.3.2 (192.168.3.2) 138.944 ms 138.953 ms 138.961 ms


трейс с нашего шлюза до айпишника из филиала:
traceroute to 192.168.2.96 (192.168.2.96), 30 hops max, 60 byte packets
1 172.16.0.84 (172.16.0.84) 6.565 ms 6.632 ms 6.708 ms
2 79.126.125.161 (79.126.125.161) 30.058 ms 30.052 ms 30.040 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *


из последнего трейса видно, что пакеты уходят куда-то в интернет, но до шлюза филиала не доходят видать

[Tonny_Bennet]

CJ F.A.N., а теперь если можно по порядку.

Три филиала. У всех внешние IP адреса статические? Или динамические? Или у кого-то такие а у кого-то такие?

Локальные сети? желательно бы описать адресацию внутри каждой сети, с маской и шлюзом.

Серверы на debian, какие у них адреса внутри сети.

Логика проста. На одном сервер клиент, на остальных сервер. Клиенты подключаются к серверу, получают некоторые адреса. Сервер добавляет маршруты в клиентские сети, клиенты добавляют маршрут в сеть сервера. Выключается NAT между локальными сетями. Всё работает.

[CJ F.A.N.]

Tonny_Bennet, на данный момент, основная организация (Сеть1) имеет подсеть 192.168.1.0 (дополнительно назначил некоторым серверам айпишники из подсети 192.168.3.0, чтобы связывать все филиалы более безопасно и желательно без смены подсетей в них). Один из филиалов имеет подсеть 192.168.2.0 (сеть2). Все шлюзы имеют статические адреса. Идея: поставить клиенты опенвпн на все шлюзы всех филиалов, чтобы связать шлюзы с нашим. Проблема в том, что клиенты локальных сетей филиалов видят нашу подсеть (сеть1), а мы видим только шлюзы филиалов, но клиентов локальных сетей этих филиалов не видим и не пингуем. Товарищ выше говорит что надо либо DHCP раздавать всем, либо вручную настраивать маршруты, но это проблемно, тем более что некоторые филиалы находятся в других областях, и боюсь, что перенастройка всех компьютеров тех локальных сетей будет проблематична, поэтому ищу способ, как объединить подсети, настраивая только шлюзы. Почти получилось, вот только как бы в одну сторону....... Я подозреваю, что неверен конфиг сервера опенвпн, собственно по нему и спрашиваю, правильно настроил или нет

Забыл. Наш шлюз имеет адрес 192.168.1.51 (192.168.3.51), адрес шлюза одного из филиалов 192.168.2.1)
Все шлюзы построены на Debian 7

[Tonny_Bennet]

CJ F.A.N., ещё было бы неплохо нарисовать план-схему сети. Хотя бы такую:

http://s017.radikal.ru/i439/1409/f5/34534e9c092dt.jpg (http://radikal.ru/fp/c3b2177dfff24a4d87f2e03be9d1beea)

(дополнительно назначил некоторым серверам айпишники из подсети 192.168.3.0, чтобы связывать все филиалы более безопасно и желательно без смены подсетей в них) »
Вопрос зачем???

Какой адрес получает OpenVPN клиента на стороне сети2? Вам нужно добавить маршрут на шлюзе сети1 такого вида:

route add -net 192.168.2.0/24 gw <адрес OpenVPN клиента>

Ещё посмотрите правила NAT в 1-й сети.

[CJ F.A.N.]

Tonny_Bennet,
http://s019.radikal.ru/i629/1409/72/b6714fe5a383t.jpg (http://radikal.ru/fp/876d4874f3c74891a14e29f1c690a27e)
вот так вот нужно.
Вопрос зачем??? »
потому что в сети 2 не все IP получилось перенастроить на подсеть 192.168.2.0. Как я выше писал, раньше подсеть была одна и так же, и дабы не было конфликтов, пришлось перенастроить, но не всех. Возникли проблемы, во первых, с шарами, во вторых, там специфические программы, где лицензии привязываются к локальному IP, и после смены настроек сети лицензия слетала, а получить новую долго, а работу программы прерыват ьнельзя, вот так, поэтому было принято такое решение, селать, чтобы мы с подсети 1 видели все компьютеры филиала, а они некоторые наши серверы в подсети 192.168.3.0 или 192.168.1.0, как получится, вот не знаю как лучше сделать, запутался сам уже. Нат на нашем шлюзе в принципе ничего не перекрывает, вот активные маршруты из сети1:

Назначение Шлюз Маска сети Интерфейс
10.8.0.0 Ни одного 255.255.255.0 tap0
172.16.0.84 Ни одного 255.255.255.255 ppp0
192.168.1.0 Ни одного 255.255.255.0 eth2
192.168.3.0 Ни одного 255.255.255.0 eth2


шлюз на сети2 получает от Опенвпн сервера адрес 10.8.0.8, внешние IP примерные я указал на рисунке

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

[Tonny_Bennet]

Добавьте маршрут во 2-ю сеть на шлюзе первой сети
route add -net 192.168.2.0/24 gw 10.8.0.8

Если не заработает показывайте iptables с обоих шлюзов

iptables-save

[Rezor666]

Что не так? »
Все так, пропустил, прошу прощения.

CJ F.A.N., почитайте (http://www.lissyara.su/articles/freebsd/security/openvpn_via_nat/)эту статью, там все расписано.

[MakaBooka]

Вам нужно добавить маршрут на шлюзе сети1 такого вида:
Код:
route add -net 192.168.2.0/24 gw <адрес OpenVPN клиента> »

Лучше это делать при установлении VPN средствами OpenVPN.

[CJ F.A.N.]

Добавьте маршрут во 2-ю сеть на шлюзе первой сети »
Спасибо, все заработало! Остался последний вопрос: как корректнее добавлять этот маршрут при рестарте сервера в сети1 ?
Я пробовал в каталоге /etc/openvpn/ccd создать файлик для клиента, в котором директивой iroute добавляется маршрут, но ничего не происходит, как будто Openvpn не подхватывает настройки клиента, ну да ладно. Пока просто сделал скрипт, выполняющийся в rc.local , создающий статический маршрут
route add -net 192.168.2.0/24 gw 10.8.0.8

думаю, этого хватит=)

[MakaBooka]

но ничего не происходит, как будто Openvpn не подхватывает настройки клиента»

во всех непонятных случаях надо курить маны. как только случаи стали понятными, но поведение не совпадает с ожидаемым, надо курить логи.
если непонятное присутствует, с конфигами, логами и вопросами - по форумам.

вопрос ясен, давай конфиги и логи :)


Пока просто сделал скрипт, выполняющийся в rc.local »

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

[CJ F.A.N.]

MakaBooka,
server.conf

# cat /etc/openvpn/server.conf


mode server

port 9375
proto tcp
dev tap
client-config-dir /etc/openvpn/ccd
push "route 192.168.3.0 255.255.255.0"
;push "route 192.168.2.0 255.255.255.0"

;push "route 192.168.3.0 255.255.255.0"
;push "route-gateway 10.8.0.1"

;push "dhcp-option DNS 10.8.0.1"

route 192.168.2.0 255.255.255.0
;iroute 192.168.2.0 255.255.255.0
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
;server-bridge 192.168.3.1 255.255.255.0 192.168.3.100 192.168.3.252

ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
log /var/log/openvpn.log
tls-auth ta.key 0
client-to-client
cipher DES-EDE3-CBC
verb 3
;push "route 10.8.0.0 255.255.255.0"
;up /usr/sbin/openvpn_route.sh
user nobody
group nogroup


Конфиг клиента fil1, который и получает адрес 10.8.0.8
#cat /etc/openvpn/ccd/fil1
iroute 192.168.2.0 255.255.255.0

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

Конфиги openvpn-status.log и /var/log/openvpn.log ничего странного не показывают, ошибок там нет, просто данные о том, сколько клиентов подключено и какие им назначены mac и ip адреса