LINUX.ORG.RU
решено Форум — Admin  

Заставить роутер пропускать пакеты в сеть OpenVPN

 , ,


0

1

Имеем конфигурацию:

1. VDS-виртуалка в Интернете, на которой запущен сервер OpenVPN. Для vpn-сети задано адресное пространство 192.168.2.0/24. В этой vpn-cети данная виртуалка имеет IP 192.168.2.1.

2. Домашний роутер с прошивкой DD-WRT, на котором запущен openvpn-клиент. После соединения с сервером, роутер получает в vpn-сети IP 192.168.2.50. Его IP в локальной домашней сети 192.168.1.1.

3. Домашняя рабочая станция. Ее IP, к примеру 192.168.1.5. Маршрут по-умолчанию на ней установлен, естественно, на гейтвей 192.168.1.1.

Vpn-соединение между виртуалкой и роутером нормальное, работает в двух направлениях. Из консоли роутера пинги ходят до виртуалки. В консоле виртуалки пинги ходят до роутера.

Для начала задача простая: достучаться до виртуалки 192.168.2.1 с рабочей станции 192.168.1.5.

Для этого я на роутере сначала смотрю роутинг:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.192  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0


Я не силен в сетях, поэтому не могу точно сказать, достаточно ли строки 192.168.2.0 для того, чтобы пакеты на сеть 192.168.2.0 заворачивались этим правилом. Поэтому добавляю такое правило (просто командой, не через WEB интерфейс):

# route add -net 192.168.2.0 netmask 255.255.255.0 gw 192.168.2.1 metric 1


После чего имею уже два правила:

# route | grep 192.168.2.0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
192.168.2.0     192.168.2.1     255.255.255.0   UG    1      0        0 tun0


По идее, этого достаточно для того, чтобы роутер начал пробрасывать пакеты из сети 192.168.1.0/24 в 192.168.2.0/24, используя в качестве гейтвея хост с виртуалкой 192.168.2.1.

Однако ни ping 192.168.2.1, ни traceroute 192.168.2.1, выполненные в консоли домашней рабочей станции, не работают.

Я не пойму, почему так происходит. Может быть, пакеты пробрасываются до 192.168.2.1 из сети 192.168.1.0/24, но обратно не возвращаются, потому что нужно еще как-то маршрут возвращения прописать? Или пинги не проходят потому, что на роутере их рубит файрвол? Вот какую информацию могу дать по файрволу:

# cat /proc/sys/net/ipv4/ip_forward 
1
# iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8080 
2    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
3    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
4    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:69 
5    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
2    lan2wan    0    --  0.0.0.0/0            0.0.0.0/0           
3    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           
4    ACCEPT     udp  --  0.0.0.0/0            224.0.0.0/4         
5    TRIGGER    0    --  0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0 
6    trigger_out  0    --  0.0.0.0/0            0.0.0.0/0           
7    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state NEW 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain advgrp_1 (0 references)
num  target     prot opt source               destination         

Chain advgrp_10 (0 references)
num  target     prot opt source               destination         

Chain advgrp_2 (0 references)
num  target     prot opt source               destination         

Chain advgrp_3 (0 references)
num  target     prot opt source               destination         

Chain advgrp_4 (0 references)
num  target     prot opt source               destination         

Chain advgrp_5 (0 references)
num  target     prot opt source               destination         

Chain advgrp_6 (0 references)
num  target     prot opt source               destination         

Chain advgrp_7 (0 references)
num  target     prot opt source               destination         

Chain advgrp_8 (0 references)
num  target     prot opt source               destination         

Chain advgrp_9 (0 references)
num  target     prot opt source               destination         

Chain grp_1 (1 references)
num  target     prot opt source               destination

Chain grp_10 (0 references)
num  target     prot opt source               destination

Chain grp_2 (0 references)
num  target     prot opt source               destination

Chain grp_3 (0 references)
num  target     prot opt source               destination

