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

Listener mati di DD-WRT biasanya bermaksud daemon keluar semasa menghurai konfigurasinya, bukan bahawa peraturan firewall menyekat port. OpenVPN 2.5 telah mengetatkan beberapa nilai lalai yang diharapkan oleh konfigurasi lama, dan konfigurasi yang dijana yang berfungsi pada binaan lama boleh ditolak sebelum soket dibuka. Puncanya ada dalam log penghala itu sendiri, dan inputnya ada dalam fail yang dijana. Membaca kedua-duanya dalam urutan itu lebih pantas daripada sebarang tangkapan paket.

Daemon bukan firewall

Perbezaan ini penting kerana kedua-dua kegagalan kelihatan sama dari luar: klien menghantar handshake dan tidak menerima apa-apa. Satu ialah proses yang tidak berjalan, dan satu lagi proses yang berjalan dan menapis.

Asingkan kedua-duanya dengan dua pemeriksaan sebelum mengubah apa-apa, kerana menyunting firewall pada daemon mati hanya menambah pemboleh ubah kedua.

Baca konfigurasi yang dijana DD-WRT

DD-WRT tidak memberikan teks yang anda taip dalam antara muka web kepada OpenVPN. Ia menulis konfigurasi yang dijana ke /tmp/openvpn/openvpn.conf dan memulakan daemon dengan fail itu, jadi medan antara muka dan sebarang teks dalam Additional Config digabungkan sebelum OpenVPN melihatnya. Jika anda menyahpepijat borang dan bukannya fail yang dijana, anda membaca niat dan bukan input sebenar. Salin fail itu ke tempat kekal sebelum but semula /tmp membersihkannya.

Bandingkan fail yang dijana dengan apa yang anda maksudkan, terutamanya di tempat antara muka menulis arahan yang tidak pernah anda pilih. Menu lungsur yang mengeluarkan pilihan usang tidak kelihatan dalam borang dan membawa maut kepada daemon.

Jika fail yang dijana kosong atau tiada, daemon tidak sempat memulakan langsung, dan masalahnya terletak di hulu OpenVPN.

Apa yang OpenVPN 2.5 berhenti terima

OpenVPN 2.5 menggantikan ncp-ciphers dengan data-ciphers, dan menaikkan versi minimum TLS lalai kepada 1.2. Ia juga mengubah pengendalian pemampatan, sehingga rakan yang menawarkan pemampatan ditolak melainkan konfigurasi membenarkannya secara jelas, dan ia menandakan nama pilihan lama seperti ns-cert-type sebagai usang demi remote-cert-tls. Setiap perubahan itu menjadikan konfigurasi yang dahulunya berfungsi sebagai kegagalan penghuraian atau rundingan.

Cara kegagalan bergantung pada arahan. Pilihan yang tidak dikenali atau dibuang menghentikan daemon semasa mula, itulah listener mati anda. Ketidakserasian rundingan membiarkan daemon berjalan dan menolak klien, yang dari sisi klien kelihatan seperti masalah firewall.

Baca ralat pertama dalam log, bukan yang terakhir. Penghuraian berhenti pada arahan buruk pertama, dan segala-galanya selepas itu ialah bunyi semasa mematikan.

Prasyarat khusus Broadcom

Pada binaan Broadcom peranti terowong mesti wujud sebelum daemon boleh menggunakannya. Periksa bahawa modul tun dimuatkan dan bahawa /dev/net/tun wujud, kerana peranti yang tiada menghasilkan kegagalan permulaan yang tiada kaitan dengan sijil. Perkara sama berlaku untuk skrip pembantu yang dijana DD-WRT untuk laluan dan DNS: jika tiada atau tidak boleh laku, daemon boleh bermula dan masih gagal menyelesaikan persediaannya.

Jalankan daemon di latar hadapan dengan lebih terperinci terhadap konfigurasi yang dijana apabila anda memerlukan mesej sebenar. Larian latar hadapan mencetak ralat penghuraian yang ditelan skrip init.

Kemudian pulihkan perkhidmatan biasa, kerana daemon latar hadapan dan skrip init akan bergaduh atas port.

Buktikan listener wujud sebelum menyahpepijat klien

Sahkan proses dan soket secara berasingan: satu arahan untuk daemon yang berjalan, satu lagi untuk port UDP yang terikat pada alamat yang dijangka. Proses tanpa soket bermakna ia masih dalam persediaan atau terikat pada antara muka yang salah. Pasangan itu ujian yang berguna kerana satu bahagian tidak boleh benar tanpa yang lain.

Nyahpepijat di sisi klien hanya bermakna selepas listener wujud. Kemudian periksa bahawa sifer dan tetapan TLS klien sepadan dengan senarai data-ciphers pelayan dan versi minimumnya, dan port benar-benar diteruskan ke penghala.

Simpan konfigurasi yang dijana dan baris log yang membuktikan pembetulan. Kemas kini firmware seterusnya boleh mengubah nilai lalai lagi, dan rekod itulah yang menjadikan pengulangan sebagai pemeriksaan lima minit.