forum.opennet.ru - "OpenVPN и маршрутизация" (38)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"OpenVPN и маршрутизация"

Форумы OpenNET: Виртуальная конференция (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"OpenVPN и маршрутизация"		+/–
Сообщение от Septima (??) on 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 перечитал по несколько раз (может, уже глаз замылился) - так и не добился ничего. :(
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

OpenVPN и маршрутизация, ALex_hha, 14:45 , 14-Июл-09, (1)

OpenVPN и маршрутизация, Septima, 16:19 , 14-Июл-09, (2)

OpenVPN и маршрутизация, BlackHawk, 19:09 , 21-Июл-09, (30)

OpenVPN и маршрутизация, ALex_hha, 20:20 , 21-Июл-09, (31)
OpenVPN и маршрутизация, Septima, 22:29 , 21-Июл-09, (32)

OpenVPN и маршрутизация, ALex_hha, 16:45 , 14-Июл-09, (3)

OpenVPN и маршрутизация, Septima, 17:08 , 14-Июл-09, (4)

OpenVPN и маршрутизация, ALex_hha, 17:16 , 14-Июл-09, (5)

OpenVPN и маршрутизация, Septima, 17:35 , 14-Июл-09, (6)

OpenVPN и маршрутизация, ALex_hha, 17:38 , 14-Июл-09, (7)

OpenVPN и маршрутизация, Septima, 18:01 , 14-Июл-09, (8)

OpenVPN и маршрутизация, ALex_hha, 19:18 , 14-Июл-09, (9)

OpenVPN и маршрутизация, PavelR, 20:02 , 14-Июл-09, (10)

OpenVPN и маршрутизация, ALex_hha, 20:08 , 14-Июл-09, (11)
OpenVPN и маршрутизация, Septima, 20:09 , 14-Июл-09, (12)

OpenVPN и маршрутизация, PavelR, 20:13 , 14-Июл-09, (13)

OpenVPN и маршрутизация, Septima, 21:05 , 14-Июл-09, (14)

OpenVPN и маршрутизация, PavelR, 22:10 , 14-Июл-09, (15)

OpenVPN и маршрутизация, Septima, 01:15 , 15-Июл-09, (21)
OpenVPN и маршрутизация, Septima, 14:36 , 26-Июл-09, (33)

OpenVPN и маршрутизация, reader, 22:18 , 14-Июл-09, (16)
OpenVPN и маршрутизация, ALex_hha, 23:21 , 14-Июл-09, (17)

OpenVPN и маршрутизация, reader, 23:33 , 14-Июл-09, (18)

OpenVPN и маршрутизация, ALex_hha, 00:13 , 15-Июл-09, (19)

OpenVPN и маршрутизация, reader, 00:40 , 15-Июл-09, (20)

OpenVPN и маршрутизация, ALex_hha, 01:15 , 15-Июл-09, (22)

OpenVPN и маршрутизация, Septima, 14:24 , 21-Июл-09, (29)

OpenVPN и маршрутизация, Septima, 01:35 , 15-Июл-09, (25)

OpenVPN и маршрутизация, ALex_hha, 13:59 , 15-Июл-09, (26)

OpenVPN и маршрутизация, Septima, 14:10 , 21-Июл-09, (28)

OpenVPN и маршрутизация, Septima, 01:23 , 15-Июл-09, (23)

OpenVPN и маршрутизация, ALex_hha, 01:31 , 15-Июл-09, (24)

OpenVPN и маршрутизация, Septima, 14:07 , 21-Июл-09, (27)

OpenVPN и маршрутизация, Septima, 21:33 , 30-Июл-09, (34)

OpenVPN и маршрутизация, reader, 00:24 , 31-Июл-09, (35)
OpenVPN и маршрутизация, Septima, 20:25 , 05-Авг-09, (36)

OpenVPN и маршрутизация, s_sh, 22:09 , 09-Авг-09, (37)
OpenVPN и маршрутизация, Septima, 23:49 , 11-Авг-09, (38)

Сообщения по теме [Сортировка по времени | RSS]

1. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 14-Июл-09, 14:45

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

30. "OpenVPN и маршрутизация" +/–

Сообщение от BlackHawk (ok) on 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
линуховая машина и не должна видеть регистратор по той причине, что он стоит за натом, а вот регистратор при правильной настройке должен видеть линуховую машину

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

31. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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 увидели?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

32. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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-интерфейсе) пакетов для сети за натом на приемной стороне уже нет, хотя, как мне глубоко кажется, все-таки должны быть.
А на счет НАТ-а в следующий раз проверю...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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 я, к сожалению, не подумал. :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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 как шлюз по умолчанию

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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 как шлюз по умолчанию
Это - само собой разумеется.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 14-Июл-09, 19:18

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "OpenVPN и маршрутизация" +/–

Сообщение от PavelR (??) on 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 прописаны в этот хост...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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 сервера

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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-овский. виртуальный...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "OpenVPN и маршрутизация" +/–

Сообщение от PavelR (??) on 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 ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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 поправил ситуацию и маршрут прописался.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "OpenVPN и маршрутизация" +/–

Сообщение от PavelR (??) on 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 ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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-ом). :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

33. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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, заставляя его кинуть пакет в тун-интерфейс,
>где опенвпн его подхватывает и перемаршрутизирует  куда считает нужным. так
Вот на сервере пакеты кидаются в интерфейс, но на клиенте из интерфейса уже не выходят. :( Где их искать теперь - в каком параллельном мире?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "OpenVPN и маршрутизация" +/–

Сообщение от reader (ok) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (??) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "OpenVPN и маршрутизация" +/–

Сообщение от reader (ok) on 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 не должно было быть, это вообще лишнее

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "OpenVPN и маршрутизация" +/–

Сообщение от reader (ok) on 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
то есть уйти в другую подсеть?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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
и ты увидишь рекомендуемые пары адресов сервер-клиент

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

29. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 21-Июл-09, 14:24

>>>Я бы выдавал лучше так
>>>ifconfig-push 192.168.3.5 192.168.3.6
>>то есть уйти в другую подсеть?
>нет, оставаться в маске 252 с сервером
"В маске с 252 с сервером остаться" не получится, т.к. 3.6 или 3.5 сервер никак не получит. Оба этих адреса будут на стороне клиента и только там. Один будет присвоен виртуальному адаптеру, т.е. самому хосту клиента, а другой - виртуальному маршрутизатору.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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-я тут никак не подходит, если верить документации, а я склонен ей верить, пока мне не доказали, что там написано с ошибками.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 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 будет его шлюзом

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 21-Июл-09, 14:10

>[оверквотинг удален]
>>/30): четный адрес - самому клиенту, нечетный - виртуальный маршрутизатор. Насколько
>>я помню - ноги идеологии растут из Cisco.
>
>А вы не путаете случайно?
>
>В конструкции
>
>ifconfig-push 172.16.0.77 172.16.0.78
>
>172.16.0.77 - получит клиент, а 172.16.0.78 будет его шлюзом
Нет - по документации такая конструкция вообще не имеет смысла. :( Если оно работает так, как Вы написали, то это - недокументированная фича.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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 и именно четко указанная.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

24. "OpenVPN и маршрутизация" +/–

Сообщение от ALex_hha (ok) on 15-Июл-09, 01:31

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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 адаптере не наблюдает. :(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

34. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 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-пакеты ходят в такт уходящим в канал пакетам.
Чувствую, что где-то я накосячил, но вот где - понять не могу. :-(

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

35. "OpenVPN и маршрутизация" +/–

Сообщение от reader (ok) on 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
с клиента вся подсеть за сервером доступна.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

36. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 05-Авг-09, 20:25

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

37. "OpenVPN и маршрутизация" +/–

Сообщение от s_sh on 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 сервера пинговался только клиент, компьютеры за клиентом были недоступны. причем из сети клиента сервер был прекрасно виден.
зато с компьютеров в сети сервера при указании сервера как шлюза в сеть клиента
вся сеть клиента была замечательно видна. так и не понял в чем было дело.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

38. "OpenVPN и маршрутизация" +/–

Сообщение от Septima (??) on 11-Авг-09, 23:49

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "OpenVPN и маршрутизация"		+/–
Сообщение от ALex_hha (ok) on 14-Июл-09, 14:45
>Уже не первый день бьюсь, howto и man с сайта OpenVPN перечитал >по несколько раз (может, уже глаз замылился) - так и не >добился ничего. :( Нарисуй схему, тяжело понять
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "OpenVPN и маршрутизация"		+/–
	Сообщение от BlackHawk (ok) on 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 линуховая машина и не должна видеть регистратор по той причине, что он стоит за натом, а вот регистратор при правильной настройке должен видеть линуховую машину
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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 увидели?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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-интерфейсе) пакетов для сети за натом на приемной стороне уже нет, хотя, как мне глубоко кажется, все-таки должны быть. А на счет НАТ-а в следующий раз проверю...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

3. "OpenVPN и маршрутизация"		+/–
Сообщение от ALex_hha (ok) on 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
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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 я, к сожалению, не подумал. :(
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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 как шлюз по умолчанию
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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 как шлюз по умолчанию Это - само собой разумеется.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 14-Июл-09, 19:18
	>Форвардинг на XP включается автоматически при активации "Общего доступа для подключения > к интернет". не знал, так как с XP почти не работаю :) > Я в VPN-канале со стороны клиента не вижу пакетов для >192.168.4.77, хотя, подозреваю, что и для 192.168.4.0/24 я тоже в настоящее >время (на текущих настройках) почем-то не увижу. :( давай от простого, посомтри на машине 4.1 есть ли попытки пинга с 192.168.3.2?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

10. "OpenVPN и маршрутизация"		+/–
Сообщение от PavelR (??) on 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 прописаны в этот хост...
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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 сервера
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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-овский. виртуальный...
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "OpenVPN и маршрутизация"		+/–
	Сообщение от PavelR (??) on 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 ?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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 поправил ситуацию и маршрут прописался.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "OpenVPN и маршрутизация"		+/–
	Сообщение от PavelR (??) on 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 ?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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-ом). :(
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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, заставляя его кинуть пакет в тун-интерфейс, >где опенвпн его подхватывает и перемаршрутизирует куда считает нужным. так Вот на сервере пакеты кидаются в интерфейс, но на клиенте из интерфейса уже не выходят. :( Где их искать теперь - в каком параллельном мире?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "OpenVPN и маршрутизация"		+/–
	Сообщение от reader (ok) on 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
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (??) on 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
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "OpenVPN и маршрутизация"		+/–
	Сообщение от reader (ok) on 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 не должно было быть, это вообще лишнее
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "OpenVPN и маршрутизация"		+/–
	Сообщение от reader (ok) on 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 то есть уйти в другую подсеть?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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 и ты увидишь рекомендуемые пары адресов сервер-клиент
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 21-Июл-09, 14:24
	>>>Я бы выдавал лучше так >>>ifconfig-push 192.168.3.5 192.168.3.6 >>то есть уйти в другую подсеть? >нет, оставаться в маске 252 с сервером "В маске с 252 с сервером остаться" не получится, т.к. 3.6 или 3.5 сервер никак не получит. Оба этих адреса будут на стороне клиента и только там. Один будет присвоен виртуальному адаптеру, т.е. самому хосту клиента, а другой - виртуальному маршрутизатору.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 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-я тут никак не подходит, если верить документации, а я склонен ей верить, пока мне не доказали, что там написано с ошибками.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "OpenVPN и маршрутизация"		+/–
	Сообщение от ALex_hha (ok) on 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 будет его шлюзом
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "OpenVPN и маршрутизация"		+/–
	Сообщение от Septima (??) on 21-Июл-09, 14:10
	>[оверквотинг удален] >>/30): четный адрес - самому клиенту, нечетный - виртуальный маршрутизатор. Насколько >>я помню - ноги идеологии растут из Cisco. > >А вы не путаете случайно? > >В конструкции > >ifconfig-push 172.16.0.77 172.16.0.78 > >172.16.0.77 - получит клиент, а 172.16.0.78 будет его шлюзом Нет - по документации такая конструкция вообще не имеет смысла. :( Если оно работает так, как Вы написали, то это - недокументированная фича.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору