Correction de l'erreur TLS: la négociation TLS a échoué sur le client OpenVPN

Je configure OpenVPN 2.3.6-1 sur mon serveur Arch Linux afin de crypter le trafic SMB sur Internet public. Lorsque je teste la configuration sur un de mes clients de la machine virtuelle Linux, je reçois l'erreur: TLS Error: TLS handshake failed.

J'ai lu rapidement ( OpenVPN sur OpenVZ TLS Erreur: la négociation TLS a échoué (les solutions suggérées par Google n'aidaient pas) ) et j'ai essayé de passer de l'UDP par défaut à TCP, mais cela n'a fait que signaler au client à plusieurs reprises que la connexion a expiré. J'ai également essayé de désactiver le chiffrement et l'authentification TLS, mais cela a entraîné l'échec du serveur Assertion failed at crypto_openssl.c:523. Dans les deux cas, les modifications requises ont été apportées aux configurations client et serveur.

J'ai suivi les instructions sur ( https://wiki.archlinux.org/index.php/OpenVPN ) pour configurer OpenVPN et les instructions sur ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ) pour créer les clés et les certificats. Les seules dérogations que j'ai apportées à ces instructions ont été de spécifier les noms de mes propres ordinateurs et leurs noms de fichiers de clés / certificats correspondants.

Voir aussi ma question d'origine sur la sécurisation du trafic SMB sur Internet: ( Cryptage simple pour les partages Samba )

Quelqu'un peut-il expliquer comment je peux résoudre ce problème?

Détails:

Serveur: Arch Linux (à jour) connecté directement à la passerelle via un câble Ethernet. Pas d'iptables.

Client: machine virtuelle Arch Linux (à jour) sur l'hôte VirtualBox 4.3.28r100309 Windows 8.1, carte réseau pontée. Pas d'iptables. Pare-feu Windows désactivé.

Passerelle: redirection de port pour le port 1194 activée, aucune restriction de pare-feu.

Voici les fichiers de configuration sur le serveur et le client, respectivement. Je les ai créés selon les instructions du Arch Wiki.

/etc/openvpn/server.conf (Lignes sans commentaire uniquement):

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server-name.crt
key /etc/openvpn/server-name.key
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

/etc/openvpn/client.conf (Lignes sans commentaire uniquement):

client
dev tun
proto udp
remote [my public IP here] 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client-name.crt
key /etc/openvpn/client-name.key
remote-cert-tls server
tls-auth /etc/openvpn/ta.key 1
comp-lzo
verb 3

Voici les sorties de l'exécution d'openvpn sur les machines avec les configurations ci-dessus. J'ai démarré le serveur d'abord, puis le client.

La sortie de openvpn /etc/openvpn/server.confsur le serveur:

Thu Jul 30 17:02:53 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 17:02:53 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 17:02:53 2015 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Thu Jul 30 17:02:53 2015 Diffie-Hellman initialized with 2048 bit key
Thu Jul 30 17:02:53 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 17:02:53 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 17:02:53 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 17:02:53 2015 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=enp5s0 HWADDR=##:##:##:##:##:##
Thu Jul 30 17:02:53 2015 TUN/TAP device tun0 opened
Thu Jul 30 17:02:53 2015 TUN/TAP TX queue length set to 100
Thu Jul 30 17:02:53 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 30 17:02:53 2015 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Jul 30 17:02:53 2015 /usr/bin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Thu Jul 30 17:02:53 2015 /usr/bin/ip route add 10.8.0.0/24 via 10.8.0.2
Thu Jul 30 17:02:53 2015 GID set to nobody
Thu Jul 30 17:02:53 2015 UID set to nobody
Thu Jul 30 17:02:53 2015 UDPv4 link local (bound): [undef]
Thu Jul 30 17:02:53 2015 UDPv4 link remote: [undef]
Thu Jul 30 17:02:53 2015 MULTI: multi_init called, r=256 v=256
Thu Jul 30 17:02:53 2015 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Thu Jul 30 17:02:53 2015 IFCONFIG POOL LIST
Thu Jul 30 17:02:53 2015 Initialization Sequence Completed

La sortie de openvpn /etc/openvpn/client.confsur le client:

Thu Jul 30 21:03:02 2015 OpenVPN 2.3.6 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Dec  2 2014
Thu Jul 30 21:03:02 2015 library versions: OpenSSL 1.0.2d 9 Jul 2015, LZO 2.09
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/client-name.key' is group or others accessible
Thu Jul 30 21:03:02 2015 WARNING: file '/etc/openvpn/ta.key' is group or others accessible
Thu Jul 30 21:03:02 2015 Control Channel Authentication: using '/etc/openvpn/ta.key' as a OpenVPN static key file
Thu Jul 30 21:03:02 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Jul 30 21:03:02 2015 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 30 21:03:02 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu Jul 30 21:03:02 2015 UDPv4 link local: [undef]
Thu Jul 30 21:03:02 2015 UDPv4 link remote: [AF_INET][my public IP here]:1194
Thu Jul 30 21:04:02 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 30 21:04:02 2015 TLS Error: TLS handshake failed
Thu Jul 30 21:04:02 2015 SIGUSR1[soft,tls-error] received, process restarting
Thu Jul 30 21:04:02 2015 Restart pause, 2 second(s)

J'ai aussi eu ce problème.

J'utilise le fournisseur digitalocean pour mon serveur et le problème était avec la fonction IP flottante.

Pour résoudre ce problème, vous devez mettre à jour le paramètre de configuration openvpn:

local <ip anchor>

ip anchor doit être une adresse ip collectée à partir de la ip addrcommande, voir l'exemple:

Crédits à ce post

Comme suggéré par Michael Hampton et Michal Sokolowski dans les commentaires sur ma question, c'était un problème avec la règle de redirection de port que j'ai créée sur ma passerelle. OpenVPN est configuré pour utiliser UDP, et j'ai oublié de passer de TCP à UDP sur la passerelle car je n'utilise généralement pas ce protocole. La règle de transfert utilise désormais UDP, et mon VPN est fonctionnel.

S'il apparaît après la mise à jour du noyau du système d'exploitation. Ou les paquets entrants apparaissent dans tcpdump sur le serveur, mais ne fonctionnent toujours pas. Essayez un simple pare-feu désactiver / activer. Peut-être que quelqu'un va aider.

sudo ufw disable
sudo ufw enable

Ma configuration actuelle fonctionnerait sur certains pays mais pas sur d'autres. Je soupçonne que mon fournisseur actuel bloque le paquet de négociation TLS. Solution? Étant donné que je suis le seul à utiliser ce VPN, je suis passé à l'authentification par clé statique qui, dans mon cas, s'est révélée très rapide https://openvpn.net/index.php/open-source/documentation/miscivers/78-static -key-mini-howto.html

J'obtenais ce problème en raison d'une passerelle par défaut mal configurée côté serveur. Le serveur OpenVPN recevait la tentative de connexion du client, mais la réponse était alors perdue car il n'avait jamais atteint le bon routeur.

Je viens d'avoir ce problème. En vérifiant mon fichier .ovpn, j'ai vu que le? .Ddns.net avait été changé en une adresse IP, c'est pourquoi il ne s'est pas connecté. J'ai changé l'IP en adresse? .Ddns.net et je me suis connecté.