LINUX.ORG.RU

История изменений

Исправление Xintrea, (текущая версия) :

Я тут ковырялся, и таки заставил поднимать openvpn клиента не скриптом, а штатно через Web-интерфейс роутера. Соединение устанавливается, только интерфейс теперь на роутере называется не tun0 а tun1 (и я на это повлиять никак не могу).

После этого появилась возможность поставить галку NAT в настройках openvpn клиента. После чего пинги стали ходить из сети 192.168.1.0/24 до самого openvpn сервера 192.168.2.1 (раньше ходили только до роутера 192.168.2.50).

Теперь нужна обратная возможность: чтобы пинги стали ходить с хоста в сети 192.168.2.0/24 до узлов в сети 192.168.1.0/24.

На первый взгляд, для этого нужно сделать две вещи:

1. Прописать на openvpn-сервере маршрут до роутера для пакетов, предназначенных в сеть 192.168.1.0/24. Я попробовал такую команду:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.50 metric 1

и таблица на openvpn виртуалке стала такой:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gw.special.maro 0.0.0.0         UG    0      0        0 eth0
192.168.1.0     192.168.2.50    255.255.255.0   UG    1      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
193.124.184.0   *               255.255.248.0   U     0      0        0 eth0

Тут меня смущает два гейтвея. Но вроде из-за того что метрика для 192.168.1.0/24 равна 1, эта маршрутизация должна происходит раньше маршрута default.

По идее, с этим правилом команда traceroute 192.168.1.1, выполненная на openvpn виртуалке, должна доходить хотя бы до 192.168.2.50, но этого не происходит. Почему - не знаю.

2. Когда пакеты, предназначенные сети 192.168.1.0/24 станут попадать на роутер 192.168.2.50, на самом роутере надо сделать «переход» пакетов из сети 192.168.2.0/24 в сеть 192.168.1.0/24. Как это сделать - не знаю.


Теперь по вашим вопросам.

на ddwrt - «ip ro»

# ip ro
default via 83.221.214.197 dev ppp0
83.221.214.197 dev ppp0  proto kernel  scope link  src 100.67.240.184
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun1  proto kernel  scope link  src 192.168.2.50


на vds - «ip ro»

# ip ro
default via 193.124.184.1 dev eth0
192.168.1.0/24 via 192.168.2.50 dev tun0  metric 1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
193.xxx.xxx.0/21 dev eth0  proto kernel  scope link  src 193.xxx.xxx.214


и «ip ro get 192.168.1.5»

У меня щас нет такого IP, рабочая станция имеет 192.168.1.2, вот что по ней (хотя разницы нет, это ж только схема маршрута):

# ip ro get 192.168.1.2
192.168.1.2 via 192.168.2.50 dev tun0  src 192.168.2.1
    cache

Исправление Xintrea, :

Я тут ковырялся, и таки заставил поднимать openvpn клиента не скриптом, а штатно через Web-интерфейс роутера. Соединение устанавливается, только интерфейс теперь на роутере называется не tun0 а tun1 (и я на это повлиять никак не могу).

После этого появилась возможность поставить галку NAT в настройках openvpn клиента. После чего пинги стали ходить из сети 192.168.1.0/24 до самого openvpn сервера 192.168.2.1 (раньше ходили только до роутера 192.168.2.50).

Теперь нужна обратная возможность: чтобы пинги стали ходить с хоста в сети 192.168.2.0/24 до узлов в сети 192.168.1.0/24.

На первый взгляд, для этого нужно сделать две вещи:

1. Прописать на openvpn-сервере маршрут до роутера для пакетов, предназначенных в сеть 192.168.1.0/24. Я попробовал такую команду:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.50 metric 1

и таблица на openvpn виртуалке стала такой:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gw.special.maro 0.0.0.0         UG    0      0        0 eth0
192.168.1.0     192.168.2.50    255.255.255.0   UG    1      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
193.124.184.0   *               255.255.248.0   U     0      0        0 eth0

Тут меня смущает два гейтвея. Но вроде из-за того что метрика для 192.168.1.0/24 равна 1, эта маршрутизация должна происходит раньше маршрута default.