Chain grp_4 (0 references)
num  target     prot opt source               destination

Chain grp_5 (0 references)
num  target     prot opt source               destination

Chain grp_6 (0 references)
num  target     prot opt source               destination

Chain grp_7 (0 references)
num  target     prot opt source               destination

Chain grp_8 (0 references)
num  target     prot opt source               destination

Chain grp_9 (0 references)
num  target     prot opt source               destination

Chain lan2wan (1 references)
num  target     prot opt source               destination
1    grp_1      0    --  0.0.0.0/0            0.0.0.0/0

Chain logaccept (0 references)
num  target     prot opt source               destination
1    ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0

Chain logdrop (0 references)
num  target     prot opt source               destination
1    DROP       0    --  0.0.0.0/0            0.0.0.0/0

Chain logreject (0 references)
num  target     prot opt source               destination
1    REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset

Chain trigger_out (1 references)
num  target     prot opt source               destination

Я добавил правило:

# iptables -A FORWARD -d 192.168.2.0/24 -j ACCEPT
# iptables -L -n --line-numbers | grep 192.168.2.0
8    ACCEPT     0    --  0.0.0.0/0            192.168.2.0/24

Но пинги/трейсроут с рабочей станции до виртуалки все равно не проходят.

Вопрос: что где надо еще настроить, чтобы начали ходить пинги от рабочей станции до виртуалки?

PS: Далее будет следующий вопрос: как заставить ходить пинги из виртуалки до рабочей станции. Ради этого, в принципе, все и затевалось.

★★★★★

Последнее исправление: Xintrea (всего исправлений: 2)
← пометить бедблоки в рейде
Solaris 11.3 ZFS шифрование, не запрашивает пароль или file.key при монтировании →

А должно быть: 

192.168.2.0     192.168.2.1               255.255.255.0     UG    0      0        0 tun0
192.168.2.1     *                         255.255.255.255   UH    1      0        0 tun0
А вот этого быть не должно: 
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
Тут бы хорошо файл конфигурации посмотреть на предмет обнаружения/отсутствия 
route 192.168.2.0 255.255.255.0
А так... Могу общими фразами ограничиться. Остерегайтесь делать на тунелях сети 192.168 Публичные сети (в магазинах, кабаках и прочих питейных заведениях) тоже любят эти сети. В результате может так получится (и получается), что вы не сможете пользоваться собственным VPN-сервером даже из соседней рюмочной. Ну, не очень-то заморачиваются в публичных местах с выбором подсетей для общедоступных точек. Часто встречаются эти 192.168

gazanit
()
Ответ на: комментарий от gazanit

А вот этого быть не должно:
192.168.2.0 * 255.255.255.0 U 0 0 0 tun0

Это правило появляется на Роутере автоматически, после поднятия клиентского openvpn-соединения. Честно говоря, не знаю как на его появление можно повлиять.

Тут бы хорошо файл конфигурации посмотреть на предмет обнаружения/отсутствия
route 192.168.2.0 255.255.255.0

Файл конфигурации чего конкретно? В конфигурации openvpn-клиента ничего подобного не прописано.

Ну, не очень-то заморачиваются в публичных местах с выбором подсетей для общедоступных точек. Часто встречаются эти 192.168

Мне openvpn нужен для других целей. В голову даже не приходило стучаться из общедоступных точек.

Xintrea ★★★★★
() автор топика
Последнее исправление: Xintrea (всего исправлений: 1)

Я сам в сетях не особо, но когда что-то не работает я отключаю все что может повлиять на работу, а когда хоть как-то заработало начинаю «закручивать гайки».

Отключи нетфильтр 

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Затем сделай сервер впн шлюзом по умолчанию и добавь правило для доступа к своему впн серверу напрямую(нужно что бы роутер смог подключиться к openvpn).

route add default gw 192.168.2.1
route add ip.vpn.server gw 192.214.221.83

Потом сделай это 

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

и само собой должно быть это 

net.ipv4.ip_forward=1
Удачи)

