Listener OpenVPN 2.5 di DD-WRT mati? Baca konfigurasi yang dihasilkannya

Listener yang mati di DD-WRT biasanya berarti daemon keluar saat mengurai konfigurasinya, bukan bahwa aturan firewall memblokir port. OpenVPN 2.5 memperketat beberapa nilai bawaan yang diandalkan konfigurasi lama, dan konfigurasi hasil generate yang berfungsi pada build lama bisa ditolak sebelum soket sempat dibuka. Penyebabnya ada di log router itu sendiri, dan inputnya ada di berkas hasil generate. Membaca keduanya dengan urutan itu lebih cepat daripada tangkapan paket apa pun.

Daemon bukan firewall

Pembedaan ini penting karena kedua kegagalan terlihat sama dari luar: klien mengirim handshake dan tidak menerima apa pun. Yang satu adalah proses yang tidak berjalan, yang lain proses yang berjalan dan menyaring.

Pisahkan keduanya dengan dua pemeriksaan sebelum mengubah apa pun, karena menyunting firewall pada daemon yang mati hanya menambah variabel kedua.

Baca konfigurasi yang dihasilkan DD-WRT

DD-WRT tidak memberikan teks yang Anda ketik di antarmuka web kepada OpenVPN. DD-WRT menulis konfigurasi hasil generate ke /tmp/openvpn/openvpn.conf dan menjalankan daemon dengan berkas itu, sehingga kolom antarmuka dan teks Additional Config apa pun digabungkan sebelum OpenVPN melihatnya. Jika Anda men-debug formulir alih-alih berkas hasil generate, Anda membaca niat, bukan input sebenarnya. Salin berkas itu ke tempat permanen sebelum reboot /tmp membersihkannya.

Bandingkan berkas hasil generate dengan yang Anda maksudkan, terutama di tempat antarmuka menulis direktif yang tidak pernah Anda pilih. Menu tarik-turun yang mengeluarkan opsi usang tidak terlihat di formulir dan fatal bagi daemon.

Jika berkas hasil generate kosong atau hilang, daemon bahkan tidak sampai mulai, dan masalahnya ada di hulu OpenVPN.

Apa yang berhenti diterima OpenVPN 2.5

OpenVPN 2.5 menggantikan ncp-ciphers dengan data-ciphers, dan menaikkan versi TLS minimum bawaan ke 1.2. OpenVPN juga mengubah penanganan kompresi sehingga rekan yang menawarkan kompresi ditolak kecuali konfigurasi mengizinkannya secara eksplisit, dan menandai nama opsi lama seperti ns-cert-type sebagai usang demi remote-cert-tls. Setiap perubahan itu mengubah konfigurasi yang tadinya berfungsi menjadi kegagalan penguraian atau negosiasi.

Cara kegagalannya bergantung pada direktif. Opsi yang tidak dikenal atau dihapus menghentikan daemon saat mulai, itulah listener mati Anda. Ketidakcocokan negosiasi membiarkan daemon berjalan dan menolak klien, yang dari sisi klien tampak seperti masalah firewall.

Baca kesalahan pertama di log, bukan yang terakhir. Penguraian berhenti pada direktif buruk pertama, dan semua setelahnya adalah derau dari penutupan.

Prasyarat khusus Broadcom

Pada build Broadcom peranti terowongan harus ada sebelum daemon dapat memakainya. Periksa bahwa modul tun termuat dan bahwa /dev/net/tun ada, karena peranti yang hilang menghasilkan kegagalan awal yang tidak ada hubungannya dengan sertifikat. Hal yang sama berlaku untuk skrip bantu yang dihasilkan DD-WRT untuk rute dan DNS: jika tidak ada atau tidak dapat dieksekusi, daemon bisa mulai dan tetap gagal menyelesaikan penyiapannya.

Jalankan daemon di latar depan dengan verbositas lebih tinggi terhadap konfigurasi hasil generate saat Anda membutuhkan pesan sebenarnya. Jalankan di latar depan mencetak kesalahan penguraian yang ditelan skrip init.

Lalu pulihkan layanan normal, karena daemon latar depan dan skrip init akan berebut port.

Buktikan listener ada sebelum men-debug klien

Konfirmasikan proses dan soket secara terpisah: satu perintah untuk daemon yang berjalan, satu lagi untuk port UDP yang terikat pada alamat yang diharapkan. Proses tanpa soket berarti masih dalam penyiapan atau terikat ke antarmuka yang salah. Pasangan itu uji yang berguna justru karena satu bagian tidak bisa benar tanpa yang lain.

Debug sisi klien baru masuk akal setelah listener ada. Lalu periksa bahwa cipher dan pengaturan TLS klien cocok dengan daftar data-ciphers server dan versi minimumnya, serta port benar-benar diteruskan ke router.

Simpan konfigurasi hasil generate dan baris log yang membuktikan perbaikan. Pembaruan firmware berikutnya bisa mengubah nilai bawaan lagi, dan catatan itulah yang mengubah pengulangan menjadi pemeriksaan lima menit.