[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. Этот вариант - хороший, особенно если имя компьютера назначается со смыслом, типа 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  * * *

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