Se déconnecter du serveur OpenVPN chaque heure

J'ai un problème assez étrange avec ma OpenVPNconfiguration. Je me connecte Windows 7avec le dernier OpenVPNclient officiel à mon OpenVPNserveur ( OpenVPN 2.1.4 i386-redhat-linux-gnu).

Le problème est que je me déconnecte de mon OpenVPNserveur exactement après 1 heure et je ne comprends pas quelle directive / option est responsable de cela. C'est peut-être un problème client? J'ai essayé différents Windowssystèmes et Windows VPNclients. Les Linuxclients fonctionnent comme prévu sans déconnexion.

Pourriez-vous s'il vous plaît m'aider à résoudre ce problème? J'ai essayé de lire des livres et googler et certaines personnes conseillent de jouer avec keepaliveet reneg-secdirectives. Mais cela ne semble pas aider.

Configuration du serveur 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"

Journal du serveur (le problème n'est-il pas dans 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

Journal client

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

Merci beaucoup.

Le coupable semble être votre configuration d'authentification. Vous utilisez plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so logince qui obligerait le client à fournir une combinaison nom d'utilisateur / mot de passe valide pour se connecter. Apparemment, cela est également requis lors de la nouvelle saisie et votre client OpenVPN semble incapable de demander le nom d'utilisateur à stdin( ERROR: could not read Auth username from stdin).

Quant à la raison pour laquelle l'augmentation de reneg-sec dans la configuration de votre serveur n'aide pas les choses, c'est parce que le paramètre doit être spécifié dans les deux - la configuration du serveur et du client doit être effectivement élevée au-dessus de la valeur par défaut de 3600 secondes (ce qui arrive à cause une heure - déconnectez vous voyez).

Donc, vos options seraient de

• utiliser une méthode d'authentification qui ne nécessite pas de saisie par l'utilisateur (les certificats me viennent à l'esprit)
• dépanner pourquoi votre client ne peut pas demander la combinaison nom d'utilisateur / mot de passe après l'établissement de la connexion
• augmenter la période de recomposition ou désactiver complètement la recomposition (ce qui affaiblit la sécurité de votre connexion, donc ce n'est sûrement qu'une solution de contournement inférieure à votre problème)

vous pouvez essayer reneg-sec 0dans votre server.conf:

https://duo.com/docs/openvpn

https://tldrify.com/m80

c'est assez simple vraiment. Étant donné qu'OpenVPN essaie de renégocier une nouvelle session TLS toutes les 3600 secondes par défaut, vous devrez vous ré-authentifier à chaque fois, en utilisant un nouveau OTP. Pour éviter ce genre de comportement, il s'agit simplement de dire à openvpn de ne jamais renégocier une session TLS et de maintenir celle existante, si vous combinez la keepalivedirective et reneg-sec 0, vous allez avoir une connexion stable, sans aucune renégociation.

J'ai connu un effet similaire lorsque j'ai ajouté l'option 'auth-nocache' à ma configuration client. J'utilise des certificats ET une combinaison nom d'utilisateur + mot de passe pour m'authentifier.

Quelques fois, j'ai remarqué dans les journaux de connexion que openvpn a signalé l'avertissement suivant:

AVERTISSEMENT: cette configuration peut mettre en cache les mots de passe en mémoire - utilisez l'option auth-nocache pour éviter cela

J'ai donc pensé ajouter cette option et voir ce qui se passe. Eh bien, l'avertissement ci-dessus disparaît, mais après une heure, une boîte de dialogue est apparue, me demandant mon nom d'utilisateur et mon mot de passe.

J'ai remarqué que la configuration ci-dessus d'Andrew ne contient pas cette option, donc je suis un peu perplexe quant à la raison pour laquelle elle ne met pas en cache le mot de passe. C'est peut-être parce que j'utilise une version plus récente d'openvpn ou peut-être qu'elle peut être définie sur la configuration du serveur pour pousser cette option vers le client.

Cela a été vu sur: OpenVPN 2.2.1-8 + deb7u2 avec OpenVPN GUI v5 pour Windows.