Задать вопрос
hostadmin
@hostadmin
linux

Как настроить доступ из сети сервера к сети клиента в OpenVPN (iroute не работает)?

Имеется такая схема:
1cfc2569180a49689298e7866d6a936a.JPG

Клиент и сервер - это роутеры с OpenWRT и установленным OpenVPN.

Настройки сервера (сеть 192.168.1.0):
option dev 'tun'
	option server '10.0.100.0 255.255.255.0'
	option keepalive '10 60'
	option verb '3'
	option mssfix '1420'
	option ca '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.ca'
	option key '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.key'
	option dh '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.dh'
	option cert '/lib/uci/upload/cbid.openvpn.Example_routed_multiclient_server.cert'
	option enabled '1'
option client_config_dir '/etc/openvpn/ccd'
option log '/var/log/openvpn.log'
option proto 'tcp'

+ CCD-конфиг клиента:
iroute 192.168.0.0 255.255.255.0

Настройки клиента (192.168.0.0):
config openvpn 'client_tun'
        option nobind '1'
        option float '1'
        option client '1'
option tls-client '1'
option proto 'tcp'
option resolv-retry 'infinite'
        option reneg_sec '0'
        option dev 'tun'
        option verb '3'
        option persist_tun '1'
        option persist_key '1'
        option remote_cert_tls 'server'
        option remote 'server.ru'
        option ca '/lib/uci/upload/cbid.openvpn.client_tun.ca'
        option cert '/lib/uci/upload/cbid.openvpn.client_tun.cert'
        option key '/lib/uci/upload/cbid.openvpn.client_tun.key'
        option enabled '1'
option log '/var/log/openvpn.log'


Задача была такой, чтобы из сети сервера можно было иметь доступ к компьютерам в сети клиента. Но такого не происходит. Туннель устанавливается, клиент получает tun-адрес 10.0.100.6 и по этому адресу к нему можно обратиться с самого сервера или из сети сервера. Но вот по адресу 192.168.0.x никаких ответов нет.

Так же на сервере установлен mwan3, с балансировкой двух провайдеров.

Маршруты на сервере выглядят так:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         109-x-x-x.w 0.0.0.0         UG    9      0        0 eth0.2
default         95-x-x-x.dyna 0.0.0.0         UG    10     0        0 pppoe-wan2
10.0.100.0      10.0.100.2      255.255.255.0   UG    0      0        0 tun0
10.0.100.2      *               255.255.255.255 UH    0      0        0 tun0
95.x.x.x      *               255.255.255.255 UH    0      0        0 pppoe-wan2
109.x.x.0   *               255.255.255.192 U     9      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

Т.е. маршрута на 192.168.0.0 не видно.

В логах openvpn-сервера указано, что маршрут применяется:
Fri Dec 18 22:57:23 2015 TCPv4_SERVER link remote: 217.y.y.y:53515
Fri Dec 18 22:57:23 2015 217.y.y.y:53515 TLS: Initial packet from 217.y.y.y:53515, sid=3b512b2d ccb4f1b3
Fri Dec 18 22:57:26 2015 217.y.y.y:53515 VERIFY OK: depth=1, /C=RU/ST=Saint-Petersburg/L=Saint-Petersburg/O=SITE/OU=Flat/CN=SITE_CA/name=FlatK/emailAddress=dom@site.ru
Fri Dec 18 22:57:26 2015 217.y.y.y:53515 VERIFY OK: depth=0, /C=RU/ST=Saint-Petersburg/L=Saint-Petersburg/O=SITE/OU=Flat/CN=client1/name=Client/emailAddress=client@site.ru
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Dec 18 22:57:27 2015 217.y.y.y:53515 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec 18 22:57:28 2015 217.y.y.y:53515 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Dec 18 22:57:28 2015 217.y.y.y:53515 [client1] Peer Connection Initiated with 217.y.y.y:53515
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/client1
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 MULTI: Learn: 10.0.100.6 -> client1/217.y.y.y:53515
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 MULTI: primary virtual IP for client1/217.y.y.y:53515: 10.0.100.6
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 <b>MULTI: internal route 192.168.0.0/24 -> client1/217.y.y.y:53515</b>
Fri Dec 18 22:57:28 2015 client1/217.y.y.y:53515 <b>MULTI: Learn: 192.168.0.0/24 -> client1/217.y.y.y:53515</b>
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 PUSH: Received control message: 'PUSH_REQUEST'
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.0.100.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.100.6 10.0.100.5' (status=1)
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 PUSH: Received control message: 'PUSH_REQUEST'
Fri Dec 18 22:57:30 2015 client1/217.y.y.y:53515 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.0.100.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.100.6 10.0.100.5' (status=1)


Попытался добавить маршрут такой командой:
route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.0.100.2 tun0

роутинги стали такими:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         109-x-x-x.w 0.0.0.0         UG    9      0        0 eth0.2
default         95-x-x-x.dyna 0.0.0.0         UG    10     0        0 pppoe-wan2
10.0.100.0      10.0.100.2      255.255.255.0   UG    0      0        0 tun0
10.0.100.2      *               255.255.255.255 UH    0      0        0 tun0
95.x.x.x      *               255.255.255.255 UH    0      0        0 pppoe-wan2
109.x.x.x   *               255.255.255.192 U     9      0        0 eth0.2
192.168.0.0     10.0.100.2      255.255.255.0   UG    0      0        0 tun0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

