URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 82607
[ Назад ]
Исходное сообщение
"Openvpn между Debian и Freebsd!"
Отправлено kert84 , 28-Окт-08 10:48 
Пытаюсь настроить openvpn между двумя офисами! Сервер openvpn запущен на Freebsd клиент работает под Debian.
Freebsd server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
client-config-dir ccd
route 192.168.1.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log         openvpn.log
verb 6

открыл порт: 1194

Debian client.conf
dev tun
proto udp
remote 89.252.X.X 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
log openvpn.log
verb 6

Запускаю на FreeBsd сервер он устанавливает соединение P-t-P 10.8.0.1 --> 10.8.0.2 (Так должно быть???)

Запускаю на Debian клиента он устанавливает соединение P-t-P 10.8.0.6 --> 10.8.0.5 (Тоже не понимаю почему туда!)

На сервере сеть работает(не через vpn, а через обычный интеренет), на клиенте сеть пропадает - пингов ни куда нет!!! Команда route не выводит ни каких маршрутов!!!

В логах на сервере и на клиенте соединение установлено!
на сервере:

Thu Oct 23 19:41:08 2008 us=460092 OpenVPN 2.0 i386-portbld-freebsd4.11 [SSL] [LZO] built on Oct 20 2008
Thu Oct 23 19:41:08 2008 us=504420 Diffie-Hellman initialized with 1024 bit key
Thu Oct 23 19:41:08 2008 us=516844 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Oct 23 19:41:08 2008 us=517000 gw 213.148.173.229
Thu Oct 23 19:41:08 2008 us=517139 TUN/TAP device /dev/tun1 opened
Thu Oct 23 19:41:08 2008 us=517175 /sbin/ifconfig tun1 10.8.0.1 10.8.0.2 mtu 1500 netmask 255.255.255.255 up
Thu Oct 23 19:41:08 2008 us=519023 /sbin/route add -net 192.168.1.0 10.8.0.2 255.255.255.0
add net 192.168.1.0: gateway 10.8.0.2
Thu Oct 23 19:41:08 2008 us=540245 /sbin/route add -net 10.8.0.0 10.8.0.2 255.255.255.0
add net 10.8.0.0: gateway 10.8.0.2
Thu Oct 23 19:41:08 2008 us=541813 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Thu Oct 23 19:41:08 2008 us=543309 GID set to nobody
Thu Oct 23 19:41:08 2008 us=543404 UID set to nobody
Thu Oct 23 19:41:08 2008 us=543456 Socket Buffers: R=[41600->65536] S=[9216->65536]
Thu Oct 23 19:41:08 2008 us=543486 UDPv4 link local (bound): [undef]:1194
Thu Oct 23 19:41:08 2008 us=543504 UDPv4 link remote: [undef]
Thu Oct 23 19:41:08 2008 us=543531 MULTI: multi_init called, r=256 v=256
Thu Oct 23 19:41:08 2008 us=543614 IFCONFIG POOL: base=10.8.0.4 size=62
Thu Oct 23 19:41:08 2008 us=543683 IFCONFIG POOL LIST
Thu Oct 23 19:41:08 2008 us=543759 Initialization Sequence Completed
Thu Oct 23 19:41:08 2008 us=583328 MULTI: multi_create_instance called
Thu Oct 23 19:41:08 2008 us=583415 81.9.18.134:36751 Re-using SSL/TLS context
Thu Oct 23 19:41:08 2008 us=583513 81.9.18.134:36751 LZO compression initialized
Thu Oct 23 19:41:08 2008 us=583877 81.9.18.134:36751 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Oct 23 19:41:08 2008 us=583917 81.9.18.134:36751 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Thu Oct 23 19:41:08 2008 us=584011 81.9.18.134:36751 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Thu Oct 23 19:41:08 2008 us=584032 81.9.18.134:36751 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Thu Oct 23 19:41:08 2008 us=584111 81.9.18.134:36751 Local Options hash (VER=V4): '530fdded'
Thu Oct 23 19:41:08 2008 us=584143 81.9.18.134:36751 Expected Remote Options hash (VER=V4): '41690919'
Thu Oct 23 19:41:08 2008 us=584225 81.9.18.134:36751 UDPv4 READ [14] from 81.9.18.134:36751: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Oct 23 19:41:08 2008 us=584257 81.9.18.134:36751 TLS: Initial packet from 81.9.18.134:36751, sid=6a896597 37f13337
Thu Oct 23 19:41:08 2008 us=584344 81.9.18.134:36751 UDPv4 WRITE [26] to 81.9.18.134:36751: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Thu Oct 23 19:41:08 2008 us=647165 81.9.18.134:36751 UDPv4 READ [22] from 81.9.18.134:36751: P_ACK_V1 kid=0 [ 0 ]
Thu Oct 23 19:41:08 2008 us=647515 81.9.18.134:36751 UDPv4 READ [101] from 81.9.18.134:36751: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=87

клиент:

Mon Oct 27 11:06:11 2008 us=60571 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Sep 20 2007
Mon Oct 27 11:06:11 2008 us=60638 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Mon Oct 27 11:06:11 2008 us=60649 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mon Oct 27 11:06:11 2008 us=100483 WARNING: file 'client1.key' is group or others accessible
Mon Oct 27 11:06:11 2008 us=101229 LZO compression initialized
Mon Oct 27 11:06:11 2008 us=111520 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Oct 27 11:06:11 2008 us=111632 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Oct 27 11:06:11 2008 us=111664 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Oct 27 11:06:11 2008 us=111674 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Mon Oct 27 11:06:11 2008 us=111710 Local Options hash (VER=V4): '41690919'
Mon Oct 27 11:06:11 2008 us=111732 Expected Remote Options hash (VER=V4): '530fdded'
Mon Oct 27 11:06:11 2008 us=112139 Socket Buffers: R=[111616->131072] S=[111616->131072]
Mon Oct 27 11:06:11 2008 us=112197 UDPv4 link local: [undef]
Mon Oct 27 11:06:11 2008 us=112222 UDPv4 link remote: 89.252.92.110:1194
Mon Oct 27 11:06:11 2008 us=112440 UDPv4 WRITE [14] to 89.252.92.110:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Mon Oct 27 11:06:11 2008 us=156308 UDPv4 READ [26] from 89.252.92.110:1194: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Mon Oct 27 11:06:11 2008 us=156391 TLS: Initial packet from 89.252.92.110:1194, sid=cf512948 f05b7def
Mon Oct 27 11:06:11 2008 us=156459 UDPv4 WRITE [22] to 89.252.92.110:1194: P_ACK_V1 kid=0 [ 0 ]
Mon Oct 27 11:06:11 2008 us=156540 UDPv4 WRITE [101] to 89.252.92.110:1194: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=87
Mon Oct 27 11:06:11 2008 us=218885 UDPv4 READ [126] from 89.252.92.110:1194: P_CONTROL_V1 kid=0 [ 1 ] pid=1 DATA len=100
Mon Oct 27 11:06:11 2008 us=219046 UDPv4 WRITE [22] to 89.252.92.110:1194: P_ACK_V1 kid=0 [ 1 ]
Mon Oct 27 11:06:11 2008 us=219428 UDPv4 READ [114] from 89.252.92.110:1194: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Mon Oct 27 11:06:11 2008 us=219467 UDPv4 WRITE [22] to 89.252.92.110:1194: P_ACK_V1 kid=0 [ 2 ]
Mon Oct 27 11:06:11 2008 us=219820 UDPv4 READ [114] from 89.252.92.110:1194: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Mon Oct 27 11:06:11 2008 us=219858 UDPv4 WRITE [22] to 89.252.92.110:1194: P_ACK_V1 kid=0 [ 3 ]
Mon Oct 27 11:06:11 2008 us=220459 UDPv4 READ [114] from 89.252.92.110:1194: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Mon Oct 27 11:06:11 2008 us=220496 UDPv4 WRITE [22] to 89.252.92.110:1194: P_ACK_V1 kid=0 [ 4 ]
Mon Oct 27 11:06:11 2008 us=240051 UDPv4 READ [114] from 89.252.92.110:1194: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100

Делал по http://openvpn.net/index.php/documentation/howto.html#quick
Прошу помощи!

Содержание
Сообщения в этом обсуждении
"Openvpn между Debian и Freebsd!"
Отправлено kert84 , 28-Окт-08 14:01 
VPN установился! Обе машины пингуют себя по айпишнику! Клиент пингует внутренню сетевуху сервера. Делаю пинг внутренне сети котороя находится за сервером, пинг не проходит. Tcpdump видно что echo request туда идёт а назад ответа нет, как будто назад пакет не знает куда лететь!
netstat -rn на сервере
10.8/24            10.8.0.2           UGSc        0       36   tun1
10.8.0.2           10.8.0.1           UH          2        2   tun1

Как я понимаю маршруты прописаны.

В настройках VPN указано, что адреса должны быть вида 10.8.0.X 255.255.255.0, а через ifconfig видно 10.8.0.X 255.255.255.255(Может здесь проблема?)
Опять прошу помощи!)

"траблшутинг роутинга сетьтинга в нетворькинге"
Отправлено Andrey Mitrofanov , 28-Окт-08 15:02 
>Делаю пинг внутренне сети котороя находится за сервером, пинг не проходит.
>Tcpdump видно что echo request туда идёт а назад ответа нет,
>как будто назад пакет не знает куда лететь!

Пакет, он маааленькиий. "Знать" ничего не обязан.

"Занать, куда лететь" прописывается в таблицах маршрутизации (и, в более "других" случаях, правилах NAT-а/маскарада) _обоих_ хостов, участвующих в обмене и _всех_ роутеров по пути следования.

Думайте.

"траблшутинг роутинга сетьтинга в нетворькинге"
Отправлено kert84 , 30-Окт-08 11:01 
Смотрите я делаю пинг с машины 10.8.0.6 машины 192.168.0.3 которя находится за vpn server 10.8.0.1!
На сервере есть маршруты:
10.8/24            10.8.0.2           UGSc        0        6   tun1
10.8.0.2           10.8.0.1           UH          2        0   tun1
Пинг приходит на 10.8.0.1 летит через сетевуху которая смотрит в локальную сеть:
А назад не летит! Разве при наличии таких маршрутов он не должен знать куда лететь? Ил необходимо настроить нат для пакетов из впн влетающих через локальную сетевуху?
"траблшутинг роутинга сетьтинга в нетворькинге"
Отправлено DogEater , 31-Окт-08 09:45 
>
>А назад не летит! Разве при наличии таких маршрутов он не должен
>знать куда лететь? Ил необходимо настроить нат для пакетов из впн
>влетающих через локальную сетевуху?

В таких случаях полезно представить себя сетевым пакетом, например пакетом icmp. Пройдите по всему маршруту, рассмотрите таблицы маршрутизации. каждый узел лил должен передать вас напрямую, или знать маршрут до целевой сети/хоста или послать вас по умолчанию.
Если вы так доберётесь до конечной точки - значит надо смотреть правила брандмауэра.
Это не шутка, это совет.