lucky_guy ★★★
()
Ответ на: комментарий от gazanit

Кстати, я для теста привел вручную таблицу маршрутизации к такому виду:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.192  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     192.168.2.1     255.255.255.0   UG    1      0        0 tun0
192.168.2.1     *               255.255.255.255 UH    2      0        0 tun0


Но пакеты все равно не проходят.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Anoxemian

Я ж в стартовой мессаге показал:

# cat /proc/sys/net/ipv4/ip_forward 
1


Вы это хотели увидеть?

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от gazanit

И еще уточнение. С Рабочей станции 192.168.1.5 нормально проходят пинги на Роутер 192.168.2.50:

ping 192.168.2.50
PING 192.168.2.50 (192.168.2.50) 56(84) bytes of data.
64 bytes from 192.168.2.50: icmp_seq=1 ttl=64 time=0.279 ms
64 bytes from 192.168.2.50: icmp_seq=2 ttl=64 time=0.196 ms
64 bytes from 192.168.2.50: icmp_seq=3 ttl=64 time=0.189 ms

То есть, в сеть 192.168.2.0/24 без проблем можно попасть из сети 192.168.1.0/24. Не работает только роутинг дальше, к хосту 192.168.2.1.

Xintrea ★★★★★
() автор топика
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от lucky_guy

Отключил нетфильтер вашими командами. Остальное не трогал. Картина все та же:

- С Рабочей станции пингуется Роутер как 192.168.2.50 (он же 192.168.1.1)
- С Рабочей станции не пингуется Виртуалка 192.168.2.1

Отсюда делаю вывод, что проблема, как минимум, не в фаирволе.

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

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Скорее всего эти пинги не проходят через сервер а идут напрямую к роутеру, посмотрите на время. И сравните с 

ping 192.168.1.1
и с 
ping ip.VDS

lucky_guy ★★★
()
Ответ на: комментарий от lucky_guy

Конечно, к Роутеру пинги что на 192.168.2.50, что на 192.168.1.1 идут одинаково, это же одна и та же машина.

Xintrea ★★★★★
() автор топика
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

net.ipv4.ip_forward - на маршрутизаторе, который выпускает человека в сети? )) Да, можно поискать, конечно. Если автор испытывает проблемы выхода в сеть.

gazanit
()
Ответ на: комментарий от Xintrea

В конфигурации openvpn-клиента ничего подобного не прописано.

А как по мне, так очень даже прописано. Строчкой номер три в клиентской конфигурации. )) Если по вашей ссылке. И строчками номер 35,37 в серверной конфигурации. Другое дело, что у вас указано местечко конфигурации пользователей на сервере... и немного непонятно: там есть чего-нибудь или нет? )) Потому что странно так указано. Производитель OpenVPN всё же рекомендует указывать полный путь. Знаю, что это у кого как получится, но на сертификаты вы полностью пути печатаете, а почему вдруг с клиентами без путей? - немного непонятно. В общем так. Сеть вы от сервера клиенту отдаёте. С конфигурацией клиента на сервере - невнятно. Дефолтный gateway от сервера не отдаётся, потому что этого в конфиге сервера этого нет. Тут вам надо определиться: вы либо фул-пул хотите, либо статику через конфигурацию клиента на сервере. Что из двух?

gazanit
()
Ответ на: комментарий от Xintrea

Вот только дальнейших действий, которые вы предлагаете, я не понимаю.

