Perbaiki 'Kesalahan TLS: Jabat tangan TLS gagal' pada klien OpenVPN


16

Saya mengkonfigurasi OpenVPN 2.3.6-1 di server Arch Linux saya untuk mengenkripsi lalu lintas SMB melalui Internet publik. Ketika saya uji setup pada salah satu saya Linux mesin virtual klien, saya mendapatkan error: TLS Error: TLS handshake failed.

Saya cepat membaca ( OpenVPN pada OpenVZ Kesalahan TLS: Jabat tangan TLS gagal (solusi yang disarankan Google tidak membantu) ) dan mencoba beralih dari UDP default ke TCP, tetapi itu hanya menyebabkan klien melaporkan berulang kali bahwa koneksi habis waktu. Saya juga mencoba menonaktifkan otentikasi cipher dan TLS, tetapi itu menyebabkan server gagal Assertion failed at crypto_openssl.c:523. Dalam kedua kasus, perubahan yang diperlukan dibuat untuk konfigurasi klien dan server.

Saya telah mengikuti instruksi di ( https://wiki.archlinux.org/index.php/OpenVPN ) untuk mengatur OpenVPN dan instruksi di ( https://wiki.archlinux.org/index.php/Create_a_Public_Key_Infrastructure_Using_the_easy-rsa_Scriptts ) untuk membuat kunci dan sertifikat. Satu-satunya penyimpangan yang saya buat dari instruksi ini adalah menentukan nama komputer saya sendiri dan nama file sertifikat / kunci yang sesuai.

Lihat juga pertanyaan awal saya tentang mengamankan lalu lintas SMB melalui Internet: ( Enkripsi sederhana untuk saham Samba )

Adakah yang bisa menjelaskan bagaimana saya bisa menyelesaikan masalah ini?

Detail:

Server: Arch Linux (terbaru) terhubung langsung ke gateway melalui kabel ethernet. Tidak ada iptables.

Klien: Mesin virtual Arch Linux (terbaru) di host VirtualBox 4.3.28r100309 Windows 8.1, adapter jaringan yang dijembatani. Tidak ada iptables. Windows Firewall dinonaktifkan.

Gateway: Port forwarding untuk port 1194 diaktifkan, tidak ada batasan firewall.

Berikut adalah file konfigurasi di server dan klien, masing-masing. Saya membuat ini sesuai dengan instruksi pada Arch Wiki.

/etc/openvpn/server.conf (Baris non-komentar saja):

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 (Baris non-komentar saja):

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

Berikut ini adalah output dari menjalankan openvpn pada mesin dengan konfigurasi di atas. Saya memulai server terlebih dahulu, lalu klien.

Output dari openvpn /etc/openvpn/server.confpada 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

Output dari openvpn /etc/openvpn/client.confpada klien:

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
Klien Anda tidak pernah mendapat respons dari server sama sekali. Entah Anda memiliki firewall yang Anda lupa, atau penerusan port Anda tidak berfungsi.
Michael Hampton

2
Lakukan mengendus paket, seperti: tcpdump -ni eth0 udp and port 1194 di server dan memastikan apakah paket datang. Jika ada, mungkin ada masalah dengan paket firewall dropping, jika tidak maka kemungkinan besar ada beberapa masalah dengan port forwarding pada router. Anda dapat melakukannya di router juga. Coba dan coba gunakan beberapa port yang lebih tinggi, itu tidak umum tetapi mungkin ISP Anda mengacaukan sesuatu, seperti port 11194 / UDP atau 53 / UDP.
Michal Sokolowski

Ya, itu adalah penerusan. Saya biasanya tidak bekerja dengan UDP, jadi saya lupa mengubah protokol saat membuat aturan. Saya akan memposting itu sebagai jawabannya.
Kyle

3
Jika paket muncul di tcpdump di server, apakah ada cara untuk memastikan bahwa mereka tiba di openvpn dengan benar?
Joost

Jawaban:


9

Saya punya masalah ini juga.

Saya menggunakan penyedia digitalocean untuk server saya dan masalahnya adalah dengan fitur ip mengambang.

Untuk memperbaikinya, Anda harus memperbarui pengaturan konfigurasi openvpn:

local <ip anchor>

ip anchor harus berupa alamat ip yang dikumpulkan dari ip addrperintah, lihat contoh: masukkan deskripsi gambar di sini

Kredit untuk pos ini


Saya punya masalah ini juga dengan perangkat pfsense. Menambahkan local <ip address of VPN server>entri dalam konfigurasi server memperbaikinya. Perhatikan bahwa untuk TCP entri ini tidak diperlukan, hanya UDP yang memberikan kesalahan.
Vincenzo Pii

5

Seperti yang disarankan oleh Michael Hampton dan Michal Sokolowski di komentar pada pertanyaan saya, itu adalah masalah dengan aturan port forwarding yang saya buat di gateway saya. OpenVPN dikonfigurasi untuk menggunakan UDP, dan saya lupa untuk beralih dari TCP ke UDP di gateway karena saya biasanya tidak menggunakan protokol itu. Aturan penerusan sekarang menggunakan UDP, dan VPN saya berfungsi.


0

Jika muncul setelah memperbarui inti OS. Atau paket yang masuk muncul di tcpdump di server, tetapi masih tidak berfungsi. Coba nonaktifkan / aktifkan firewall sederhana. Mungkin seseorang akan membantu.

sudo ufw disable
sudo ufw enable


0

Saya mendapatkan masalah ini karena gateway default salah konfigurasi di sisi server. Server OpenVPN mendapatkan upaya koneksi dari klien tetapi responsnya kemudian hilang karena tidak pernah mencapai router yang tepat.


Apakah Anda ingat di mana Anda harus mengubah ini? Apakah ini ada di dalam etc/openvpn/server.conf?
Arthur Attout

Saya pikir ada sesuatu yang salah dengan tabel routing di sisi server. Periksa dengan ip route.
lanoxx

0

Saya baru saja mengalami masalah ini. Saat memeriksa file .ovpn saya, saya melihat bahwa? .Ddns.net telah diubah menjadi alamat IP, oleh karena itu tidak terhubung. Saya mengubah IP kembali ke alamat? .Ddns.net dan terhubung.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.