URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 85953
[ Назад ]
Исходное сообщение
"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 13:44 
Не могу победить маршрутизацию. :( Дано: сервер - linux, 2.0.7; клиент - WinXP, OpenVPN 2.0.7 Win32-MinGW. Когда все поднималось - нужен был только доступ клиента к стандартным служебным сервисам типа почты и пр. Потом за первым клиентом появился второй, третий - на XP использовались возможности "Общего доступа", все работало нормально.
server.conf:
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key  # This file should be kept secret
dh keys/dh2048.pem
server 192.168.3.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth keys/ta.key 0 # This file is secret
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

client.conf:
client
dev tun
proto udp
remote server_addr 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert key.crt
key key.key
tls-auth ta.key 1
verb 3

Дожили до того, что за клиентом появилась железка-видеорегистратор, к которой нужен доступ через сервер. На сервере добавил команды в конфиг:
client-config-dir clients
route 192.168.4.0 255.255.255.0
(потом даже пробовал push "route 192.168.4.0 255.255.255.0", хотя, если верить доке - оно не по тем делам)
в ccd/client:
ifconfig-push 192.168.3.6 255.255.255.252
iroute 192.168.4.0 255.255.255.0

на сервере появился маршрут на сеть:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.3.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.4.0     192.168.3.2     255.255.255.0   UG        0 0          0 tun0
192.168.3.0     192.168.3.2     255.255.255.0   UG        0 0          0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         xxx.xxx.xxx.xxx 0.0.0.0         UG        0 0          0 eth0

но с сервера железяка не видна. Клиент 192.168.3.6 пингуется, если пинговать железяку (192.168.4.77) то пакетики в vpn-канал уходят (судя по tcpdump-у), а ответа нет. На клиенте запустил wireshark - пинги на железяку в vpn-канале отсутствуют. :( Попытки прописать на сервере маршрут на железяку через 192.168.3.6 вручную заканчиваются сообщением об ошибке:
# route add -host 192.168.4.77 gw 192.168.3.6
SIOCADDRT: Network is unreachable

Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал по несколько раз (может, уже глаз замылился) - так и не добился ничего. :(

Содержание
Сообщения в этом обсуждении
"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 14:45 
>Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал
>по несколько раз (может, уже глаз замылился) - так и не
>добился ничего. :(

Нарисуй схему, тяжело понять

"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 16:19 
>>Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал
>>по несколько раз (может, уже глаз замылился) - так и не
>>добился ничего. :(
>
>Нарисуй схему, тяжело понять

Так, вроде, все стандартно-примитивно:
OVPN-server(192.168.3.1) <-> Internet <-> (192.168.3.6)client(192.168.4.1) <-> (192.168.4.77)registrator

"OpenVPN и маршрутизация"
Отправлено BlackHawk , 21-Июл-09 19:09 
>>>Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал
>>>по несколько раз (может, уже глаз замылился) - так и не
>>>добился ничего. :(
>>
>>Нарисуй схему, тяжело понять
>
>Так, вроде, все стандартно-примитивно:
>OVPN-server(192.168.3.1) <-> Internet <-> (192.168.3.6)client(192.168.4.1) <-> (192.168.4.77)registrator

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

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 21-Июл-09 20:20 
>[оверквотинг удален]
>>>>добился ничего. :(
>>>
>>>Нарисуй схему, тяжело понять
>>
>>Так, вроде, все стандартно-примитивно:
>>OVPN-server(192.168.3.1) <-> Internet <-> (192.168.3.6)client(192.168.4.1) <-> (192.168.4.77)registrator
>
>линуховая машина и не должна видеть регистратор по той причине, что он
>стоит за натом, а вот регистратор при правильной настройке должен видеть
>линуховую машину

Где вы там NAT увидели?

"OpenVPN и маршрутизация"
Отправлено Septima , 21-Июл-09 22:29 
>[оверквотинг удален]
>>>>добился ничего. :(
>>>
>>>Нарисуй схему, тяжело понять
>>
>>Так, вроде, все стандартно-примитивно:
>>OVPN-server(192.168.3.1) <-> Internet <-> (192.168.3.6)client(192.168.4.1) <-> (192.168.4.77)registrator
>
>линуховая машина и не должна видеть регистратор по той причине, что он
>стоит за натом, а вот регистратор при правильной настройке должен видеть
>линуховую машину

Гм, на счет НАТ-а мысль здравая, но смущает другое - openvpn про нат на нем ничего не знает. :-) А в _канале_ (на приемном tap-интерфейсе) пакетов для сети за натом на приемной стороне уже нет, хотя, как мне глубоко кажется, все-таки должны быть.

А на счет НАТ-а в следующий раз проверю...

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 16:45 
>Попытки прописать на сервере маршрут на железяку через 192.168.3.6
>вручную заканчиваются сообщением об ошибке:
># route add -host 192.168.4.77 gw 192.168.3.6
>SIOCADDRT: Network is unreachable

это лишнее, так как у тебя уже есть маршрут в 4ю подсеть.

>Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал
>по несколько раз (может, уже глаз замылился) - так и не
>добился ничего. :(

Покажи вывод tcpdump при пинге с сервера 192.168.4.1

"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 17:08 
>>Попытки прописать на сервере маршрут на железяку через 192.168.3.6
>>вручную заканчиваются сообщением об ошибке:
>># route add -host 192.168.4.77 gw 192.168.3.6
>>SIOCADDRT: Network is unreachable
>это лишнее, так как у тебя уже есть маршрут в 4ю подсеть.

Согласен, но это уже "жест отчаяния". ;(

ping 192.168.3.6
PING 192.168.3.6 (192.168.3.6) from 192.168.3.1 : 56(84) bytes of data.
64 bytes from 192.168.3.6: icmp_seq=1 ttl=128 time=69.211 msec
64 bytes from 192.168.3.6: icmp_seq=2 ttl=128 time=69.788 msec
64 bytes from 192.168.3.6: icmp_seq=3 ttl=128 time=68.901 msec

--- 192.168.3.6 ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 2013ms
rtt min/avg/max/mdev = 68.901/69.300/69.788/0.367 ms

По логике линукса шлюз должен лежать в пределах подсети, но как быть, если шлюз в соседней подсети, но хост знает, как в ту подсеть попасть?

>>Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал
>>по несколько раз (может, уже глаз замылился) - так и не
>>добился ничего. :(
>
>Покажи вывод tcpdump при пинге с сервера 192.168.4.1

ping 192.168.4.1
PING 192.168.4.1 (192.168.4.1) from 192.168.3.1 : 56(84) bytes of data.

--- 192.168.4.1 ping statistics ---
8 packets transmitted, 0 received, 100% loss, time 7013ms

tcpdump -npi tun0
Warning: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: listening on tun0
16:01:29.655349 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:30.668322 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:31.668347 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:32.668426 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:33.668407 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:34.668371 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:35.668355 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
16:01:36.668370 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 17:16 
>[оверквотинг удален]
>socket
>tcpdump: listening on tun0
>16:01:29.655349 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:30.668322 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:31.668347 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:32.668426 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:33.668407 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:34.668371 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:35.668355 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>16:01:36.668370 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)

Похоже, что машина 192.168.4.1 не знает куда слать ответы для подсети 3.0. Покажи маршруты на машине 192.168.4.1 после установки vpn.

"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 17:35 
>[оверквотинг удален]
>>16:01:30.668322 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>16:01:31.668347 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>16:01:32.668426 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>16:01:33.668407 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>16:01:34.668371 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>16:01:35.668355 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>16:01:36.668370 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>
>Похоже, что машина 192.168.4.1 не знает куда слать ответы для подсети 3.0.
>Покажи маршруты на машине 192.168.4.1 после установки vpn.

Сейчас уже не могу, т.к. оттуда я уехал, но, как я уже писал раньше - при пинге 192.168.4.77 с сервера на клиенте 192.168.3.1 (он же - 192.168.4.1) _в_канале_ tun не было ничего. А вот проверить пинг на 192.168.4.1 я, к сожалению, не подумал. :(

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 17:38 
>[оверквотинг удален]
>>>16:01:35.668355 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>>16:01:36.668370 192.168.3.1 > 192.168.4.1: icmp: echo request (DF)
>>
>>Похоже, что машина 192.168.4.1 не знает куда слать ответы для подсети 3.0.
>>Покажи маршруты на машине 192.168.4.1 после установки vpn.
>
>Сейчас уже не могу, т.к. оттуда я уехал, но, как я уже
>писал раньше - при пинге 192.168.4.77 с сервера на клиенте 192.168.3.1
>(он же - 192.168.4.1) _в_канале_ tun не было ничего. А вот
>проверить пинг на 192.168.4.1 я, к сожалению, не подумал. :(

192.168.4.1 - там же стоит Windows XP? Если да, то надо включить на ней ip forwarding

http://support.microsoft.com/kb/315236

На машине 192.168.4.77 указать 192.168.4.1 как шлюз по умолчанию

"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 18:01 
>[оверквотинг удален]
>>>Покажи маршруты на машине 192.168.4.1 после установки vpn.
>>
>>Сейчас уже не могу, т.к. оттуда я уехал, но, как я уже
>>писал раньше - при пинге 192.168.4.77 с сервера на клиенте 192.168.3.1
>>(он же - 192.168.4.1) _в_канале_ tun не было ничего. А вот
>>проверить пинг на 192.168.4.1 я, к сожалению, не подумал. :(
>
>192.168.4.1 - там же стоит Windows XP? Если да, то надо включить
>на ней ip forwarding
>http://support.microsoft.com/kb/315236

Форвардинг на XP включается автоматически при активации "Общего доступа для подключения к интернет". Я в VPN-канале со стороны клиента не вижу пакетов для 192.168.4.77, хотя, подозреваю, что и для 192.168.4.0/24 я тоже в настоящее время (на текущих настройках) почем-то не увижу. :(

>На машине 192.168.4.77 указать 192.168.4.1 как шлюз по умолчанию

Это - само собой разумеется.

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 19:18 
>Форвардинг на XP включается автоматически при активации "Общего доступа для подключения > к интернет".

не знал, так как с XP почти не работаю :)

> Я в VPN-канале со стороны клиента не вижу пакетов для
>192.168.4.77, хотя, подозреваю, что и для 192.168.4.0/24 я тоже в настоящее
>время (на текущих настройках) почем-то не увижу. :(

давай от простого, посомтри на машине 4.1 есть ли попытки пинга с 192.168.3.2?

"OpenVPN и маршрутизация"
Отправлено PavelR , 14-Июл-09 20:02 
>[оверквотинг удален]
>192.168.3.0     192.168.3.2     255.255.255.0   UG        0 0          0 tun0
>192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
>192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
>192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
>192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
>127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
>0.0.0.0         xxx.xxx.xxx.xxx 0.0.0.0         UG        0 0          0 eth0
>
>но с сервера железяка не видна. Клиент 192.168.3.6 пингуется, если пинговать железяку
>(192.168.4.77) то пакетики в vpn-канал уходят (судя по tcpdump-у), а ответа

Эммм, извините что вмешиваюсь, но что это за цифирки 192.168.3.2 выше по тексту ?
Маршруты в 3.0/24 и 4.0/24 прописаны в этот хост...

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 20:08 
>[оверквотинг удален]
>>192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
>>127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
>>0.0.0.0         xxx.xxx.xxx.xxx 0.0.0.0         UG        0 0          0 eth0
>>
>>но с сервера железяка не видна. Клиент 192.168.3.6 пингуется, если пинговать железяку
>>(192.168.4.77) то пакетики в vpn-канал уходят (судя по tcpdump-у), а ответа
>
>Эммм, извините что вмешиваюсь, но что это за цифирки 192.168.3.2 выше по
>тексту ?
>Маршруты в 3.0/24 и 4.0/24 прописаны в этот хост...

Если не ошибаюсь это ip OpenVPN сервера

"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 20:09 
>[оверквотинг удален]
>>192.168.15.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
>>127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
>>0.0.0.0         xxx.xxx.xxx.xxx 0.0.0.0         UG        0 0          0 eth0
>>
>>но с сервера железяка не видна. Клиент 192.168.3.6 пингуется, если пинговать железяку
>>(192.168.4.77) то пакетики в vpn-канал уходят (судя по tcpdump-у), а ответа
>
>Эммм, извините что вмешиваюсь, но что это за цифирки 192.168.3.2 выше по
>тексту ?
>Маршруты в 3.0/24 и 4.0/24 прописаны в этот хост...

Дыкть, эта - шлюз openvpn-овский. виртуальный...

"OpenVPN и маршрутизация"
Отправлено PavelR , 14-Июл-09 20:13 
>[оверквотинг удален]
>>>0.0.0.0         xxx.xxx.xxx.xxx 0.0.0.0         UG        0 0          0 eth0
>>>
>>>но с сервера железяка не видна. Клиент 192.168.3.6 пингуется, если пинговать железяку
>>>(192.168.4.77) то пакетики в vpn-канал уходят (судя по tcpdump-у), а ответа
>>
>>Эммм, извините что вмешиваюсь, но что это за цифирки 192.168.3.2 выше по
>>тексту ?
>>Маршруты в 3.0/24 и 4.0/24 прописаны в этот хост...
>
>Дыкть, эта - шлюз openvpn-овский. виртуальный...

ну дык 4.0/24 то за 3.6 а не за 3.2 ?

"OpenVPN и маршрутизация"
Отправлено Septima , 14-Июл-09 21:05 
>>>>но с сервера железяка не видна. Клиент 192.168.3.6 пингуется, если пинговать
>>>>железяку (192.168.4.77) то пакетики в vpn-канал уходят (судя по tcpdump-у), а ответа
>>>Эммм, извините что вмешиваюсь, но что это за цифирки 192.168.3.2 выше по
>>>тексту ?
>>>Маршруты в 3.0/24 и 4.0/24 прописаны в этот хост...
>>Дыкть, эта - шлюз openvpn-овский. виртуальный...
>ну дык 4.0/24 то за 3.6 а не за 3.2 ?

Пра-льно, но робяты из openvpn считають (и их можно попытаться понять) что при прописанных в конфигах сетях, клиент должен выловить из пространства openvpn-канала пакеты, предназначенные для сети за ним.

А вот прописать по-человечески маршрут на сервере для 4.0/24 (3.6 который) на том-же сервере не удается, хотя 3.6 пингуется с сервера нормально. :( Бо ядро считает, что он (3.6) лежит...

Вот!!!! Нашлась бяка!!!:
ifconfig tun0|grep inet
inet addr:192.168.3.1  P-t-P:192.168.3.2  Mask:255.255.255.255
Т.е., ядро считает, что нужный мне шлюз лежит не в одной сети с сервером. Не знаю, как оно отобразится на работе openvpn - проверю завтра, но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и маршрут прописался.

"OpenVPN и маршрутизация"
Отправлено PavelR , 14-Июл-09 22:10 
>[оверквотинг удален]
>том-же сервере не удается, хотя 3.6 пингуется с сервера нормально. :(
>Бо ядро считает, что он (3.6) лежит...
>
>Вот!!!! Нашлась бяка!!!:
>ifconfig tun0|grep inet
>inet addr:192.168.3.1  P-t-P:192.168.3.2  Mask:255.255.255.255
>Т.е., ядро считает, что нужный мне шлюз лежит не в одной сети
>с сервером. Не знаю, как оно отобразится на работе openvpn -
>проверю завтра, но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и
>маршрут прописался.

аа, ну тогда всё понятно - это же тун-девайс, опенвпн обманывает ядро, говоря что подсетка за 3.2, заставляя его кинуть пакет в тун-интерфейс, где опенвпн его подхватывает и перемаршрутизирует  куда считает нужным. так что "но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и маршрут прописался" - скорее всего лишнее. надо пересмотреть заново.

tcpdump на сервере показывает что пакеты в сеть 4.0 уходят в тун0 ?

"OpenVPN и маршрутизация"
Отправлено Septima , 15-Июл-09 01:15 
>[оверквотинг удален]
>>с сервером. Не знаю, как оно отобразится на работе openvpn -
>>проверю завтра, но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и
>>маршрут прописался.
>аа, ну тогда всё понятно - это же тун-девайс, опенвпн обманывает ядро,
>говоря что подсетка за 3.2, заставляя его кинуть пакет в тун-интерфейс,
>где опенвпн его подхватывает и перемаршрутизирует  куда считает нужным. так
>что "но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и маршрут
>прописался" - скорее всего лишнее. надо пересмотреть заново.
>
>tcpdump на сервере показывает что пакеты в сеть 4.0 уходят в тун0?

Да. Но на клиенте пакеты для 4.0 уже не видны (смотрел wireshark-ом). :(

"OpenVPN и маршрутизация"
Отправлено Septima , 26-Июл-09 14:36 
>>ifconfig tun0|grep inet
>>inet addr:192.168.3.1  P-t-P:192.168.3.2  Mask:255.255.255.255
>>Т.е., ядро считает, что нужный мне шлюз лежит не в одной сети
>>с сервером. Не знаю, как оно отобразится на работе openvpn -
>>проверю завтра, но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и
>>маршрут прописался.
>аа, ну тогда всё понятно - это же тун-девайс, опенвпн обманывает ядро,
>говоря что подсетка за 3.2, заставляя его кинуть пакет в тун-интерфейс,
>где опенвпн его подхватывает и перемаршрутизирует  куда считает нужным. так

Вот на сервере пакеты кидаются в интерфейс, но на клиенте из интерфейса уже не выходят. :( Где их искать теперь - в каком параллельном мире?

"OpenVPN и маршрутизация"
Отправлено reader , 14-Июл-09 22:18 
>[оверквотинг удален]
>том-же сервере не удается, хотя 3.6 пингуется с сервера нормально. :(
>Бо ядро считает, что он (3.6) лежит...
>
>Вот!!!! Нашлась бяка!!!:
>ifconfig tun0|grep inet
>inet addr:192.168.3.1  P-t-P:192.168.3.2  Mask:255.255.255.255
>Т.е., ядро считает, что нужный мне шлюз лежит не в одной сети
>с сервером. Не знаю, как оно отобразится на работе openvpn -
>проверю завтра, но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и
>маршрут прописался.

при tun интерфейсе подымается точка-точка, хотите маску /24 поменяйте на tap

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 14-Июл-09 23:21 
>Вот!!!! Нашлась бяка!!!:
>ifconfig tun0|grep inet
>inet addr:192.168.3.1  P-t-P:192.168.3.2  Mask:255.255.255.255
>Т.е., ядро считает, что нужный мне шлюз лежит не в одной сети
>с сервером. Не знаю, как оно отобразится на работе openvpn -
>проверю завтра, но ifconfig tun0 192.168.3.1 netmask 255.255.255.0 поправил ситуацию и
>маршрут прописался.

что то вы намудрили. Вот у меня есть

# ifconfig tun1 | grep inet
          inet addr:172.16.0.1  P-t-P:172.16.0.2  Mask:255.255.255.255

используется для road warrior. При подключении я отлично вижу машины, которые находятся в других подсетях, куда VPN сервер получает доступ через другой VPN тунель

# ifconfig tun0 | grep inet
          inet addr:10.3.0.1  P-t-P:10.3.0.2  Mask:255.255.255.255

# route -n | grep 192.168.11.0
192.168.11.0    10.3.0.2        255.255.255.0   UG    0      0        0 tun0

> ping 192.168.11.1

Обмен пакетами с 192.168.11.1 по 32 байт:

Ответ от 192.168.11.1: число байт=32 время=269мс TTL=63
Ответ от 192.168.11.1: число байт=32 время=250мс TTL=63
Ответ от 192.168.11.1: число байт=32 время=392мс TTL=63
Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63

"OpenVPN и маршрутизация"
Отправлено reader , 14-Июл-09 23:33 
>[оверквотинг удален]
>tun0
>
>> ping 192.168.11.1
>
>Обмен пакетами с 192.168.11.1 по 32 байт:
>
>Ответ от 192.168.11.1: число байт=32 время=269мс TTL=63
>Ответ от 192.168.11.1: число байт=32 время=250мс TTL=63
>Ответ от 192.168.11.1: число байт=32 время=392мс TTL=63
>Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63

просто клиенту должен был отдаваться адрес 3.2, а не 3.6

верней ifconfig-push 192.168.3.6 255.255.255.252 не должно было быть, это вообще лишнее

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 15-Июл-09 00:13 
>[оверквотинг удален]
>>Обмен пакетами с 192.168.11.1 по 32 байт:
>>
>>Ответ от 192.168.11.1: число байт=32 время=269мс TTL=63
>>Ответ от 192.168.11.1: число байт=32 время=250мс TTL=63
>>Ответ от 192.168.11.1: число байт=32 время=392мс TTL=63
>>Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63
>
>просто клиенту должен был отдаваться адрес 3.2, а не 3.6
>
>верней ifconfig-push 192.168.3.6 255.255.255.252 не должно было быть, это вообще лишнее

Это с каких делов? 3.2 это ip OpenVPN сервера!!! Клиенту его нельзя выдавать.

А вот насчет ifconfig-push 192.168.3.6 255.255.255.252

Он прав, так как это ограничения реализации tun в windows xp

On Windows, point-to-point IP support (i.e. --dev tun)
is emulated by the TAP-Win32 driver.  The major limitation
imposed by this approach is that the --ifconfig local and
remote endpoints must be part of the same 255.255.255.252
subnet.

Я бы выдавал лучше так
ifconfig-push 192.168.3.5 192.168.3.6

"OpenVPN и маршрутизация"
Отправлено reader , 15-Июл-09 00:40 
>[оверквотинг удален]
>>>Ответ от 192.168.11.1: число байт=32 время=250мс TTL=63
>>>Ответ от 192.168.11.1: число байт=32 время=392мс TTL=63
>>>Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63
>>
>>просто клиенту должен был отдаваться адрес 3.2, а не 3.6
>>
>>верней ifconfig-push 192.168.3.6 255.255.255.252 не должно было быть, это вообще лишнее
>
>Это с каких делов? 3.2 это ip OpenVPN сервера!!! Клиенту его нельзя
>выдавать.

у сервера вроде 3.1
>
>А вот насчет ifconfig-push 192.168.3.6 255.255.255.252

это по моему с dev tap лучше использовать
>[оверквотинг удален]
>Он прав, так как это ограничения реализации tun в windows xp
>
>On Windows, point-to-point IP support (i.e. --dev tun)
>is emulated by the TAP-Win32 driver.  The major limitation
>imposed by this approach is that the --ifconfig local and
>remote endpoints must be part of the same 255.255.255.252
>subnet.
>
>Я бы выдавал лучше так
>ifconfig-push 192.168.3.5 192.168.3.6

то есть уйти в другую подсеть?

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 15-Июл-09 01:15 
>[оверквотинг удален]
>>>>Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63
>>>
>>>просто клиенту должен был отдаваться адрес 3.2, а не 3.6
>>>
>>>верней ifconfig-push 192.168.3.6 255.255.255.252 не должно было быть, это вообще лишнее
>>
>>Это с каких делов? 3.2 это ip OpenVPN сервера!!! Клиенту его нельзя
>>выдавать.
>
>у сервера вроде 3.1

у сервера тоже P-t-P

server 192.168.3.0 255.255.255.0

это срока говорит о том, что у сервера будет 192.168.3.1 P-t-P 192.168.3.2

>>А вот насчет ifconfig-push 192.168.3.6 255.255.255.252
>
>это по моему с dev tap лучше использовать

не совсем понял, что именно?

>>Я бы выдавал лучше так
>>ifconfig-push 192.168.3.5 192.168.3.6
>
>то есть уйти в другую подсеть?

нет, оставаться в маске 252 с сервером

Запусти на windows
>openvpn --show-valid-subnets

и ты увидишь рекомендуемые пары адресов сервер-клиент

"OpenVPN и маршрутизация"
Отправлено Septima , 21-Июл-09 14:24 
>>>Я бы выдавал лучше так
>>>ifconfig-push 192.168.3.5 192.168.3.6
>>то есть уйти в другую подсеть?
>нет, оставаться в маске 252 с сервером

"В маске с 252 с сервером остаться" не получится, т.к. 3.6 или 3.5 сервер никак не получит. Оба этих адреса будут на стороне клиента и только там. Один будет присвоен виртуальному адаптеру, т.е. самому хосту клиента, а другой - виртуальному маршрутизатору.

"OpenVPN и маршрутизация"
Отправлено Septima , 15-Июл-09 01:35 
>[оверквотинг удален]
>>>Ответ от 192.168.11.1: число байт=32 время=250мс TTL=63
>>>Ответ от 192.168.11.1: число байт=32 время=392мс TTL=63
>>>Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63
>>
>>просто клиенту должен был отдаваться адрес 3.2, а не 3.6
>>
>>верней ifconfig-push 192.168.3.6 255.255.255.252 не должно было быть, это вообще лишнее
>
>Это с каких делов? 3.2 это ip OpenVPN сервера!!! Клиенту его нельзя
>выдавать.

Вернее, если присмотреться, 3.2 - это адрес шлюза для сервера. Адрес сервера по дефолту - .1. Для всех клиентов используются пары адресов (подсети /30): четный адрес - самому клиенту, нечетный - виртуальный маршрутизатор. Насколько я помню - ноги идеологии растут из Cisco.

>[оверквотинг удален]
>Он прав, так как это ограничения реализации tun в windows xp
>
>On Windows, point-to-point IP support (i.e. --dev tun)
>is emulated by the TAP-Win32 driver.  The major limitation
>imposed by this approach is that the --ifconfig local and
>remote endpoints must be part of the same 255.255.255.252
>subnet.
>
>Я бы выдавал лучше так
>ifconfig-push 192.168.3.5 192.168.3.6

Если перечитать ман (что я за последнее время сделал уже раз 15), то надо, все-таки:
--ifconfig-push local _remote-netmask_
Push virtual IP endpoints for client tunnel, overriding the --ifconfig-pool dynamic allocation.

Адрес gateway-я тут никак не подходит, если верить документации, а я склонен ей верить, пока мне не доказали, что там написано с ошибками.

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 15-Июл-09 13:59 
>Вернее, если присмотреться, 3.2 - это адрес шлюза для сервера. Адрес сервера
>по дефолту - .1. Для всех клиентов используются пары адресов (подсети
>/30): четный адрес - самому клиенту, нечетный - виртуальный маршрутизатор. Насколько
>я помню - ноги идеологии растут из Cisco.

А вы не путаете случайно?

В конструкции

ifconfig-push 172.16.0.77 172.16.0.78

172.16.0.77 - получит клиент, а 172.16.0.78 будет его шлюзом

"OpenVPN и маршрутизация"
Отправлено Septima , 21-Июл-09 14:10 
>[оверквотинг удален]
>>/30): четный адрес - самому клиенту, нечетный - виртуальный маршрутизатор. Насколько
>>я помню - ноги идеологии растут из Cisco.
>
>А вы не путаете случайно?
>
>В конструкции
>
>ifconfig-push 172.16.0.77 172.16.0.78
>
>172.16.0.77 - получит клиент, а 172.16.0.78 будет его шлюзом

Нет - по документации такая конструкция вообще не имеет смысла. :( Если оно работает так, как Вы написали, то это - недокументированная фича.

"OpenVPN и маршрутизация"
Отправлено Septima , 15-Июл-09 01:23 
>[оверквотинг удален]
>>> ping 192.168.11.1
>>
>>Обмен пакетами с 192.168.11.1 по 32 байт:
>>
>>Ответ от 192.168.11.1: число байт=32 время=269мс TTL=63
>>Ответ от 192.168.11.1: число байт=32 время=250мс TTL=63
>>Ответ от 192.168.11.1: число байт=32 время=392мс TTL=63
>>Ответ от 192.168.11.1: число байт=32 время=437мс TTL=63
>
>просто клиенту должен был отдаваться адрес 3.2, а не 3.6

Ну, он не первый клиент в vpn-е. Динамическую раздачу адресов мы уже перешагнули... :(

>верней ifconfig-push 192.168.3.6 255.255.255.252 не должно было быть, это вообще лишнее

Без этого виндовый клиент не работает - ругается. Ему нужна маска именно /30 и именно четко указанная.

"OpenVPN и маршрутизация"
Отправлено ALex_hha , 15-Июл-09 01:31 
>Без этого виндовый клиент не работает - ругается. Ему нужна маска именно
>/30 и именно четко указанная.

попробуй все таки выдавать ip, как я написал

И покажи таблицу маршрутизации с 4.1

"OpenVPN и маршрутизация"
Отправлено Septima , 21-Июл-09 14:07 
Продолжим - я снова добрался до этой площадки....

>>Без этого виндовый клиент не работает - ругается. Ему нужна маска именно
>>/30 и именно четко указанная.
>
>попробуй все таки выдавать ip, как я написал
>
>И покажи таблицу маршрутизации с 4.1

C:\> route print
===========================================================================
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x2 ...00 21 91 1f a7 d3 ...... D-Link DFE-520TX PCI Fast Ethernet Adapter - Минипорт планировщика пакетов
0x3 ...00 1a 4d 80 0c a0 ...... NVIDIA nForce Networking Controller - Минипорт планировщика пакетов
0x4 ...00 11 67 36 9d ad ...... Bluetooth PAN Network Adapter - Минипорт планировщика пакетов
0x5 ...00 ff 07 18 ae ee ...... TAP-Win32 Adapter V8 - Минипорт планировщика пакетов

===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.4       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.1.0    255.255.255.0      192.168.1.4     192.168.1.4       20
      192.168.1.4  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.1.255  255.255.255.255      192.168.1.4     192.168.1.4       20
      192.168.3.1  255.255.255.255      192.168.3.5     192.168.3.6       1
      192.168.3.4  255.255.255.252      192.168.3.6     192.168.3.6       30
      192.168.3.6  255.255.255.255        127.0.0.1       127.0.0.1       30
    192.168.3.255  255.255.255.255      192.168.3.6     192.168.3.6       30
      192.168.4.0    255.255.255.0      192.168.4.1     192.168.4.1       20
      192.168.4.1  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.4.255  255.255.255.255      192.168.4.1     192.168.4.1       20
        224.0.0.0        240.0.0.0      192.168.1.4     192.168.1.4       20
        224.0.0.0        240.0.0.0      192.168.3.6     192.168.3.6       30
        224.0.0.0        240.0.0.0      192.168.4.1     192.168.4.1       20
  255.255.255.255  255.255.255.255      192.168.1.4     192.168.1.4       1
  255.255.255.255  255.255.255.255      192.168.3.6     192.168.3.6       1
  255.255.255.255  255.255.255.255      192.168.3.6               4       1
  255.255.255.255  255.255.255.255      192.168.4.1     192.168.4.1       1
Основной шлюз:         192.168.1.1
===========================================================================
Постоянные маршруты:
  Отсутствует

При этом по-прежнему нет ответа от 4.1. tcpdump на сервере показывает, что пакеты от 3.1 на 4.1 в канал уходят, а wireshark на клиенте никаких пакетов на Tap-Win32 адаптере не наблюдает. :(

"OpenVPN и маршрутизация"
Отправлено Septima , 30-Июл-09 21:33 
Ну что - нет зубров в этом деле? Сегодня поднял на этом же конфиге клиента под FreeBSD 7.2, openvpn-2.0.6_9 из портов - ситуация один-в-один. На клиенте на tun-интерфейсе пакетов для 192.168.4.0/24 нет, хотя на серваке маршрут прописан:
192.168.3.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.4.0     192.168.3.2     255.255.255.0   UG        0 0          0 tun0
192.168.3.0     192.168.3.2     255.255.255.0   UG        0 0          0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         213.179.254.221 0.0.0.0         UG        0 0          0 eth0

Кстати, и сеть за клиентом перестала видеть сервак (к слову о нат-е)... :-(
127.0.0.1          127.0.0.1          UH          0      233    lo0
192.168.0.0/24     192.168.3.1        UGS         0        0   tun1
192.168.1.0/24     link#1             UC          0        0    rl0
192.168.1.1        link#1             UHLW        1        0    rl0
192.168.3.1/32     192.168.3.5        UGS         1      205   tun1
192.168.3.5        192.168.3.6        UH          1        0   tun1
192.168.4.0/24     link#2             UC          0        0    vr0
192.168.4.4        00:1a:4d:80:0c:a0  UHLW        1   157648    vr0    958

и точно так же - на сервере на tun-интерфейсе нет пакетов для 192.168.3.1 от 192.168.4.х, хотя на роутере (FreeBSD который) все уходит. При этом между Unix-машинами openvpn-пакеты ходят в такт уходящим в канал пакетам.

Чувствую, что где-то я накосячил, но вот где - понять не могу. :-(

"OpenVPN и маршрутизация"
Отправлено reader , 31-Июл-09 00:24 
есть примерно такое же , но с разницей в том что сервер и клиент поменяны местами относительно вашего варианта

клиент

remote a.b.c.d 1194
client
dev tap
proto tcp
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert phoom.crt
key phoom.key
tls-auth ta.key 1
tls-client
auth sha1
auth-user-pass
comp-lzo
verb 3


сервер

port 1194
proto tcp
dev tap
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/router.crt
key /etc/openvpn/keys/router.key
dh /etc/openvpn/keys/dh2048.pem
tls-server
tls-auth /etc/openvpn/keys/ta.key 0
tls-timeout 120
auth SHA1
mode server
ifconfig 10.1.0.1 255.255.255.0
duplicate-cn
ifconfig-pool-persist /var/log/openvpn-ipp.txt
server-bridge 10.1.0.1 255.255.255.0 10.1.0.2 10.1.0.50
push "route 10.10.0.0 255.255.255.0 metric 5"
client-config-dir /etc/openvpn/ccd
push "dhcp-option DNS 10.10.0.254"
client-to-client
keepalive 15 120
cipher BF-CBC
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status /var/log/openvpn-status.log 3500
log-append /var/log/openvpn.log
verb 3
mute 20
tun-mtu 1500
tun-mtu-extra 32
mssfix 1250
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

/etc/openvpn/ccd/phoom
ifconfig-push 10.1.0.2 255.255.255.0
push "route 10.10.0.0 255.255.255.0"

адрес tap-интерфейса клиента (phoom) 10.1.0.2, сервера 10.1.0.1, сеть за сервером 10.10.0.0/24

с клиента вся подсеть за сервером доступна.

"OpenVPN и маршрутизация"
Отправлено Septima , 05-Авг-09 20:25 
>Чувствую, что где-то я накосячил, но вот где - понять не могу. :-(

Уже впору какие-то шаманские пляски с бубном устраивать...
Дошел до того, что поставил на отдельной машине VMWare, насетапил три виртуальные машины, навиртуалил две сети, даже нашел инсталл почти 10-летней давности, что на сервере использовался - ASP-Linux 7.2, пересобрал ядра, либы - чтоб все было как в живую, перетянул конфиги и... - все работает!!! :-( Куда, на что еще посмотреть, чтоб в и жизни тоже работало?

"OpenVPN и маршрутизация"
Отправлено s_sh , 09-Авг-09 22:09 
у меня следующая ситуация:
сервер c openvpn на линуксе(лок. ip 192.168.0.1).
клиент на линуксе (лок. ip 10.1.1.1). имя сертификата "client0".
в /etc/openvpn/ccd/client0:
   push "route 192.168.0.0 255.255.255.0"
   iroute 10.1.1.0 255.255.255.0
после поднятия соединения клиент и его сеть начинает пинговаться только после
добавления на сервере маршрута route add -net 10.1.1.0 netmask 255.255.255.0 dev tun0
видно это сделано для возможности параллельной маршрутизации до подсетей нескольких клиентов.
сети друг друга видят, все хорошо.

интересный момент. когда поставил клиента на машине с win xp (включил сервис маршрутизации и удаленного доступа, в реестре IPEnableRouter = 1)
c сервера пинговался только клиент, компьютеры за клиентом были недоступны. причем из сети клиента сервер был прекрасно виден.
зато с компьютеров в сети сервера при указании сервера как шлюза в сеть клиента
вся сеть клиента была замечательно видна. так и не понял в чем было дело.


"OpenVPN и маршрутизация"
Отправлено Septima , 11-Авг-09 23:49 
>>Чувствую, что где-то я накосячил, но вот где - понять не могу. :-(
>
>Уже впору какие-то шаманские пляски с бубном устраивать...
>Дошел до того, что поставил на отдельной машине VMWare, насетапил три виртуальные
>машины, навиртуалил две сети, даже нашел инсталл почти 10-летней давности, что
>на сервере использовался - ASP-Linux 7.2, пересобрал ядра, либы - чтоб
>все было как в живую, перетянул конфиги и... - все работает!!!
>:-( Куда, на что еще посмотреть, чтоб в и жизни тоже
>работало?

В общем, оказалось, что некорректно были выставлены права на каталог ccd: содержимое каталога читается в момент авторизации клиента, в то время, как понижение в правах до указанных в конфиге - после чтения основного кофига. В итоге сервер не мог прочитать параметр iroute из определения клиента в каталоге ccd и считал, что за клиентом сети нет.