Если отбросить все тонкости то суть такова:
У вас сейчас стоит шлюз 

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.214.221.83 0.0.0.0         UG    0      0        0 ppp0
весь ваш траффик идет через него. Теперь мы делаем шлюзом по умолчанию сервер openvpn командой 
route add default gw 192.168.2.1
Теперь после ввода команды route будут такие первые строчки: 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 tun0
default         192.214.221.83  0.0.0.0         UG    0      0        0 ppp0
Тут принцип «кто первый - через того и иду». Теперь все ваши соединения будут проходить через openvpn сервер.
Но пока клиент не подключился к серверу, интерфейс tun0 не появится и все соединения(включая авторизацию на openvpn сервере) будут ломиться в несуществующую сеть. А что бы этого не произошло, для клиента нужно открыть прямой доступ к ip адресу вашей VDS. Клиент авторизуется -> появляется интерфейс tun0 -> соединения соединяются, закачки закачиваются. 
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
Про маскардинг в двух словах не объясню. Грубо говоря это мостик из одной сети в другую.

lucky_guy ★★★
()
Последнее исправление: lucky_guy (всего исправлений: 1)
Ответ на: комментарий от gazanit

Давайте по порядку.

1.

На клиенте мы имеем в строчке 3 опцию:

pool


На сервере мы имеем в строчках 34-37 опции:
topology subnet
push "topology subnet"
ifconfig 192.168.2.1 255.255.255.0
ifconfig-pool 192.168.2.50 192.168.2.250 255.255.255.0


Что здесь не нравится?


2.

Другое дело, что у вас указано местечко конфигурации пользователей на сервере... и немного непонятно: там есть чего-нибудь или нет? )) Потому что странно так указано. Производитель OpenVPN всё же рекомендует указывать полный путь. Знаю, что это у кого как получится, но на сертификаты вы полностью пути печатаете, а почему вдруг с клиентами без путей? - немного непонятно.

Потому что конфигурация клиента настраивается через скрипт. Соединение, настраиваемое через WEB-интерфейс, не работает, поэтому приходится извращаться.

Этот скрипт и файлы сертификатов из себя разворачивает, и файл конфигурации кладет рядом с ними, и переходит в эту директорию, и запускает openvpn клиента с явным указанием файла конфигурации с полным путем.


3.

Дефолтный gateway от сервера не отдаётся, потому что этого в конфиге сервера этого нет. Тут вам надо определиться: вы либо фул-пул хотите, либо статику через конфигурацию клиента на сервере. Что из двух?

Скорее, надо gateway на клиенте прописывать путем push команды. И этот gateway не должен стать дефолтным на клиенте, чтобы нормально интернет провайдера работал.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Отсюда делаю вывод, что проблема, как минимум, не в фаирволе.

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

«Роутинг» )) появится сразу, как только вы прочтёте это: https://community.openvpn.net/openvpn/wiki/Concepts-Addressing

Ещё раз попробую объяснить. Вы в конфигурации сервера делаете статику: 

ifconfig 192.168.2.1 255.255.255.0
ifconfig-pool 192.168.2.50 192.168.2.250 255.255.255.0
Потом про неё как бы «забываете» 
# client-config-dir ccd
Лучше не забывать. И что-нибудь указать. Там есть чего-нибудь?

Дальше больше. Если всё же была идея сделать так называемый фул-пул, то надо бы раскоментировать: 

# server 192.168.2.0 255.255.255.0

Замес у вас в конфигурациях получился забавный.

gazanit
()
Ответ на: комментарий от lucky_guy

Тут принцип «кто первый - через того и иду». Теперь все ваши соединения будут проходить через openvpn сервер.

Ну и зачем это нужно? Поймите, я openvpn поднимаю не для анонимности, не для того чтобы через него в интернет ходить. Да и тариф на серваке у меня слабый, не предполагающий сёрфинг.

Я это делаю только для организации своей личной vpn сети, просто потому что провайдер не выдает белых IP. Поэтому и приходится так извращаться.

Вот и нужна такая маршрутизация, чтобы пакеты VPN-сети 192.168.2.0/24 заворачивались на opnvpn виртуалку. А все остальное должно ходить как обычно.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Скорее, надо gateway на клиенте прописывать путем push команды. И этот gateway не должен стать дефолтным на клиенте, чтобы нормально интернет провайдера работал.

