Настройка openvpn.

[andy_k]

Добрый день!

Поставили задачу соединить два филиала с центральным магазином.
В каждом филиале уже трудится шлюз на базе altlinux, в одном 6й версии, в другом 7й, в центральном магазине стоит шлюз на базе 7й версии.
В центральном магазине я на шлюзе с помощью альтератора поднял OpenVPN сервер, подписал сертификаты от двух клиентов. Все соединилось, запустилось, но меня смущает момент, что если не ставить галку "VPN шлюз по умолчанию", то вроде соединение есть, а главный сервер не пингуется, а если поставить галку, то все филиалы начинают ходить в интернет через главный шлюз.
В интернете все советуют поправить настройки server.conf, а я не смог найти его в папке etc, нашел один в папке usr, но кажется он там для образца лежит.
Подскажите как настроить сеть так, что при соединении vpn филиалы могли ходить только в сеть центрального магазина, а в интернет ходили через свое сетевое соединение. 

[ruslandh]

Все соединилось, запустилось, но меня смущает момент, что если не ставить галку "VPN шлюз по умолчанию", то вроде соединение есть, а главный сервер не пингуется, а если поставить галку, то все филиалы начинают ходить в интернет через главный шлюз.

А кто соединение устанавливает - etcnet или NetworkManager?
По идее нужен шлюз не по-умолчанию, а шлюз на конкретные адреса, в терминологии etcnet :
не
default via 10.0.0.254
а
10.0.1.0/24 via 10.0.0.254

[speccyfan]

Все верно, нужно глянуть server.conf (понятия не имею где он лежит в случае настройки альтератором) и там смотреть в сторону push.
Т.е. может быть так:
push "route-gateway 192.168.0.1"
а вам надо может как-то так:
push "route 192.168.0.0 255.255.255.0"

[andy_k]

А кто соединение устанавливает - etcnet или NetworkManager?
По идее нужен шлюз не по-умолчанию, а шлюз на конкретные адреса, в терминологии etcnet :
не
default via 10.0.0.254
а
10.0.1.0/24 via 10.0.0.254

Да, главное где это прописать? Читал, что это надо делать на стороне сервера.

[andy_k]

Все верно, нужно глянуть server.conf (понятия не имею где он лежит в случае настройки альтератором) и там смотреть в сторону push.
Т.е. может быть так:
push "route-gateway 192.168.0.1"
а вам надо может как-то так:
push "route 192.168.0.0 255.255.255.0"

Подскажите пожалуйста в каком файле править эти настройки?

[asy]

Подскажите пожалуйста в каком файле править эти настройки?

/etc/net/ifaces/tunX/ovpnoptions, если это альтератором настраивалось.

[andy_k]

Спасибо!
Помогло в файл /etc/net/ifaces/tunX/ovpnoptions прописать
push "route 192.168.10.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
После этого пакеты стали ходить как надо.
Ребят,  спасибо вам!

[andy_k]

Ребят, отвез все на место, но  возникла еще одна проблема. Не получается зайти на компьютеры филиала из центрального офиса.

Вот параметры сети
192.168.10.0/24 Центальный офис
192.168.0.0/24 Филиал
10.8.0.0/24 Промежуточная сеть ВПН.


Пинг с сервера впн филиала идет до компьютеров в центральном офисе.

Код: [Выделить]

[admin@driver-router ~]$ traceroute 192.168.10.2
traceroute to 192.168.10.2 (192.168.10.2), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  27.977 ms  27.909 ms  34.227 ms
 2  192.168.10.2 (192.168.10.2)  35.383 ms  35.056 ms  34.710 ms
Пинг с компьютеров филиала идет до компьютеров в центральном офисе.

Код: [Выделить]

C:\Users\user>tracert 192.168.10.2
Трассировка маршрута к WIN-DRNU7MM7287 [192.168.10.2]
с максимальным числом прыжков 30:
  1     1 ms    <1 мс    <1 мс  192.168.0.1
  2    27 ms    26 ms    27 ms  10.8.0.1
  3    31 ms    28 ms    27 ms  WIN-DRNU7MM7287 [192.168.10.2]
Трассировка завершена.
Пинг с сервера центрального офиса до сервера впн филиала идет.

Код: [Выделить]

C:\Users\Администратор> tracert 192.168.0.1
Трассировка маршрута к 192.168.0.1 с максимальным числом прыжков 30
  1    <1 мс    <1 мс    <1 мс  192.168.10.1
  2    28 ms    28 ms    27 ms  192.168.0.1
Трассировка завершена.
Пинг с компьютеров центрального офиса до компьютеров филиала не идет.

Код: [Выделить]

