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

OpenVPN: соединение есть, ping-и не идут

 ,


2

1

Есть сеть 192.168.5.0/24 и маршрутизатор с openwrt (192.168.5.1) и установленым openvpn. Так же в этой сети есть компьютер с Debian и openvpn. Конфиг /etc/config/openvpn из маршрутизатора:

package openvpn

...

config openvpn sample_server

	option enabled 1

	option port 1194

	# TCP or UDP server?
#	option proto tcp
	option proto udp

	option dev tap

	option ca /etc/openvpn/ca.crt
	option cert /etc/openvpn/openwrt-dinoasm.crt

	option key /etc/openvpn/openwrt-dinoasm.key

	option dh /etc/openvpn/dh1024.pem

	option ifconfig_pool_persist /tmp/ipp.txt

	option server_bridge "10.8.0.1 255.255.255.0 10.8.0.2 10.8.0.254"

#	list push "route 192.168.5.0 255.255.255.0"
#	list push "route 192.168.20.0 255.255.255.0"

	option client_to_client 1

	option keepalive "10 120"

	option comp_lzo 1

	option persist_key 1
	option persist_tun 1

	option status /tmp/openvpn-status.log

	option verb 3

/etc/openvpn/client.conf из компьютера с Debian:

client

dev tap
proto udp

remote 192.168.5.1 1194
remote-cert-tls server

nobind

persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/comp.crt
key /etc/openvpn/comp.key

verb 3

В логах ошибок нету, клиент вроде соединяется, но ping-и не идут. Что я упустил?



Последнее исправление: DinoAsm (всего исправлений: 1)

Что значит «вроде соединяется»? tap интерфейс появляется, ip-адрес на него назначается? Маршрут появляется? На какой адрес пытаетесь отправлять пинги?

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

Tap интерфейс появляется, ip на сервере (маршрутизаторе) назначал вручную, ping с маршрутизатора на 10.8.0.2 (который назначается клиенту и виден в его выводе ifconfig) не идет, с клиента на 10.8.0.1 тоже.

Вывод клиентского openvpn:

# openvpn /etc/openvpn/client.conf 
Sat Jun 15 21:30:37 2013 OpenVPN 2.2.1 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 23 2012
Sat Jun 15 21:30:37 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Sat Jun 15 21:30:37 2013 WARNING: file '/etc/openvpn/comp.key' is group or others accessible
Sat Jun 15 21:30:37 2013 Control Channel MTU parms [ L:1575 D:140 EF:40 EB:0 ET:0 EL:0 ]
Sat Jun 15 21:30:37 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Sat Jun 15 21:30:37 2013 Data Channel MTU parms [ L:1575 D:1450 EF:43 EB:4 ET:32 EL:0 ]
Sat Jun 15 21:30:37 2013 Local Options hash (VER=V4): '10f35004'
Sat Jun 15 21:30:37 2013 Expected Remote Options hash (VER=V4): 'a917298a'
Sat Jun 15 21:30:37 2013 Attempting to establish TCP connection with [AF_INET]192.168.5.1:1194 [nonblock]
Sat Jun 15 21:30:38 2013 TCP connection established with [AF_INET]192.168.5.1:1194
Sat Jun 15 21:30:38 2013 TCPv4_CLIENT link local: [undef]
Sat Jun 15 21:30:38 2013 TCPv4_CLIENT link remote: [AF_INET]192.168.5.1:1194
Sat Jun 15 21:30:38 2013 TLS: Initial packet from [AF_INET]192.168.5.1:1194, sid=34842f18 7f7788da
Sat Jun 15 21:30:38 2013 VERIFY OK: depth=1, ***
Sat Jun 15 21:30:38 2013 Validating certificate key usage
Sat Jun 15 21:30:38 2013 ++ Certificate has key usage  00a0, expects 00a0
Sat Jun 15 21:30:38 2013 VERIFY KU OK
Sat Jun 15 21:30:38 2013 Validating certificate extended key usage
Sat Jun 15 21:30:38 2013 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Jun 15 21:30:38 2013 VERIFY EKU OK
Sat Jun 15 21:30:38 2013 VERIFY OK: depth=0, ***
Sat Jun 15 21:30:38 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jun 15 21:30:38 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jun 15 21:30:38 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jun 15 21:30:38 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jun 15 21:30:38 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jun 15 21:30:38 2013 [openwrt-dinoasm] Peer Connection Initiated with [AF_INET]192.168.5.1:1194
Sat Jun 15 21:30:41 2013 SENT CONTROL [openwrt-dinoasm]: 'PUSH_REQUEST' (status=1)
Sat Jun 15 21:30:41 2013 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0'
Sat Jun 15 21:30:41 2013 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jun 15 21:30:41 2013 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jun 15 21:30:41 2013 OPTIONS IMPORT: route-related options modified
Sat Jun 15 21:30:41 2013 TUN/TAP device tap0 opened
Sat Jun 15 21:30:41 2013 TUN/TAP TX queue length set to 100
Sat Jun 15 21:30:41 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Jun 15 21:30:41 2013 /sbin/ifconfig tap0 10.8.0.2 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Sat Jun 15 21:30:41 2013 Initialization Sequence Completed