Ну, вы же не рассказываете про свои «другие цели». Откуда мне знать, что именно вы хотите получить? Если в сеть вы хотите «ходить» как обычно, не через VPN, то делайте статику и не отдавайте дефолтный шлюз с сервера, пусть будет от провайдера. ))

gazanit
()
Ответ на: комментарий от gazanit

# client-config-dir ccd
Лучше не забывать. И что-нибудь указать. Там есть чего-нибудь?

У меня на openvpn-сервере только одна конфигурация. Мне бы с ней разобраться, и только потом я буду по разным клиентам конфиги распихивать. Поэтому директории /etc/opnvpn/ccd нет вообще.


Дальше больше. Если всё же была идея сделать так называемый фул-пул, то надо бы раскоментировать:
# server 192.168.2.0 255.255.255.0

Что такое фул-пул?

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Что такое фул-пул?

Одна из разновидностей топологии сети. Раздел концепции адресации. Я чуть выше ссылку дал.

gazanit
()
Ответ на: комментарий от gazanit

то надо бы раскоментировать:
# server 192.168.2.0 255.255.255.0

Раскомментировал только эту строчку. Сервер не может стартануть. Ошибка:

Nov  7 02:57:22 webhamster ovpn-server[6234]: Options error: --server already defines an ifconfig-pool, so you can't also specify --ifconfig-pool explicitly
Nov  7 02:57:22 webhamster ovpn-server[6234]: Use --help for more information.
Nov  7 02:57:22 webhamster systemd[1]: openvpn@server.service: control process exited, code=exited status=1
Nov  7 02:57:22 webhamster systemd[1]: Failed to start OpenVPN connection to server.
Nov  7 02:57:22 webhamster systemd[1]: Unit openvpn@server.service entered failed state.

А потому что надо было тогда закомментировать 

ifconfig-pool 192.168.2.50 192.168.2.250 255.255.255.0

Но толку от этого никакого, потому что на клиенте формируется такая же таблица маршрутизации:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         194.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.194  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0
Xintrea ★★★★★
() автор топика
Последнее исправление: Xintrea (всего исправлений: 1)
Ответ на: комментарий от Xintrea

Ну и зачем это нужно?

Что бы выяснить в чем проблема. Если заработает то потом сделать

Вот и нужна такая маршрутизация, чтобы пакеты VPN-сети 192.168.2.0/24 заворачивались на opnvpn виртуалку. А все остальное должно ходить как обычно.

можно двумя командами. Но дело ваше.

lucky_guy ★★★
()
Ответ на: комментарий от lucky_guy

Что бы выяснить в чем проблема. Если заработает то потом сделать

Вот смотрите. Я отключаю вашими командами фаирвол. Потом должен дать две команды:

route add default gw 192.168.2.1
route add ip.vpn.server gw 192.214.221.83

По первой команде вопросов нет. По второй неясно, что надо указывать в качестве ip.vpn.server. Интернетовский IP виртуалки, на котором крутится openvpn сервер? Или адрес в vpn-сети, равный 192.168.2.1?

Если надо указывать интернетовский IP, то его добавление не срабатывает. Я пробовал команды:
route add 193.xxx.xxx.214 gw 194.214.221.83
route add -host 193.xxx.xxx.214 gw 194.214.221.83

Они молча выполняются, но после них таблица маршрутизации остается прежней, в ней не появляются строки с IP 193.xxx.xxx.214:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 tun0
default         194.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.194  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от lucky_guy

Вот и нужна такая маршрутизация, чтобы пакеты VPN-сети 192.168.2.0/24 заворачивались на opnvpn виртуалку. А все остальное должно ходить как обычно.

можно двумя командами. Но дело ваше.

О каких командах идет речь?

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Интернетовский IP виртуалки, на котором крутится openvpn сервер?

Да.

добавление не срабатывает.

Это странно, попробуйте 

ip route add 193.xxx.xxx.214 via 194.214.221.83
А еще эти строчи странные, почему адреса зеркальные? 
default         194.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.194  *               255.255.255.255 UH    0      0        0 ppp0