C:\Users\Администратор> tracert 192.168.0.2
Трассировка маршрута к 192.168.0.2 с максимальным числом прыжков 30
  1    <1 мс    <1 мс    <1 мс  192.168.10.1
  2    27 ms    29 ms    30 ms  10.8.0.14
  3     *        *        *     Превышен интервал ожидания для запроса.
Вот таблицы маршрутизации обоих серверов:

Сервер центрального офиса.

Код: [Выделить]

[admin@openvpn ~]$ ip route
default via 192.168.2.195 dev ens32
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0  proto kernel  scope link  src 10.8.0.1
192.168.0.0/24 via 10.8.0.2 dev tun0
192.168.2.0/24 dev ens32  proto kernel  scope link  src 192.168.2.192
192.168.10.0/24 dev ens33  proto kernel  scope link  src 192.168.10.1
Сервер впн филиала.

Код: [Выделить]

[admin@driver-router ~]$ ip route
default dev ppp1  scope link
10.8.0.0/24 via 10.8.0.13 dev tun0
10.8.0.13 dev tun0  proto kernel  scope link  src 10.8.0.14
10.79.255.126 dev ppp1  proto kernel  scope link  src 109.195.7.103
192.168.0.0/24 dev enp1s13  proto kernel  scope link  src 192.168.0.1
192.168.10.0/24 via 10.8.0.13 dev tun0
Читал http://forum.altlinux.org/index.php?topic=25561.0 Но до решения не дошел. Не могу понять почему пакеты из центрального офиса идут через 10.8.0.14 . Пробовал на клиентах вручную задавать маршурт до 192.168.0.2 через 192.168.0.1 - безрезультатно.

[andy_k]

Сейчас еще дополнительно выполнил команду tracepath, вот вывод с сервера филиала:

Код: [Выделить]

[root@driver-router tun0]# tracepath 192.168.10.2
 1:  10.8.0.14                                             0.584ms pmtu 1500
 1:  10.8.0.1                                             28.405ms
 1:  10.8.0.1                                             28.526ms
 2:  192.168.10.2                                         29.644ms reached
     Resume: pmtu 1500 hops 2 back 127

Вот вывод с сервера центрального магазина:

Код: [Выделить]

[root@openvpn ~]# tracepath 192.168.0.2
 1:  10.8.0.1                                              0.268ms pmtu 1500
 1:  10.8.0.14                                            28.163ms
 1:  10.8.0.14                                            29.314ms
 2:  no reply
................
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500
Складывается ощущение, что север филиала не знает что делать со входящим пакетом, мне вообще кажется, что он свою сеть за NAT прячет. В iptables в цепочки Forward прописал -i tun0  -j ACCEPT Подскажите куда дальше копать.

[asy]

Подскажите куда дальше копать.

Внимательно проверять роутинг везгде. В смысле настройки. Если где-то случился NAT ненужный, он отключается не в FORWARD, а в POSTROUTING. И лучше не перехватывать правилом с ACCEPT, а NAT привязать сразу только к нужному интерфейсу.

[andy_k]

Внимательно проверять роутинг везгде. В смысле настройки. Если где-то случился NAT ненужный, он отключается не в FORWARD, а в POSTROUTING. И лучше не перехватывать правилом с ACCEPT, а NAT привязать сразу только к нужному интерфейсу.

Роутинг проверил везде, уже пробовал вручную перезаписать - безрезультатно.
вот правила iptables с сервера филиала:

Код: [Выделить]

[root@driver-router ~]# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -f -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j ULOG --ulog-prefix icount --ulog-cprange 48 --ulog-qthreshold 50
-A INPUT -i ppp1 -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -i ppp1 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i ppp1 -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i ppp1 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i ppp1 -p udp -m udp --dport 22 -j ACCEPT
-A INPUT -i ppp1 -p icmp -j ACCEPT
-A INPUT -i ppp1 -j DROP
-A FORWARD -f -j DROP
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ULOG --ulog-prefix fcount --ulog-cprange 48 --ulog-qthreshold 50
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -i ppp1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp1 -j DROP
-A OUTPUT -f -j DROP
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j ULOG --ulog-prefix ocount --ulog-cprange 48 --ulog-qthreshold 50

Я nat таблице одна запись

Код: [Выделить]

-o ppp1 -j MASQUERADE.

[asy]

Роутинг проверил везде, уже пробовал вручную перезаписать - безрезультатно.

Значит, не везде. Проверять надо маршрутизацию в сторону сервера центрального магазина с этого 192.168.10.2, видимо. Можно ещё tcpdump-ом смотреть в нужных точках, куда пакеты уходят на самом деле.

[speccyfan]

может натолкнет на мысли
https://sites.google.com/site/speccyfan/openvpn#TOC-.

[andy_k]

Ребята, спасибо. Разобрался в чем было дело. Проблема решена.

P.S. проблема была в локальном клиенте windows7, его фаервол блокировал все соединения не из своей сети.