Por que o handshake de TLS falhou?

1

Meu cliente OpenVPN (Windows 10) está em uma LAN corporativa e se conecta a um servidor na Internet (Ubuntu). A configuração usada para funcionar, mas interrompida há algum tempo (veja abaixo para a pequena alteração de infraestrutura, a configuração do servidor ou do cliente não foi alterada).

Nos registros abaixo

  • o endereço do servidor OpenVPN é SERVERIP
  • ao sair da LAN corporativa, o endereço de origem é CORPORATEIP (é SNATed do IP interno do cliente)

Ao tentar se conectar a partir do cliente, recebo o seguinte log:

Sun May 29 10:55:07 2016 OpenVPN 2.3.11 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Sun May 29 10:55:07 2016 Windows version 6.2 (Windows 8 or greater) 64bit
Sun May 29 10:55:07 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.09
Sun May 29 10:55:07 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun May 29 10:55:07 2016 Need hold release from management interface, waiting...
Sun May 29 10:55:08 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'state on'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'log all on'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'hold off'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'hold release'
Sun May 29 10:55:08 2016 MANAGEMENT: CMD 'proxy NONE  '
Sun May 29 10:55:09 2016 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun May 29 10:55:09 2016 MANAGEMENT: >STATE:1464512109,RESOLVE,,,
Sun May 29 10:55:09 2016 UDPv4 link local: [undef]
Sun May 29 10:55:09 2016 UDPv4 link remote: [AF_INET]SERVERIP:1194
Sun May 29 10:55:09 2016 MANAGEMENT: >STATE:1464512109,WAIT,,,

No lado do servidor, isso corresponde a

May 29 10:55:09 srv ovpn-server[732]: CORPORATEIP:15057 TLS: Initial packet from [AF_INET]CORPORATEIP:15057, sid=38d5a524 b40f69aa
May 29 10:56:09 srv ovpn-server[732]: CORPORATEIP:15057 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
May 29 10:56:09 srv ovpn-server[732]: CORPORATEIP:15057 TLS Error: TLS handshake failed
May 29 10:56:09 srv ovpn-server[732]: CORPORATEIP:15057 SIGUSR1[soft,tls-error] received, client-instance restarting
May 29 10:56:12 srv ovpn-server[732]: CORPORATEIP:15082 TLS: Initial packet from [AF_INET]CORPORATEIP:15082, sid=36d1f0e9 9cdc88ec

Assim, o cliente chega ao servidor, tenta uma conexão e, em seguida, TLS Error: TLS key negotiation failed to occur within 60 seconds acontece.

O Perguntas freqüentes do OpenVPN menciona este erro e sugere que o tráfego possa ter um firewall (no servidor ou no cliente). Este não é o caso, uma vez que o cliente chega ao servidor (assim udp/1154 tráfego está aberto nos firewalls).

A configuração usada para trabalhar, a única mudança que eu posso pensar foi uma mudança no lado do servidor: ela costumava estar em uma LAN, com udp/1154 encaminhado para ela, agora está em uma DMZ (onde gerencia os DNATs em si via iptables / shorewall, se necessário). Como os pacotes do cliente chegam ao servidor, não acho que seja esse o motivo.

Antes de prosseguir, gostaria de deixar as questões de firewall de lado:

  • Meu entendimento do que foi dito acima é que o cliente - > a conexão do servidor funciona.
  • O tráfego do servidor OpenVPN para o mundo está aberto (consigo pingar CORPORATEIP , por exemplo, UDP e TCP também estão abertos)

A minha suposição acima é de que o firewall não seja o problema correto?

(Desde que eu não queria ter certeza de que o caminho de retorno não estava obstruído, coloquei um pequeno servidor HTTP no servidor e conectei-o a partir da LAN corporativa, a conexão continua (o mesmo caminho))

# server configuration
port 1194
proto udp
dev tun0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
dh /etc/openvpn/dh2048.pem
server 10.10.13.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
# client configuration
route-nopull
route 10.10.10.0 255.255.255.0
route 10.10.11.0 255.255.255.0
route 10.10.12.0 255.255.255.0
client
dev tun
proto udp
remote SERVER_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
MIIEgDCCA2igAwIBAgIJ...
(...)
b4yiCAmaA8p5JRYqYBiT...
p20oZw==
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
(...)
         8f:d4:9d:d0
-----BEGIN CERTIFICATE-----
MIIE3DCCA8SgAwIBAgIBA...
(...)
eGOJMoV4vXQ31DZmEl33l...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvwIBADANBgkqhkiG9...
(...)
APOSuHJ4aXJocgOK3jGoK...
-----END PRIVATE KEY-----
</key>
por WoJ 29.05.2016 / 11:33

1 resposta

0

TL; DR: O problema acabou sendo no firewall de saída.

Este é um firewall com um proxy transparente que filtra, entre outros, "aplicativos" (como isso é feito é proprietário - este é um dispositivo BlueCoat). Estou autorizado a usar VPNs (isso inclui o OpenVPN) e o daemon responsável pela autorização caiu durante o fim de semana - efetivamente descartando meus pacotes.

Este é um problema localizado e considerei excluir a pergunta, mas há um comportamento estranho que pode ajudar alguém que enfrenta um problema semelhante: apenas alguns dos pacotes do OpenVPN são marcados como "VPN" pelo BlueCoat - portanto, a conexão inicial estava passando (ou seja, CLIENT_HARD_RESET ), mas outros pacotes ( SERVER_HARD_RESET para começar) foram bloqueados.

Teria sido muito mais fácil solucionar problemas se tudo estivesse bloqueado, o que era enganoso era o tráfego parcialmente interrompido.

    
por 31.05.2016 / 19:22

Tags