Correggi "Errore TLS: stretta di mano TLS non riuscita" sul client OpenVPN


16

Sto configurando OpenVPN 2.3.6-1 sul mio server Arch Linux per crittografare il traffico SMB su Internet pubblico. Quando ho verificare l'installazione su uno dei miei clienti macchine virtuali Linux, ottengo l'errore: TLS Error: TLS handshake failed.

Ho letto rapidamente ( OpenVPN su OpenVZ TLS Error: stretta di mano TLS non riuscita (google ha suggerito soluzioni che non aiutano) ) e ho provato a passare da UDP predefinito a TCP, ma ciò ha causato solo al client di segnalare ripetutamente che la connessione è scaduta. Ho anche provato a disabilitare la crittografia e l'autenticazione TLS, ma ciò ha causato il fallimento del server Assertion failed at crypto_openssl.c:523. In entrambi i casi, sono state apportate le modifiche richieste alle configurazioni client e server.

Ho seguito le istruzioni su ( https://wiki.archlinux.org/index.php/OpenVPN ) per configurare OpenVPN e le istruzioni su ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scripts ) per creare chiavi e certificati. Le uniche deviazioni che ho fatto da queste istruzioni sono state specificando i nomi dei miei computer e i loro nomi di file chiave / certificato corrispondenti.

Vedi anche la mia domanda originale sulla protezione del traffico SMB su Internet: ( Crittografia semplice per condivisioni Samba )

Qualcuno può spiegare come posso risolvere questo problema?

Dettagli:

Server: Arch Linux (aggiornato) collegato direttamente al gateway tramite cavo Ethernet. Nessun iptables.

Client: macchina virtuale Arch Linux (aggiornata) su VirtualBox 4.3.28r100309 Host Windows 8.1, scheda di rete con bridge. Nessun iptables. Windows Firewall disabilitato.

Gateway: port forwarding per la porta 1194 abilitata, nessuna limitazione del firewall.

Ecco i file di configurazione sul server e sul client, rispettivamente. Li ho creati secondo le istruzioni su Arch Wiki.

/etc/openvpn/server.conf (Solo righe senza commento):

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 righe senza commento):

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

Ecco gli output di esecuzione di openvpn sui computer con le configurazioni precedenti. Ho avviato prima il server, quindi il client.

L'output di openvpn /etc/openvpn/server.confsul server:

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

L'output di openvpn /etc/openvpn/client.confsul client:

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)

1
Il tuo client non riceve mai una risposta dal server. O hai un firewall di cui ti sei dimenticato o il tuo port forwarding non funziona.
Michael Hampton

2
Esegui l'annullamento di un pacchetto, ad esempio: tcpdump -ni eth0 udp and port 1194 sul server e assicurati che i pacchetti arrivino. In caso affermativo, potrebbero esserci problemi con il rilascio dei pacchetti del firewall, in caso contrario è molto probabile che si verifichino problemi con il port forwarding sul router. Puoi farlo anche sul router. Dai un'occhiata e prova a usare una porta più alta, non è comune ma forse il tuo ISP ha incasinato qualcosa, come la porta 11194 / UDP o 53 / UDP.
Michal Sokolowski il

Sì, era l'inoltro. Di solito non lavoro con UDP, quindi ho dimenticato di cambiare il protocollo durante la creazione della regola. Lo posterò come risposta.
Kyle,

3
Se i pacchetti compaiono in tcpdump sul server, c'è un modo per assicurarsi che arrivino correttamente ad openvpn?
Joost il

Risposte:


9

Ho avuto anche questo problema.

Sto usando il provider digitalocean per il mio server e il problema era con la funzione IP mobile.

Per risolvere questo problema, devi aggiornare l'impostazione di configurazione di openvpn:

local <ip anchor>

ip anchor dovrebbe essere un indirizzo IP raccolto dal ip addrcomando, vedi esempio: inserisci qui la descrizione dell'immagine

Crediti per questo post


Ho avuto questo problema anche con un dispositivo pfsense. L'aggiunta della local <ip address of VPN server>voce nella configurazione del server l'ha riparata. Si noti che per TCP questa voce non era necessaria, era solo UDP a dare l'errore.
Vincenzo Pii,

5

Come suggerito da Michael Hampton e Michal Sokolowski nei commenti sulla mia domanda, si è verificato un problema con la regola di port forwarding che ho creato sul mio gateway. OpenVPN è configurato per utilizzare UDP e ho dimenticato di passare da TCP a UDP sul gateway poiché di solito non uso quel protocollo. La regola di inoltro ora utilizza UDP e la mia VPN è funzionale.


0

Se appare dopo aver aggiornato il core del sistema operativo. Oppure i pacchetti in arrivo vengono visualizzati in tcpdump sul server, ma non funzionano ancora. Prova una semplice disabilitazione / abilitazione del firewall. Forse qualcuno ti aiuterà.

sudo ufw disable
sudo ufw enable


0

Stavo riscontrando questo problema a causa di un gateway predefinito non configurato sul lato server. Il server OpenVPN stava ottenendo il tentativo di connessione dal client ma la risposta andava persa perché non ha mai raggiunto il router giusto.


Ti ricordi dove hai dovuto cambiare questo? Era dentro etc/openvpn/server.conf?
Arthur Attout,

Penso che qualcosa non andasse nelle tabelle di routing sul lato server. Verificare con ip route.
lanoxx,

0

Ho appena avuto questo problema. Controllando il mio file .ovpn ho visto che? .Ddns.net era stato cambiato in un indirizzo IP, motivo per cui non si è collegato. Ho cambiato l'IP di nuovo all'indirizzo? .Ddns.net e si è collegato.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.