Se corrigió 'Error de TLS: error de enlace TLS' en el cliente OpenVPN

16

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.confen 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.confen 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)
openvpn Kyle
fuente
1
Su cliente nunca recibe una respuesta del servidor en absoluto. O tiene un firewall que olvidó o su reenvío de puertos no funciona.
Michael Hampton
2
Hacer una aspiración de paquetes, como: 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.
Michal Sokolowski
Sí, fue el reenvío. Normalmente no trabajo con UDP, así que olvidé cambiar el protocolo al crear la regla. Publicaré eso como la respuesta.
Kyle
3
Si los paquetes aparecen en tcpdump en el servidor, ¿hay alguna manera de asegurarse de que lleguen a openvpn correctamente?
Joost

Respuestas:

9

Yo tuve este problema también.

Estoy usando el proveedor digitalocean para mi servidor y el problema fue con la función de ip flotante.

Para solucionarlo, debe actualizar la configuración de configuración de openvpn:

local <ip anchor>

ip anchor debe ser una dirección ip recopilada del ip addrcomando, ver ejemplo: ingrese la descripción de la imagen aquí

Créditos a esta publicación

FelikZ
fuente
También tuve este problema con un dispositivo pfsense. Agregar la local <ip address of VPN server>entrada en la configuración del servidor lo arregló. Tenga en cuenta que para TCP esta entrada no era necesaria, solo UDP dio el error.
Vincenzo Pii
5

Como sugirieron Michael Hampton y Michal Sokolowski en los comentarios sobre mi pregunta, fue un problema con la regla de reenvío de puertos que creé en mi puerta de enlace. OpenVPN está configurado para usar UDP, y olvidé cambiar de TCP a UDP en la puerta de enlace, ya que generalmente no uso ese protocolo. La regla de reenvío ahora usa UDP, y mi VPN es funcional.

Kyle
fuente
0

Si aparece después de actualizar el núcleo del sistema operativo. O los paquetes entrantes aparecen en tcpdump en el servidor, pero aún no funcionan. Pruebe con un firewall simple deshabilitar / habilitar. Quizás alguien ayude.

sudo ufw disable
sudo ufw enable
Djanym
fuente
0

Estaba teniendo este problema debido a una puerta de enlace predeterminada mal configurada en el lado del servidor. El servidor OpenVPN estaba recibiendo el intento de conexión del cliente, pero la respuesta se estaba perdiendo porque nunca llegó al enrutador correcto.

lanoxx
fuente
¿Recuerdas dónde tuviste que cambiar esto? ¿Estaba esto adentro etc/openvpn/server.conf?
Arthur Attout el
Creo que algo estaba mal con las tablas de enrutamiento en el lado del servidor. Consulte con ip route.
lanoxx
0

acabo de tener este problema. Al revisar mi archivo .ovpn, vi que? .Ddns.net había cambiado a una dirección IP, por lo que no se conectó. Cambié la dirección IP a la dirección? .Ddns.net y se conectó.

Kyn
fuente