Problème OpenVPN - La négociation de la clé TLS n'a pas pu se produire dans les 60 secondes
Je configure un serveur OpenVPN (version 2.3.10) sur un serveur Windows 2012 mais je ne peux pas le faire fonctionner.
Le serveur est derrière un routeur et j'ai ouvert le port 1194 et créé une règle pour transférer le trafic sur ce port vers le serveur.
Voici le journal que je vois sur le serveur lorsque j'essaie de me connecter à partir d'un client:
Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting
Où XX.XX.XX.XX est l'IP du client. Je comprends donc que le client est au moins en mesure d'arriver au serveur, donc il n'y a pas de problèmes de routage ou de pare-feu.
J'ai suivi la description fournie ici. Guide Windows simple Des idées?
Ce qui est intéressant, c'est comment le numéro de port change en cours de route:
21 mars 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: paquet initial de [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3
21 mars 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: paquet initial de [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525
Cela me fait penser que, quelque part entre le client et le serveur, il y a un mauvais comportement NAT périphérique, un périphérique avec des entrées de table d'état de très courte durée, qui modifie le numéro de port source auquel il s'applique le flux établi du client, ce qui fait penser au serveur que deux communications de courte durée sont en cours, au lieu d'une continue.
De tels périphériques ne le font généralement qu'avec UDP, je vous ai donc conseillé de confirmer que vous utilisez UDP et d'essayer TCP à la place. C'est ce que vous avez fait et vous avez constaté qu'il résout le problème. Le l'étape suivante consiste à identifier le mauvais comportement NAT périphérique, frappez-le avec un marteau club et remplacez-le par un qui ne commet pas l'erreur cardinale de supposer que toutes les communications UDP sont éphémères; mais vous ont indiqué que vous êtes satisfait de passer à TCP comme solution de contournement, et le problème est donc conclu.
C'est l'une des erreurs les plus courantes dans la configuration d'Openvpn et il y a une entrée FAQ pour cela. Je vais citer ceci ici:
Erreur TLS: la négociation de la clé TLS n'a pas pu se produire dans les 60 secondes (vérifiez votre connectivité réseau)
L'un des problèmes les plus courants lors de la configuration d'OpenVPN est que les deux démons OpenVPN de chaque côté de la connexion sont incapables d'établir une connexion TCP ou UDP entre eux).
Ceci est presque le résultat de:
- Un pare-feu de périmètre sur le réseau du serveur filtre les paquets OpenVPN entrants (par défaut, OpenVPN utilise UDP ou TCP numéro de port 1194).
- Un pare-feu logiciel s'exécutant sur la machine serveur OpenVPN elle-même filtre les connexions entrantes sur le port 1194. Sachez que de nombreux systèmes d'exploitation bloqueront les connexions entrantes par défaut, sauf configuration contraire.
- Une passerelle NAT sur le réseau du serveur n'a pas de règle de transfert de port pour TCP/UDP 1194 vers l'adresse interne de la machine serveur OpenVPN.
- La configuration du client OpenVPN n'a pas l'adresse de serveur correcte dans son fichier de configuration. La directive distante dans le fichier de configuration client doit pointer soit vers le serveur lui-même, soit vers l'adresse IP publique de la passerelle du réseau de serveurs.
- Une autre cause possible est que le pare-feu Windows bloque l'accès au binaire openvpn.exe. Vous devrez peut-être la mettre sur liste blanche (l'ajouter à la liste "Exceptions") pour qu'OpenVPN fonctionne.
Il est fort probable que l'un de ces problèmes provoque également le même problème dans votre cas. Il suffit donc de parcourir la liste une par une pour la résoudre.
J'obtenais des délais d'expiration de négociation TLS comme celui-ci. Mais dans mon cas, j'ai réalisé que la liaison distante était une adresse IP locale.
Le VPN sur notre pare-feu pfSense a été par erreur placé sur l'interface LAN au lieu de l'interface WAN, et donc la configuration exportée a été définie pour essayer de se connecter à l'adresse IP LAN du pare-feu - qui n'a jamais été va travailler avec le client étant naturellement sur un LAN différent.
Je pense que les principaux enseignements à en tirer sont les suivants:
L'obtention d'un délai de négociation clé ne signifie pas nécessairement que vous avez même réussi à vous connecter à quoi que ce soit.
À ce stade, il peut donc être utile de vérifier que vous vous connectez réellement au bon endroit et qu'aucune règle de pare-feu ne bloque la connexion, etc. Surtout si votre configuration a été générée automatiquement.
Notez que l'obtention d'une invite de connexion ne signifie pas que vous êtes connecté , car OpenVPN vous demande vos informations d'identification avant d'essayer de vous connecter.
Assurez-vous que votre serveur VPN écoute sur la bonne interface.
(Bien sûr, il s'agit d'une des nombreuses erreurs de configuration côté serveur susceptibles de se produire, telles que les règles de pare-feu, la mise en place du mauvais numéro de port, le mélange TCP et UDP, etc.)
Aucune des solutions mentionnées précédemment n'a fonctionné. Dans mon cas, même si le journal client a montré la même erreur TLS Error: TLS key negotiation failed to occur within 60 seconds, les journaux du serveur indiquaient VERIFY ERROR: depth=0, error=CRL has expired.
Sur le serveur, les étapes suivantes ont résolu le problème de connexion:
# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn
Notez que vous pouvez obtenir une erreur de négociation de clé TLS, sans vous connecter avec succès au serveur OpenVPN - ou même avec succès vous connecter à quoi que ce soit!
J'ai modifié une configuration VPN pour me connecter à localhost, sur un port qui n'écoutait rien:
OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] construit le 26 avril 2018 Windows version 6.2 (Windows 8 ou supérieur) ) Versions de la bibliothèque 64 bits : OpenSSL 1.1.0h 27 mars 2018, LZO 2.10 TCP/UDP: Préserver l'adresse distante récemment utilisée: [AF_INET] 127.0.0.1:12345 Lien UDP local (lié): [AF_INET] [undef]: 0 Télécommande de liaison UDP: [AF_INET] 127.0.0.1:12345Erreur TLS: la négociation de la clé TLS n'a pas pu se produire dans les 60 secondes (vérifiez votre connectivité réseau) Erreur TLS: échec de l'établissement de liaison TLS SIGUSR1 [soft, tls-error] reçu, processus redémarrant ...
L'erreur peut vous endormir dans un faux sens que vous parlez à un serveur VPN.
Vous pouvez même être invité à fournir des informations d'identification en premier, mais rien en dehors de votre ordinateur ne les a réellement demandées.
J'ai eu la même erreur et aucun conseil n'a aidé, tout semblait aller bien: adresses IP, ports, pare-feu, tout. Est devenu fou pendant 2 heures.
La solution était de changer le protocole d'UDP en TCP dans la configuration client (apparemment j'ai désactivé UDP exprès il y a longtemps)).
J'espère que cela aide quelqu'un :)
LE: cela a résolu mon problème mais ce n'est pas la meilleure approche selon les commentaires ci-dessous. Vous devez utiliser UDP au lieu de TCP. Cela m'a aidé car j'avais des paramètres différents entre les configurations client et serveur.
J'ai rencontré cette erreur dans AWS, où OpenVPN a été installé sur un serveur avec une IP publique, mais sur une instance qui se trouvait dans un sous-réseau privé, c'est-à-dire un sous-réseau qui n'avait pas de route vers une passerelle Internet.
Une fois que j'ai déployé OpenVPN sur un serveur dans un sous-réseau public, tout a bien fonctionné :)
Sur les sous-réseaux publics/privés dans AWS: https://docs.aws.Amazon.com/vpc/latest/userguide/VPC_Subnets.html
Une raison possible est que si le serveur requiert une version TLS plus récente, le TLS pris en charge par le client. soit 1,2 vs 1,0.
La chose évidente à essayer est de mettre à jour le client OpenVPN ou de modifier le côté serveur pour accepter TLS 1.0.
Je suis également tombé sur le TLS key negotiation failed to occur within 60 seconds problème.
D'après la suggestion officielle, comme Diamant post, il doit y avoir quelque chose de mal dans la connexion réseau. Cependant, ni le pare-feu ni le NAT ne causent le problème.
Dans mon cas, j'ai d'abord vérifié la connexion par nc -uvz xxx.xxx.xxx.xxx 1194. Le lien est OK.
En outre, plusieurs autres clients VPN dans le même réseau local fonctionnent correctement.
De quelque part, j'ai remarqué que la connexion udp a des problèmes de réponse ou de transfert de port.
J'arrête donc les clients VPN en cours d'exécution de la plus grande IP au client suspendu, par exemple, de "10.8.0.100" à "10.8.0.50".
Ensuite, démarrez les clients vpn arrêtés à l'envers.
Coup! Tous les clients VPN fonctionnent correctement.
En conclusion, il y a une chance de conduire à TLS key negotiation failed to occur within 60 seconds problème que plusieurs clients vpn dans un LAN démarrent dans une mauvaise séquence.