Но доступа всё равно не стало.

Удалил маршрут и попробовал другую команду
ip ro add 192.168.0.0/24 dev tun0

получил:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         109.x.x.x   0.0.0.0         UG        0 0          0 eth0.2
0.0.0.0         95.x.x.x      0.0.0.0         UG        0 0          0 pppoe-wan2
10.0.100.0      10.0.100.2      255.255.255.0   UG        0 0          0 tun0
10.0.100.2      0.0.0.0         255.255.255.255 UH        0 0          0 tun0
95.x.x.x      0.0.0.0         255.255.255.255 UH        0 0          0 pppoe-wan2
109.x.x.x   0.0.0.0         255.255.255.192 U         0 0          0 eth0.2
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

Доступа всё равно не стало.

При том, даже с прописанными маршрутами, если пытаться делать traceroute на ip 192.168.0.x, то видно, что пакеты уходят в сеть првайдера 109.x.x.x.

# traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 38 byte packets
 1  172.x.x.1 (172.x.x.1)  1.190 ms  0.032 ms  0.466 ms
^C

# traceroute ya.ru
traceroute to ya.ru (213.180.204.3), 30 hops max, 38 byte packets
 1  172.x.x.1 (172.x.x.1)  1.098 ms  0.038 ms  0.355 ms
 2  172.x.x.y (172.x.x.y)  1.157 ms  0.916 ms  0.891 ms
^C


Что не так может быть? В какую сторону копать?
PS. На всякий случай еще конфиг настроек сети:
config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option _orig_ifname 'eth0.1 wlan0'
	option _orig_bridge 'true'
	option ifname 'eth0.1 eth1'
	option ipaddr '192.168.1.1'
	option dns '192.168.1.1 8.8.8.8'

config switch
	option name 'rtl8366rb'
	option reset '1'
	option enable_vlan '1'
	option enable_vlan4k '1'

config switch_vlan
	option device 'rtl8366rb'
	option vlan '1'
	option ports '2 3 4 5t'

config switch_vlan
	option device 'rtl8366rb'
	option vlan '2'
	option ports '0 5t'

config interface 'wan1'
	option ifname 'eth0.2'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'dhcp'
	option hostname 'fuck'
	option metric '9'

config interface '3g'
	option proto '3g'

config interface 'guest'
	option proto 'static'
	option ipaddr '10.0.0.1'
	option netmask '255.255.255.0'

config switch_vlan
	option device 'rtl8366rb'
	option vlan '3'
	option ports '1 5t'

config interface 'wan2'
	option proto 'pppoe'
	option ifname 'eth0.3'
	option username 'ptn'
	option password 'ptn'
	option metric '10'

config interface 'lan_2_1'
	option proto 'static'
	option ifname 'eth1'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'

config interface 'vpn'
	option proto 'none'
	option ifname 'tun0'
	option metric '99'
  • Вопрос задан
  • 18222 просмотра
Комментировать
Подписаться 1 Оценить Комментировать
Решения вопроса 1
@ldvldv
Чтобы пакеты для сети 192.168.0 шли через VPN надо добавить
route 192.168.0.0 255.255.255.0
в конфиг сервера

https://openvpn.net/index.php/open-source/document...
--iroute network [netmask]
Generate an internal route to a specific client. The netmask parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from. Remember that you must also add the route to the system routing table as well (such as by using the --route directive). The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.

This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script.

The --iroute directive also has an important interaction with --push "route ...". --iroute essentially defines a subnet which is owned by a particular client (we will call this client A). If you would like other clients to be able to reach A's subnet, you can use --push "route ..." together with --client-to-client to effect this. In order for all clients to see A's subnet, OpenVPN must push this route to all clients EXCEPT for A, since the subnet is already owned by A. OpenVPN accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes.


это даст доступ с сервера в сеть клиента. Чтобы пакеты ходили между сетями клиента и сервера, добавить в конфиг сервера
push "route 192.168.1.0 255.255.255.0"
или
в конфиг клиента
route 192.168.1.0 255.255.255.0
Ответ написан
14 комментариев
14 комментариев
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы
Вакансии с Хабр Карьеры
Системный администратор Astra Linux
Гринатом • Новосибирск
До 60 000 ₽
Системный администратор Linux
ГК Finbridge • Ростов-на-Дону
от 180 000 до 220 000 ₽
Системный инженер (Windows/Astra Linux)
Гринатом • Новосибирск
До 57 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Модернизация софта (Python)
23 дек. 2024, в 17:16
35000 руб./за проект
Node.js (TensorFlow) приложение для извлечения именованных сущностей
23 дек. 2024, в 17:12
30000 руб./за проект
Бот ТГ на python с сервисом по поиску упоминаний в Инст
23 дек. 2024, в 17:08
10000 руб./за проект
Ещё заказы