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

16

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)
openvpn Kyle
la source
1
Votre client ne reçoit jamais du tout de réponse du serveur. Soit vous avez un pare-feu que vous avez oublié, soit votre redirection de port ne fonctionne pas.
Michael Hampton
2
Faites un paquet sniff, comme: tcpdump -ni eth0 udp and port 1194 sur le serveur et assurez-vous que les paquets arrivent. S'ils le sont, il peut y avoir un problème avec la suppression de paquets par le pare-feu, sinon, il y a très probablement un problème avec la redirection de port sur le routeur. Vous pouvez également le faire sur le routeur. Essayez-le et essayez d'utiliser un port plus élevé, ce n'est pas courant, mais votre FAI a peut-être foiré quelque chose, comme le port 11194 / UDP ou 53 / UDP.
Michal Sokolowski
Oui, c'était l'expédition. Je ne travaille généralement pas avec UDP, j'ai donc oublié de changer le protocole lors de la création de la règle. Je posterai cela comme réponse.
Kyle
3
Si les paquets apparaissent dans tcpdump sur le serveur, existe-t-il un moyen de s'assurer qu'ils arrivent correctement à openvpn?
Joost

Réponses:

9

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: entrez la description de l'image ici

Crédits à ce post

FelikZ
la source
J'ai également eu ce problème avec un appareil pfsense. L'ajout de l' local <ip address of VPN server>entrée dans la configuration du serveur l'a corrigé. Notez que pour TCP cette entrée n'était pas nécessaire, c'était seulement UDP pour donner l'erreur.
Vincenzo Pii
5

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.

Kyle
la source
0

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
Djanym
la source
0

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.

lanoxx
la source
Vous rappelez-vous où vous avez dû changer cela? C'était dedans etc/openvpn/server.conf?
Arthur Attout
Je pense que quelque chose n'allait pas avec les tables de routage côté serveur. Vérifiez avec ip route.
lanoxx
0

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é.

Kyn
la source