Estoy configurando OpenVPN 2.3.6-1 en mi servidor Arch Linux para encriptar el tráfico SMB a través de Internet público. Cuando la prueba de la configuración de uno de mis clientes de máquinas virtuales Linux, me sale el error: TLS Error: TLS handshake failed
.
Leí rápidamente ( OpenVPN en OpenVZ Error de TLS: el apretón de manos de TLS falló (las soluciones sugeridas por Google no ayudan) ) e intenté cambiar el UDP predeterminado a TCP, pero eso solo causó que el cliente informara repetidamente que la conexión se había agotado. También intenté deshabilitar el cifrado y la autenticación TLS, pero eso hizo que el servidor fallara Assertion failed at crypto_openssl.c:523
. En ambos casos, los cambios requeridos se realizaron en las configuraciones del cliente y del servidor.
He estado siguiendo las instrucciones en ( https://wiki.archlinux.org/index.php/OpenVPN ) para configurar OpenVPN y las instrucciones en ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ) para crear las claves y los certificados. Las únicas desviaciones que he hecho de estas instrucciones han sido especificar los nombres de mis propias computadoras y sus correspondientes nombres de archivo de clave / certificado.
Consulte también mi pregunta original sobre cómo proteger el tráfico de SMB a través de Internet: ( Cifrado simple para recursos compartidos de Samba )
¿Alguien puede explicar cómo puedo resolver este problema?
Detalles:
Servidor: Arch Linux (actualizado) conectado directamente a la puerta de enlace a través de un cable ethernet. No iptables.
Cliente: máquina virtual Arch Linux (actualizada) en VirtualBox 4.3.28r100309 Windows 8.1 host, adaptador de red en puente. No iptables. Firewall de Windows deshabilitado.
Gateway: reenvío de puertos para el puerto 1194 habilitado, sin restricciones de firewall.
Aquí están los archivos de configuración en el servidor y el cliente, respectivamente. Los creé de acuerdo con las instrucciones en Arch Wiki.
/etc/openvpn/server.conf
(Solo líneas sin comentarios):
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
(Solo líneas sin comentarios):
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
Aquí están los resultados de ejecutar openvpn en las máquinas con las configuraciones anteriores. Primero inicié el servidor, luego el cliente.
La salida de openvpn /etc/openvpn/server.conf
en el servidor:
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 salida de openvpn /etc/openvpn/client.conf
en el cliente:
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)
tcpdump -ni eth0 udp and port 1194
en el servidor y asegurarse de si los paquetes están llegando. Si están allí puede haber un problema con los paquetes de caída de firewall, si no lo más probable es que hay algún problema con el reenvío de puertos en el router. También puede hacerlo en el enrutador. Intente usar un puerto más alto, no es común, pero tal vez su ISP haya estropeado algo, como el puerto 11194 / UDP o 53 / UDP.