Correção 'Erro TLS: falha no handshake TLS' no cliente OpenVPN

Estou configurando o OpenVPN 2.3.6-1 no meu servidor Arch Linux para criptografar o tráfego SMB pela Internet pública. Quando eu testar a configuração em um dos meus clientes de máquina virtual Linux, eu recebo o erro: TLS Error: TLS handshake failed.

Eu li rapidamente ( OpenVPN no OpenVZ TLS Error: TLS handshake falhou (o Google sugeriu que as soluções não estavam ajudando) ) e tentei mudar do UDP padrão para o TCP, mas isso só fez com que o cliente informasse repetidamente que a conexão expirou. Também tentei desabilitar a autenticação de cifra e TLS, mas isso causou uma falha no servidor Assertion failed at crypto_openssl.c:523. Nos dois casos, as alterações necessárias foram feitas nas configurações do cliente e do servidor.

Tenho seguido as instruções em ( https://wiki.archlinux.org/index.php/OpenVPN ) para configurar o OpenVPN e as instruções em ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ) para criar as chaves e certificados. Os únicos desvios que fiz dessas instruções foram especificar os nomes dos meus próprios computadores e os nomes de arquivos de chaves / certificados correspondentes.

Veja também minha pergunta original sobre como proteger o tráfego SMB pela Internet: ( Criptografia simples para compartilhamentos Samba )

Alguém pode explicar como posso resolver esse problema?

Detalhes:

Servidor: Arch Linux (atualizado) conectado diretamente ao gateway via cabo Ethernet. Não há iptables.

Cliente: máquina virtual Arch Linux (atualizada) no host do VirtualBox 4.3.28r100309 Windows 8.1, adaptador de rede em ponte. Não há iptables. Firewall do Windows desativado.

Gateway: encaminhamento de porta para a porta 1194 ativada, sem restrições de firewall.

Aqui estão os arquivos de configuração no servidor e no cliente, respectivamente. Eu os criei de acordo com as instruções no Arch Wiki.

/etc/openvpn/server.conf (Apenas linhas sem comentário):

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 (Apenas linhas sem comentário):

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

Aqui estão as saídas da execução do openvpn nas máquinas com as configurações acima. Comecei o servidor primeiro e depois o cliente.

A saída de openvpn /etc/openvpn/server.confno 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

A saída openvpn /etc/openvpn/client.confno 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)

Eu tive esse problema também.

Estou usando o provedor digitalocean para o meu servidor e o problema estava no recurso de IP flutuante.

Para corrigir isso, você deve atualizar a configuração do openvpn:

local <ip anchor>

ip anchor deve ser um endereço IP coletado do ip addrcomando, veja o exemplo:

Créditos para esta postagem

Conforme sugerido por Michael Hampton e Michal Sokolowski nos comentários da minha pergunta, houve um problema com a regra de encaminhamento de porta que criei no meu gateway. O OpenVPN está configurado para usar UDP, e eu esqueci de mudar de TCP para UDP no gateway, pois geralmente não uso esse protocolo. A regra de encaminhamento agora usa UDP, e minha VPN está funcional.

Se ele aparecer após a atualização do núcleo do sistema operacional. Ou os pacotes recebidos aparecem no tcpdump no servidor, mas ainda não funcionam. Tente um simples firewall desativar / ativar. Talvez alguém ajude.

sudo ufw disable
sudo ufw enable

Minha configuração atual funcionaria em alguns países, mas não em outros. Suspeito que meu provedor atual esteja bloqueando o pacote de handshake TLS. Solução? Como sou o único a usar essa VPN, mudei para a autenticação de chave estática que, no meu caso, provou ser super rápida https://openvpn.net/index.php/open-source/documentation/misc Miscellaneous/78-static -key-mini-howto.html

Eu estava recebendo esse problema devido a um gateway padrão mal configurado no lado do servidor. O servidor OpenVPN estava recebendo a tentativa de conexão do cliente, mas a resposta estava sendo perdida porque nunca alcançou o roteador correto.

Eu apenas tive esse problema. Ao verificar meu arquivo .ovpn, vi que o? .Ddns.net havia sido alterado para um endereço IP, razão pela qual não se conectou. Mudei o IP de volta para o endereço? .Ddns.net e ele se conectou.