Desconectarse del servidor OpenVPN cada hora

Tengo un problema bastante extraño con mi OpenVPNconfiguración. Me estoy conectando Windows 7con el último OpenVPNcliente oficial a mi OpenVPNservidor ( OpenVPN 2.1.4 i386-redhat-linux-gnu).

El problema es que me desconecto de mi OpenVPNservidor exactamente después de 1 hora y no puedo entender qué directiva / opción es responsable de esto. Tal vez es un problema del cliente? He probado diferentes Windowssistemas y Windows VPNclientes. Los Linuxclientes están trabajando como se espera sin desconexiones.

¿Podrías ayudarme a solucionar este problema? He intentado leer libros y buscar en Google y algunas personas me aconsejan jugar keepalivey reneg-secdirectivas. Pero eso no parece ayudar.

Configuración del servidor OpenVPN

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.0.0.0 255.0.0.0"
client-config-dir ccd
route 192.168.51.0 255.255.255.0
keepalive 60 600
reneg-sec 5000
hand-window 15
tls-auth ta.key 0
comp-lzo
max-clients 50
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem
management localhost 11111
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option DOMAIN example.com"
push "dhcp-option SEARCH example.com"

Registro del servidor (¿no es el problema en reinit_src = 1?)

Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:23:38 vpn openvpn[19495]: user/192.168.253.20:54568 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Oct  9 07:24:53 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS key negotiation failed to occur within 15 seconds (check your network connectivity)
Oct  9 07:26:08 vpn openvpn[19495]: user/192.168.253.20:54568 TLS Error: TLS handshake failed
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 [UNDEF] Inactivity timeout (--ping-restart), restarting
Oct  9 07:26:39 vpn openvpn[19495]: user/192.168.253.20:54568 SIGUSR1[soft,ping-restart] received, client-instance restarting

Registro del cliente

RwrWRwRwRwRwTue Oct 09 07:26:39 2012 us=796000 TLS: soft reset sec=0 bytes=7405621/0 pkts=9459/0
Tue Oct 09 07:26:39 2012 us=600000 ERROR: could not read Auth username from stdin
Tue Oct 09 07:26:39 2012 us=600000 Exiting
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 192.168.2.1 MASK 255.255.255.255 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 C:\WINDOWS\system32\route.exe DELETE 10.0.0.0 MASK 255.0.0.0 192.168.100.150
Tue Oct 09 07:26:39 2012 us=600000 Route deletion via IPAPI succeeded [adaptive]
Tue Oct 09 07:26:39 2012 us=600000 Closing TUN/TAP interface

Muchas gracias.

El culpable parece ser su configuración de autenticación. Está utilizando plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so loginlo que requeriría que el cliente proporcione una combinación válida de nombre de usuario / contraseña para conectarse. Aparentemente, esto también se requiere al volver a escribir y su cliente OpenVPN parece incapaz de solicitar el nombre de usuario de stdin( ERROR: could not read Auth username from stdin).

En cuanto a la razón por la cual no es importante elevar reneg-sec en la configuración de su servidor, esto se debe a que el parámetro debe especificarse en ambos: la configuración del servidor y del cliente debe elevarse efectivamente por encima del valor predeterminado de 3600 segundos (lo que sucede con causa la hora - desconecta que estás viendo).

Entonces sus opciones serían

• use un método de autenticación que no requiera la entrada del usuario (los certificados vienen a la mente)
• Solucionar por qué su cliente no puede solicitar la combinación de nombre de usuario / contraseña después del establecimiento de la conexión
• aumente el período de reescritura o deshabilite la reescritura por completo (lo que debilita la seguridad de su conexión, por lo que seguramente solo es una solución inferior a su problema)

puedes intentarlo reneg-sec 0en tu server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

Es bastante simple en realidad. Dado que OpenVPN intenta renegociar una nueva sesión de TLS cada 3600 segundos de forma predeterminada, deberá volver a autenticarse cada vez, utilizando una nueva OTP. Para evitar este tipo de comportamiento, solo es cuestión de decirle a openvpn que nunca renegocie una sesión TLS y mantenga viva la existente, si combina la keepalivedirectiva y reneg-sec 0, tendrá una conexión estable, sin renegociación alguna.

Experimenté un efecto similar cuando agregué la opción 'auth-nocache' a la configuración de mi cliente. Utilizo certificados Y una combinación de nombre de usuario + contraseña para autenticar.

Algunas veces noté en los registros de conexión que openvpn informó la siguiente advertencia:

ADVERTENCIA: esta configuración puede almacenar en caché las contraseñas en la memoria; use la opción auth-nocache para evitar esto

Así que pensé agregar esta opción y ver qué pasa. Bueno, la advertencia anterior desaparece, pero después de una hora apareció un cuadro de diálogo pidiéndome mi nombre de usuario y contraseña.

Noté que la configuración anterior de Andrew no contiene esta opción, así que estoy un poco desconcertado sobre por qué no almacena en caché la contraseña. Tal vez esto se deba a que estoy usando una versión más nueva de openvpn o tal vez se pueda configurar en la configuración del servidor para enviar esta opción al cliente.

Esto se vio en: OpenVPN 2.2.1-8 + deb7u2 con OpenVPN GUI v5 para Windows.