Я запускаю сервер OpenVPN на виртуальной машине Debian.
OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 9 2010
Originally developed by James Yonan
Copyright (C) 2002-2009 OpenVPN Technologies, Inc. <sales@openvpn.net>
Недавно я перешел с протокола TCP на UDP. Мне пришлось использовать TCP, поскольку это был единственный протокол, который не был заблокирован в сети, в которой я использовал свой VPN. Однако я больше не буду использовать эту сеть, и UDP должен быть разрешен во всех сетях, в которых я сейчас буду использовать VPN.
Однако недавно я начал замечать случайные отключения на VPN-клиентах (как на Mac, так и на Windows 7). Иногда мне удается оставаться на связи более часа, иногда всего пару минут. Кроме того, попытки повторного подключения редко срабатывают, и мне нужно перезагрузить или перезапустить службу VPN, чтобы она заработала.
Вот что находится в журнале сервера:
Sun Jul 25 12:54:29 2010 us=83586 vpn.rootspirit.com/85.234.196.37:59101 PUSH: Received control message: 'PUSH_REQUEST'
Sun Jul 25 12:54:29 2010 us=83660 vpn.rootspirit.com/85.234.196.37:59101 SENT CONTROL [vpn.rootspirit.com]: 'PUSH_REPLY,route 85.12.6.190 255.255.255.0,dhcp-option DOMAIN vpn.tuinslak.org,dhcp-option DNS 10.19.88.1,dhcp-option DNS 85.12.6.171,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,dhcp-option NTP 85.12.6.130,redirect-gateway def1,route 10.19.88.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.19.88.6 10.19.88.5' (status=1)
Sun Jul 25 13:49:23 2010 us=593925 MULTI: multi_create_instance called
Sun Jul 25 13:49:23 2010 us=593996 85.234.196.37:63398 Re-using SSL/TLS context
Sun Jul 25 13:49:23 2010 us=594028 85.234.196.37:63398 LZO compression initialized
Sun Jul 25 13:49:23 2010 us=594125 85.234.196.37:63398 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sun Jul 25 13:49:23 2010 us=594140 85.234.196.37:63398 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Jul 25 13:49:23 2010 us=594175 85.234.196.37:63398 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher DES-EDE3-CBC,auth SHA1,keysize 192,tls-auth,key-method 2,tls-server'
Sun Jul 25 13:49:23 2010 us=594188 85.234.196.37:63398 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher DES-EDE3-CBC,auth SHA1,keysize 192,tls-auth,key-method 2,tls-client'
Sun Jul 25 13:49:23 2010 us=594206 85.234.196.37:63398 Local Options hash (VER=V4): 'b5edb94e'
Sun Jul 25 13:49:23 2010 us=594222 85.234.196.37:63398 Expected Remote Options hash (VER=V4): '53f7fc82'
Sun Jul 25 13:49:23 2010 us=594255 85.234.196.37:63398 TLS: Initial packet from 85.234.196.37:63398, sid=ad75fbfb 003c5c1f
Sun Jul 25 13:50:23 2010 us=47907 85.234.196.37:63398 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jul 25 13:50:23 2010 us=47956 85.234.196.37:63398 TLS Error: TLS handshake failed
Sun Jul 25 13:50:23 2010 us=48048 85.234.196.37:63398 SIGUSR1[soft,tls-error] received, client-instance restarting
Sun Jul 25 13:53:09 2010 us=208133 vpn.rootspirit.com/85.234.196.37:59101 [vpn.rootspirit.com] Inactivity timeout (--ping-restart), restarting
Sun Jul 25 13:53:09 2010 us=208192 vpn.rootspirit.com/85.234.196.37:59101 SIGUSR1[soft,ping-restart] received, client-instance restarting
Кажется, что все приводит к тайм-ауту ping или нарушению интернет-соединения. Однако другие компьютеры в этой сети остаются подключенными к Интернету нормально. Так что я не думаю, что обрывается мое vDSL-соединение. То же самое для потери пакетов на сервер; потеря близка к 0%.
Keep alive настроен на следующее:
keepalive 10 120
Есть идеи, что может вызвать эту проблему?
С уважением, Туинслак
Я давно не использовал VPN - по указанной выше причине.
Однако недавно я снова использовал его, и он больше не отключается. Я предполагаю, что это была ошибка, где-то исправленная при обновлении программного обеспечения. Некоторое время назад я также перешел с Lenny на Squeeze.
У меня было подобное поведение, когда у меня было несколько клиентов с одним и тем же сертификатом или сертификатами с одинаковым общим именем, пока duplicate-cn настройка не была включена. Устранение любой из этих причин сделало соединение стабильным.
Информация из конфигурации сервера OpenVPN:
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE "COMMON NAME",
# UNCOMMENT THIS LINE OUT.
;duplicate-cn