Masalah OpenVPN - Negosiasi kunci TLS gagal terjadi dalam 60 detik

Saya mengonfigurasi server OpenVPN (versi 2.3.10) pada server Windows 2012 tetapi saya tidak dapat membuatnya berfungsi.

Server berada di belakang router dan saya membuka port 1194 dan membuat aturan untuk meneruskan lalu lintas pada port ini ke server.

Berikut adalah log yang saya lihat di server ketika saya mencoba untuk terhubung dari klien:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

Di mana XX.XX.XX.XX adalah ip dari klien. Jadi saya mengerti dari sini bahwa klien setidaknya dapat tiba di server, jadi tidak ada masalah routing atau firewall.

Saya mengikuti deskripsi yang disediakan di sini. Panduan Windows Mudah. ​​Ada ide?

Yang menarik adalah bagaimana nomor port berubah di tengah aliran:

Senin 21 Maret 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: Paket awal dari [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Senin 21 Maret 12:12:38 2016 XX.XX.XX.XX: 55938 TLS: Paket awal dari [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Ini membuat saya berpikir bahwa, di suatu tempat antara klien dan server, ada perangkat NAT yang nakal, perangkat dengan entri tabel keadaan yang sangat singkat, yang mengubah nomor port sumber yang berlaku untuk aliran yang dibuat klien, menyebabkan server untuk berpikir bahwa dua komunikasi yang berumur pendek sedang berlangsung, alih-alih satu yang berkelanjutan.

Perangkat seperti itu umumnya hanya melakukan ini dengan UDP, jadi saya menyarankan Anda untuk mengkonfirmasi bahwa Anda menggunakan UDP, dan coba TCP sebagai gantinya. Ini sudah Anda lakukan, dan ternyata itu memperbaiki masalah. Langkah selanjutnya adalah mengidentifikasi perangkat NAT yang bermasalah, memukulnya dengan palu klub, dan menggantinya dengan yang tidak membuat kesalahan utama dengan menganggap bahwa semua komunikasi UDP adalah fana; tetapi Anda telah menunjukkan bahwa Anda senang dengan mengubah ke TCP sebagai solusi, dan masalah ini disimpulkan.

Ini adalah salah satu kesalahan paling umum dalam mengatur Openvpn dan ada entri FAQ untuk ini. Saya akan mengutip ini di sini:

Kesalahan TLS: Negosiasi kunci TLS gagal terjadi dalam 60 detik (periksa konektivitas jaringan Anda)

Salah satu masalah paling umum dalam mengatur OpenVPN adalah bahwa dua daemon OpenVPN di kedua sisi koneksi tidak dapat membuat koneksi TCP atau UDP satu sama lain.

Ini hampir merupakan akibat dari:

• Firewall perimeter pada jaringan server memfilter paket OpenVPN yang masuk (secara default OpenVPN menggunakan UDP atau nomor port TCP 1194).
• Firewall perangkat lunak yang berjalan pada mesin server OpenVPN sendiri memfilter koneksi masuk pada port 1194. Perlu diketahui bahwa banyak OS akan memblokir koneksi masuk secara default, kecuali jika dikonfigurasi sebaliknya.
• Gateway NAT pada jaringan server tidak memiliki aturan port forwarding untuk TCP / UDP 1194 ke alamat internal mesin server OpenVPN.
• Konfigurasi klien OpenVPN tidak memiliki alamat server yang benar dalam file konfigurasi. Arahan jarak jauh dalam file konfigurasi klien harus mengarah ke server itu sendiri atau alamat IP publik dari gateway jaringan server.
• Penyebab lain yang mungkin adalah bahwa windows firewall memblokir akses untuk biner openvpn.exe. Anda mungkin perlu membuat daftar putih (menambahkannya ke daftar "Pengecualian") agar OpenVPN berfungsi.

Sangat mungkin bahwa semua ini menyebabkan masalah yang sama dalam kasus Anda juga. Jadi cukup telusuri daftar satu per satu untuk menyelesaikannya.

Ref: TLS Error: Negosiasi kunci TLS gagal terjadi dalam 60 detik (periksa konektivitas jaringan Anda)

Saya mendapatkan batas waktu negosiasi kunci TLS seperti ini. Tetapi dalam kasus saya, saya menyadari bahwa tautan jarak jauh adalah alamat IP lokal.

VPN pada firewall pfSense kami secara keliru diletakkan pada antarmuka LAN alih-alih antarmuka WAN, sehingga konfigurasi yang diekspor diatur untuk mencoba dan menyambung ke alamat IP LAN firewall - yang tidak akan pernah bekerja dengan klien secara alami berada di LAN yang berbeda.

Saya pikir takeaways utama dari ini adalah:

• Mendapatkan batas waktu negosiasi utama tidak berarti Anda bahkan telah berhasil terhubung dengan apa pun.

  Jadi pada tahap ini mungkin masih layak untuk memeriksa Anda benar-benar terhubung ke tempat yang tepat, dan tidak ada aturan firewall yang memblokir koneksi, dll. Terutama jika konfigurasi Anda telah dihasilkan secara otomatis.

  Perhatikan bahwa mendapatkan prompt login tidak berarti Anda terhubung , karena OpenVPN meminta kredensial Anda sebelum mencoba terhubung.

• Pastikan server VPN Anda mendengarkan pada antarmuka yang benar.

  (Tentu saja, ini adalah salah satu dari sejumlah kesalahan konfigurasi sisi server yang dapat terjadi, seperti aturan firewall, memasukkan nomor port yang salah, mencampurkan TCP dan UDP, dll.)

Saya memiliki kesalahan yang sama dan tidak ada saran yang membantu, semuanya tampak baik-baik saja: IP, port, firewall, semuanya. Sudah gila selama 2 jam.

Solusi adalah mengubah protokol dari UDP ke TCP di konfigurasi klien (tampaknya saya menonaktifkan UDP sengaja beberapa waktu yang lalu).

Semoga ini bisa membantu seseorang :)

LE: ini menyelesaikan masalah saya tapi itu bukan pendekatan terbaik sesuai komentar di bawah ini. Anda harus menggunakan UDP bukan TCP. Ini membantu saya karena saya memiliki pengaturan berbeda antara klien dan konfigurasi server.

Tidak ada solusi yang disebutkan sebelumnya yang berfungsi. Dalam kasus saya, meskipun log klien menunjukkan kesalahan yang sama TLS Error: TLS key negotiation failed to occur within 60 seconds, log server menunjukkan VERIFY ERROR: depth=0, error=CRL has expired.

Di server, langkah-langkah berikut menyelesaikan masalah koneksi:

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

Perhatikan bahwa Anda bisa mendapatkan kesalahan negosiasi kunci TLS, tanpa berhasil menyambung ke server OpenVPN - atau bahkan berhasil menyambung ke apa pun!

Saya memodifikasi konfigurasi VPN untuk terhubung ke localhost, pada port yang tidak mendengarkan apa pun:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] dibangun pada 26 April 2018
Windows versi 6.2 (Windows 8 atau lebih tinggi) 64bit
versi pustaka: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
TCP / UDP: Mempertahankan alamat jarak jauh yang baru-baru ini digunakan: [AF_INET] 127.0.0.1:12345
Tautan UDP lokal (terikat): [AF_INET] [undef]: 0
Remote tautan UDP: [AF_INET] 127.0.0.1:12345 
Kesalahan TLS: Negosiasi kunci TLS gagal terjadi dalam 60 detik (periksa konektivitas jaringan Anda)
Kesalahan TLS: Jabat tangan TLS gagal
SIGUSR1 [lunak, tls-kesalahan] diterima, proses restart
...

