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

Question

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

Eu rapidamente li ( OpenVPN on OpenVZ TLS Error: Falha de handshake TLS (o google sugeriu soluções não está ajudando) ) e tentou mudar do padrão UDP para TCP, mas isso só fez com que o cliente relatasse repetidamente que a conexão expirou. Também tentei desativar a criptografia e a autenticação TLS, mas isso causou a falha do servidor com 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.

Eu tenho seguido as instruções em ( link ) para configurar o OpenVPN e as instruções em ( link ) para criar as chaves e os certificados. Os únicos desvios que fiz a partir dessas instruções foram especificar os nomes dos meus próprios computadores e seus nomes de arquivo de chave / certificado correspondentes.

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

Alguém pode explicar como posso resolver esse problema?

Detalhes:

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

Cliente: Arch Linux (atualizado) máquina virtual no VirtualBox 4.3.28r100309 host do Windows 8.1, adaptador de rede em ponte. Não 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 do 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. Eu iniciei o servidor primeiro, depois o cliente.

A saída de openvpn /etc/openvpn/server.conf no 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 de openvpn /etc/openvpn/client.conf no 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)

    

Answer 1

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

    

Answer 2

Eu também tive esse problema.

Estou usando o provedor digitalocean para o meu servidor e o problema foi com o recurso ip flutuante.

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

local <ip anchor>

ip anchor deve ser um endereço IP obtido do comando ip addr , veja o exemplo:

Créditos deste post

    

Answer 3

Se aparecer depois de atualizar o núcleo do sistema operacional. Ou os pacotes de entrada aparecem no tcpdump no servidor, mas ainda não funcionam. Tente uma desativação / ativação simples do firewall. Talvez alguém ajude.

sudo ufw disable
sudo ufw enable

    

Answer 4

Minha configuração atual funcionaria em alguns países, mas não em outros. Estou suspeitando que meu provedor atual está bloqueando o pacote de handshake TLS. Solução? Desde que eu sou o único usando essa VPN eu mudei para autenticação de chave estática que - no meu caso - provou ser super rápida link