По идее, с этим правилом команда traceroute 192.168.1.1 должна доходить хотя бы до 192.168.2.50, но этого не происходит. Почему - не знаю.

2. Когда пакеты, предназначенные сети 192.168.1.0/24 станут попадать на роутер 192.168.2.50, на самом роутере надо сделать «переход» пакетов из сети 192.168.2.0/24 в сеть 192.168.1.0/24. Как это сделать - не знаю.


Теперь по вашим вопросам.

на ddwrt - «ip ro»

# ip ro
default via 83.221.214.197 dev ppp0
83.221.214.197 dev ppp0  proto kernel  scope link  src 100.67.240.184
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun1  proto kernel  scope link  src 192.168.2.50


на vds - «ip ro»

# ip ro
default via 193.124.184.1 dev eth0
192.168.1.0/24 via 192.168.2.50 dev tun0  metric 1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
193.xxx.xxx.0/21 dev eth0  proto kernel  scope link  src 193.xxx.xxx.214


и «ip ro get 192.168.1.5»

У меня щас нет такого IP, рабочая станция имеет 192.168.1.2, вот что по ней (хотя разницы нет, это ж только схема маршрута):

# ip ro get 192.168.1.2
192.168.1.2 via 192.168.2.50 dev tun0  src 192.168.2.1
    cache

Исходная версия Xintrea, :

Я тут ковырялся, и таки заставил поднимать openvpn клиента не скриптом, а штатно через Web-интерфейс роутера. Соединение устанавливается, только интерфейс теперь на роутере называется не tun0 а tun1 (и я на это повлиять никак не могу).

После этого появилась возможность поставить галку NAT в настройках openvpn клиента. После чего пинги стали ходить из сети 192.168.1.0/24 до самого openvpn сервера 192.168.2.1 (раньше ходили только до роутера 192.168.2.50).

Теперь нужна обратная возможность: чтобы пинги стали ходить с хоста в сети 192.168.2.0/24 до узлов в сети 192.168.1.0/24.

На первый взгляд, для этого нужно сделать две вещи:

1. Прописать на openvpn-сервере маршрут до роутера для пакетов, предназначенных в сеть 192.168.1.0/24. Я попробовал такую команду:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.50 metric 1

и таблица на openvpn виртуалке стала такой:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gw.special.maro 0.0.0.0         UG    0      0        0 eth0
192.168.1.0     192.168.2.50    255.255.255.0   UG    1      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
193.124.184.0   *               255.255.248.0   U     0      0        0 eth0

Тут меня смущает два гейтвея. Но вроде из-за того что метрика для 192.168.1.0/24 равна 1, эта маршрутизация (проверка пакета и проброс его в сеть 192.168.1.0/24) должна происходит раньше маршрута default.

По идее, с этим правилом команда traceroute 192.168.1.1 должна доходить хотя бы до 192.168.2.50, но этого не происходит. Почему - не знаю.

2. Когда пакеты, предназначенные сети 192.168.1.0/24 станут попадать на роутер 192.168.2.50, на самом роутере надо сделать «переход» пакетов из сети 192.168.2.0/24 в сеть 192.168.1.0/24. Как это сделать - не знаю.


Теперь по вашим вопросам.

на ddwrt - «ip ro»

# ip ro
default via 83.221.214.197 dev ppp0
83.221.214.197 dev ppp0  proto kernel  scope link  src 100.67.240.184
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.2.0/24 dev tun1  proto kernel  scope link  src 192.168.2.50


на vds - «ip ro»

# ip ro
default via 193.124.184.1 dev eth0
192.168.1.0/24 via 192.168.2.50 dev tun0  metric 1
192.168.2.0/24 dev tun0  proto kernel  scope link  src 192.168.2.1
193.xxx.xxx.0/21 dev eth0  proto kernel  scope link  src 193.xxx.xxx.214


и «ip ro get 192.168.1.5»

У меня щас нет такого IP, рабочая станция имеет 192.168.1.2, вот что по ней (хотя разницы нет, это ж только схема маршрута):

# ip ro get 192.168.1.2
192.168.1.2 via 192.168.2.50 dev tun0  src 192.168.2.1
    cache