Kesalahan ini dapat membuai Anda ke perasaan palsu bahwa Anda sedang berbicara dengan server VPN.

Anda bahkan mungkin dimintai kredensial terlebih dahulu, tetapi tidak ada di luar komputer Anda yang benar-benar memintanya.

Saya mengalami kesalahan ini di AWS, di mana OpenVPN diinstal pada server dengan IP publik, tetapi pada contoh yang berada di subnet pribadi, yaitu subnet yang tidak memiliki rute ke gateway internet.

Setelah saya menggunakan OpenVPN pada server di dalam subnet publik, semuanya bekerja dengan baik :)

Pada subnet publik / pribadi di AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

Saya juga menemukan TLS key negotiation failed to occur within 60 secondsmasalah.

Dari saran resmi, seperti posting Diamant, pasti ada sesuatu yang salah dalam koneksi jaringan. Namun, baik firewall maupun NAT tidak menyebabkan masalah.

Dalam kasus saya, saya pertama kali memeriksa koneksi dengan nc -uvz xxx.xxx.xxx.xxx 1194. Tautannya OK.

Selain itu, beberapa klien vpn lain dalam LAN yang sama berfungsi dengan baik.

Dari suatu tempat saya perhatikan bahwa koneksi udp memiliki beberapa masalah sebagai respons atau port forward.

Jadi saya menghentikan klien vpn yang berjalan dari ip terbesar ke klien yang menggantung, misalnya, dari "10.8.0.100" menjadi "10.8.0.50".

Kemudian mulai klien vpn yang dihentikan secara terbalik.

Bang! Semua klien vpn bekerja dengan benar.

Sebagai kesimpulan, ada kemungkinan mengarah ke TLS key negotiation failed to occur within 60 secondsmasalah bahwa banyak klien VPN dalam LAN dimulai dengan urutan yang salah.