О каких командах идет речь?

Товарищ в первом посте написал как должно быть, когда удастся пробиться пингами от рабочей машины к серверу сделайте так как в первом посте. А еще добавьте строчку в конфиг сервера 

push "redirect-gateway def1 bypass-dhcp"
вместо 
ifconfig 192.168.2.1 255.255.255.0
ifconfig-pool 192.168.2.50 192.168.2.250 255.255.255.0

lucky_guy ★★★
()
Ответ на: комментарий от lucky_guy

Это странно, попробуйте
ip route add 193.xxx.xxx.214 via 194.214.221.83

Так тоже не работает:

# route add default gw 192.168.2.1

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 tun0
default         194.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.194  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0

# ip route add 193.124.188.214 via 194.214.221.83
RTNETLINK answers: Network unreachable

А еще эти строчи странные, почему адреса зеркальные?

Понятия не имею. Эти строчки просто генерируются роутером когда происходит соединение с провайдером. Все настройки провайдеровские: PPPoE, логин и пароль. Ничего больше не настраивается.

Товарищ в первом посте написал как должно быть, когда удастся пробиться пингами от рабочей машины к серверу сделайте так как в первом посте.

Он написал следующее:

А должно быть:
192.168.2.0     192.168.2.1               255.255.255.0     UG    0      0        0 tun0
192.168.2.1     *                         255.255.255.255   UH    1      0        0 tun0
А вот этого быть не должно:
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0

А я написал вот это. Я считаю, что это полный эквивалент того, что предлагает gazanit. Я даже здесь свой вариант повторю:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.192  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     192.168.2.1     255.255.255.0   UG    1      0        0 tun0
192.168.2.1     *               255.255.255.255 UH    2      0        0 tun0

И в таком виде маршрутизация до 192.168.2.1 не работает.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

А должно быть: 

192.168.2.0     192.168.2.1               255.255.255.0     UG    0      0        0 tun0
192.168.2.1     *                         255.255.255.255   UH    1      0        0 tun0

это для офтопика правильно.

А вот этого быть не должно: 

192.168.2.0     *               255.255.255.0   U     0      0        0 tun0

А это правильное описание маршрута через интерфейс типа p2p.

Первая проблема - это использование «route» для вывода таблицы машрутизации. Возвращаться в прошлое тысячелетие очень тяжко.

Чтоб понять проблему нужно посмотреть на все таблицы маршрутизации участников этой сети.

ip ro с ddwrt, vds и виртуалки.

Ну и на vds запуск «tcpdump -ni tun0» возможно подскажет в какую сторону не идет трафик.

vel ★★★★★
()
Ответ на: комментарий от lucky_guy

ip route add 193.124.188.214 via 194.214.221.83 dev ppp0

Не работает:

# route add default gw 192.168.2.1

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 tun0
default         193.214.221.83. 0.0.0.0         UG    0      0        0 ppp0
83.221.214.193  *               255.255.255.255 UH    0      0        0 ppp0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
169.254.0.0     *               255.255.0.0     U     0      0        0 br0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
192.168.2.0     *               255.255.255.0   U     0      0        0 tun0

# ip route add 193.124.188.214 via 194.214.221.83 dev ppp0
RTNETLINK answers: Network unreachable



И пробовали ли команду

Ну так предыдущая же не срабатывает. Но я все равно попробовал. Толку никакого, пинги из сети 192.168.1.0/24 на 192.168.2.50 идут, а на 192.168.2.1 - нет.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea 
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.1     0.0.0.0         UG    0      0        0 tun0
default         193.214.221.83. 0.0.0.0         UG    0      0        0 ppp0

Флаг вам в руки с такой таблицей машрутизации.

vel ★★★★★
()
Ответ на: комментарий от lucky_guy

На сервере туда нужно завернуть только ту подсеть, которая там должна быть доступна, а не все.

vel ★★★★★
()
Ответ на: комментарий от lucky_guy

