Estou executando um servidor OpenVPN em uma máquina virtual 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. <[email protected]>
Eu mudei recentemente do protocolo TCP para UDP. Eu tive que usar o TCP como este foi o único protocolo que não foi bloqueado na rede que usei minha VPN. No entanto, não vou mais usar essa rede, e o UDP deve ser permitido em todas as redes em que eu vou usar a VPN agora.
No entanto, comecei recentemente a notar desconexões aleatórias nos clientes VPN (tanto no Mac quanto no Windows 7). Às vezes consigo ficar ligado por mais de uma hora, às vezes apenas alguns minutos. Também tentar se reconectar raramente funciona e eu preciso recarregar ou reiniciar o serviço VPN para que ele funcione.
Isso é o que está no log do servidor:
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
Tudo parece levar a um tempo limite de ping ou a uma conexão de internet desfeita. No entanto, outros PCs aqui nesta rede permanecem conectados à internet muito bem. Então eu não acho que é a minha conexão vDSL que está caindo. O mesmo para a perda de pacotes para o servidor; perto de 0% de perda.
Keep alive está definido para isto:
keepalive 10 120
Alguma ideia do que pode causar este problema?
Atenciosamente, Tuinslak
Eu não usei a VPN por um tempo - por causa da razão mencionada acima.
No entanto, recentemente usei-o novamente e ele não parece mais desconectado. Eu estou supondo que foi um bug em algum lugar corrigido ao atualizar o software. Eu também atualizei de Lenny para Squeeze um tempo atrás.
Eu tive um comportamento semelhante quando por acaso eu tinha vários clientes com o mesmo certificado ou certificados com o mesmo nome comum, enquanto a configuração duplicate-cn não estava ativada. Resolver qualquer uma dessas causas tornou a conexão estável.
Informação da configuração do servidor 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
Tags openvpn