ip route на клиенте:

# ip route
default via 192.168.5.2 dev br0 
10.8.0.0/24 dev tap0  proto kernel  scope link  src 10.8.0.2 
169.254.0.0/16 dev br0  scope link  metric 1000 
192.168.5.0/24 dev br0  proto kernel  scope link  src 192.168.5.3 

ip route на сервере:

# ip route 
default via 192.168.5.2 dev br-lan  proto static 
10.8.0.0/24 dev tap0  proto kernel  scope link  src 10.8.0.1 

ip addr list dev tap0 на сервере:

# ip addr list dev tap0
8: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-lan state UNKNOWN qlen 100
    link/ether ca:87:68:9d:01:b7 brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope link tap0

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

Периодически на клиенте выскакивает такое:

Sat Jun 15 21:55:27 2013 Connection reset, restarting [0]
Sat Jun 15 21:55:27 2013 TCP/UDP: Closing socket
Sat Jun 15 21:55:27 2013 SIGUSR1[soft,connection-reset] received, process restarting
Sat Jun 15 21:55:27 2013 Restart pause, 5 second(s)

C proto udp писало что-то вроде Connection timeout.

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

Через него. Пробовал еще nmap-ом сканить, тоже ничего.

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

Попробуйте сначала добится работы не с tap, а с tun.

В вашем случае, когда у вас клиент и сервер связаны и ethernet и tap-тунелем, может быть путаница с arp-записями, так как linux по умолчанию отвечает на все arp-запросы, независимо от интерфейса, откуда они пришли.

Научитесь пользоватся tcpdump или wireshark. Запускаете его на клиенте и сервере, запускаете на eth0 на перехват arp и udp-пакетов, запускаете на tap0 (tun0) и пингуете. Сразу будет видно, уходят ли пакеты в тунель или пытаются идти по ethernet, доходят ли по тунелю до сервера и т.д.

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

Запустил tcpdump на прослушку tap0 на клиенте и сервере. Видны запросы arp, ответов нету. На клиент приходят непонятные, явно битые пакеты по 43 или 17 байт.

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

arp-запросы видны в tcpdump'е и на клиенте и на сервере?

Эти, явно битые пакеты, видны в tcpdump'е на сервере или там вобще ничего в сторону клиента не отправляется?

mky ★★★★★
()

ip_forward разумеется включен?

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

Arp-запросы с клиента видны только на клиенте. Arp-запросы с сервера видны только на сервере. После смены типа соединения на tun пакеты перестали приходить вообще, кроме, конечно же, отправленых с прослушиваемого интерфейса. На клиенте

$ ip addr show dev tun0
17: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0
На сервере
# ip addr show dev tun0
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun0
что станно. После замены peer на 10.8.0.1/32 на клиенте и на 10.8.0.6 на сервере ничего не изменилось. ip_forward на маршрутизаторе включен. Процесор явно не перегружен и оперативки хватает, судя по выводу free:
# free
             total         used         free       shared      buffers
Mem:         29344        23736         5608            0         1896
-/+ buffers:              21840         7504
Swap:       500152         2788       497364

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

что станно.

Это как раз нормально. IP-адреса на tun0 интерфейсах менять не надо. На клиенте должен быть маршрут:

10.8.0.0/24 via 10.8.0.5 dev tun0

на сервере аналогичный маршрут через 10.8.0.2.

С клиента нужно пинговать 10.8.0.1, с сервера 10.8.0.6

Попробуйте убрать на сервере ″comp_lzo″ или добавить ″push comp_lzo 1″.

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

Ура, пинги пошли! Спасибо. А что изменилось? Разве может быть такое, что сервер использует сжатие, а клиент об этом не знает и не распаковывает пакеты?

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

Разве может быть такое, что сервер использует сжатие, а клиент об этом не знает и не распаковывает пакеты?

Да, причём, бывает хуже, если я правильно понял гугль, клиент под макинтош вобще игнорирует эту опцию (push comp_lzo 1), то есть когда на сервере правильно настроено сжатие, у всех работает, а у мака — нет.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.