iptables не связан в данном случае с машрутизацией.

От ТС сейчас хорошо бы увидеть результаты 3-х команд после подъема vpn

на ddwrt - «ip ro»

на vds - «ip ro» и «ip ro get 192.168.1.5»

vel ★★★★★
()
Ответ на: комментарий от vel

Я тут ковырялся, и таки заставил поднимать 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 ★★★★★
() автор топика
Последнее исправление: Xintrea (всего исправлений: 2)
Ответ на: комментарий от vel

От автора темы, для начала, хотелось бы увидеть чётко изложенную идею: а что, собственно, он хочет получить? Минуточку! Я всё прочитал, что выше. Автор получил двустороннее соединение клиента и сервера, где клиент - это домашний маршрутизатор. По всей видимости, автор не потерял подключения к глобальной сети на стоящем за его домашним маршрутизатором компьютером/ноутбуком. Последний момент, конечно, ещё надо бы уточнить, но раз уж не было упомянуто, то предполагаю, что всё путём. Просмотрев конфигурации серверной и клиентской части, станет понятно, что - да! - оба устройства должны быть в одной подсети, и они действительно в одной подсети, автор проверил попингатором - ответы есть. Автор увидел, что и как передаёт сервер и справедливо возмутился, мол, «что там не так?!» Всё там «так» - сервер отдал клиенту сведения по подсети, клиент принял и влепил в таблицу упоминание. Но в конфигурации сервера так и осталось непонятным: что автор хочет получить, так как там вообще-то не «p2p», а объявленная подсеть (topology «subnet»). При этом автор категорически отказывается от настройки клиента на сервере:

У меня на openvpn-сервере только одна конфигурация. Мне бы с ней разобраться, и только потом я буду по разным клиентам конфиги распихивать.

Наверное, действительно, хочется «самонастройки» (full pool) клиентской части. Но при этом не хочет отказаться от статики (static ccd). Любопытно, чем это закончится. )) Как по мне, то, в принципе, задача уже решена - клиент и сервер соединены, находятся в одной подсети, а если дальнейшая настройка клиента отложена на «потом», то и пусть себе будет «потом». К автору: сделайте на сервере статику (static ccd), передавайте на клиента пушами и дефолтный гейт, и dns-ки, и всякое прочее. Без статики у вас клиент будет со всяким разным адресом из вашего пула адресов. Или сделайте full-pull где, разумеется, уберите «обрезанный пул адресов. Как вы заметили (опробовали), и то, и другое вместе работать не хотят. )) Отказаться от приёма дефолтного шлюза от сервера (редиректа шлюза) вы всегда сможете в клиентской конфигурации. В общем, всё как и прежде - вам надо определиться с этими, так называемыми „топологиями“, и сделать что-нибудь одно. А вот ту таблицу из двух строчек - это из соединения через vpn в глобальную сеть. Как позднее оказалось, вы этого не хотите. ))

gazanit
()
Ответ на: комментарий от Xintrea

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 192.168.1.0 255.255.255.0 192.168.2.50
# 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.

Какие 2 гейтвея? Где?

Удалите нафиг этот упоротый route! Или хотя бы запускайте его с "-n"

С таблицами маршрутизации все нормально. Все маршруты есть.

«ip ro get 192.168.1.5» нам пофиг есть живой адрес или нет. Интересует куда ядро отправит пакет если адрес назначения находится в удаленной сети.

Если на vds запустить «ping 192.168.1.X» где Х > 1 и «tcpdump -ni tun0» будет показывать пакеты с 192.168.2.1 на 192.168.1.X, то на vds все хорошо и проблему нужно искать в ddwrt.

На ddwrt нужно отключить NAT на tun1. Нужно убедиться, что на ddwrt нет фильтраци на tun1. Я никогда не сталкивался с ddwrt, так что как это сделать не знаю.

IMHO годный рецепт

Если на ddwrt есть tcpdump, то это упростит диагностику.

Про openvpn сервер. IMHO лучше сделать для ddwrt ccd, где через «ifconfig-push 192.168.2.50 255.255.255.0» выдавать ему всегда один и тот же адрес.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от Xintrea

Всю ветку не осилил, но по поиску вроде никто так про iroute еще не сказал. На сервере:
1. В конфиг сервера 

route 192.168.1.0 255.255.255.0 
client-config-dir путь-до-каталога-ccd (например /etc/openvpn/ccd)

2. В каталоге ccd создать файл с именем клиента и в него прописать 
iroute 192.168.1.0 255.255.255.0

anc ★★★★★
()
Ответ на: комментарий от anc

Да, я щас до этого и дошел.

Мне товарищ объяснил, что на маршрутизацию пакетовы внутри vpn-сети не влияют правила ядерной сетевой подсистемы линуха. А я об этом вообще не знал, и крутил обычный роутинг и фаирвол.

По сути, для того чтобы пинг проходил с openvpn-сервера в домашнюю локалку, надо чтобы произошли следующие события:

1. Пакет из обычной сетевой системы линукса самого хоста, на котором крутится openvpn, направленный на IP 192.168.1.5, должен вначале попасть в VPN сеть. Сделать он это может через интерфейс tun0. Что бы он попал туда, должно быть правило рутинга: 

# Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
# 192.168.1.0     192.168.2.1     255.255.255.0   UG    0      0        0 tun0
Тут важен не сам Gateway, а именно tun0, чтобы пакет попал в туннель.

Это автоматизируется на сервере с помощью опции:
# Добавляется маршрут вида:
# route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1
# Он же в выводе команды route:
# Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
# 192.168.1.0     192.168.2.1     255.255.255.0   UG    0      0        0 tun0
# Чтобы пакеты, направляемые в сеть 192.168.1.0/24 с этого openvpn-сервера,
# попадали в vpn-сеть в адрес 192.168.2.1 и соответственно в tun0.
# Далее сам openvpn сервер смаршрутизирует такой пакет благодаря ccd и опции iroute в файле личного конфига клиента
route 192.168.1.0 255.255.255.0 192.168.2.1


2. Так как OpenVPN не пользуется таблицей маршрутизации ядра, то сервер openvpn не знает, куда надо маршрутизировать этот пакет. И это недопонимание решается ccd-файлом для хоста gw0, в котором прописывается опция:
iroute 192.168.1.0 255.255.255.0

По сути, она говорит, что на конце vpn-туннеля, принадлежащего хосту gw0, находится сетка 192.168.1.0/24. И поэтому openvpn-сервер начинает знать, какому клиенту направить пакет.

3. Пакет вываливается из интерфейса tun1, который есть на роутере, и попадает в сетку 192.168.1.0/24.

Вот примерно так. Главное, что никто в обсуждении не сказал об этой тонкости так, чтобы было понятно.

Xintrea ★★★★★
() автор топика
Ответ на: комментарий от Xintrea

Обращаю внимание на пункт 1. 

route 192.168.1.0 255.255.255.0 192.168.2.1
gw (192.168.2.1) здесь прописывать не обязательно.

anc ★★★★★
()
Ответ на: комментарий от Xintrea

Я думаю, что вы не будете возражать, если на этой радостной ноте по случаю вашего окончательного выбора в пользу статической адресации, укажу благодарному читателю этого опуса на wiki: https://community.openvpn.net/openvpn/wiki/RoutedLans

gazanit
()
Ответ на: комментарий от gazanit

Вы бы еще перевели этот текст и на русскоязычную вики выложили, тогда цены бы этой ссылке не было. Ведь здесь у нас сайт русскоязычного сообщества. Кто знает английский как родной чтобы осилить Lans behind OpenVPN, тот на это обсуждение и не попадет.

Xintrea ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← пометить бедблоки в рейде
Admin
Solaris 11.3 ZFS шифрование, не запрашивает пароль или file.key при монтировании →