Mengapa menambah opt-verify tidak akan membaiki ralat sifer OpenVPN anda

Anda menemui cadangan untuk menambah opt-verify, menambah baris itu, dan ralat sifer kekal tepat di tempatnya. Hasil itu boleh dijangka, kerana pilihan itu tidak pernah merundingkan sifer. Ia ialah semakan ketekalan pilihan, usang dalam 2.6 dan dialihkan dalam 2.7, dan profil yang masih dihuraikan dengannya tidak dengan itu menguatkuasakan apa-apa.

Berguna untuk mengetahui apa yang dahulu dilakukan baris itu sebelum menyimpulkan bahawa ia ialah bahagian yang hilang. Sejarah juga menjelaskan mengapa ia tidak dapat membantu sekarang.

Apa yang dahulu dikuatkuasakan oleh pilihan itu

Manual 2.6 menandakan opt-verify sebagai usang dan menerangkan tingkah laku terdahulu: pelayan menggugurkan klien yang pilihan terisytiharnya tidak sepadan dengan pilihannya sendiri, membandingkan perkara seperti jenis peranti dan MTU. Semakan itu juga bergantung pada semakan ketekalan pilihan kekal dihidupkan, jadi pelayan yang berjalan dengan disable-occ tidak pernah memilikinya. Perhatikan daripada apa perbandingan itu dibina: teks yang menerangkan konfigurasi pihak lain. Ia tidak mengatakan apa-apa tentang sifer mana yang akan digunakan oleh saluran data.

Itulah sebab pertama mengapa bendera itu tidak dapat membaiki ralat sifer. Pemilihan sifer ditadbir oleh dasar data-ciphers dan oleh apa yang disokong oleh kedua-dua pihak, dan semakan ketekalan teks tidak mengembangkan senarai itu mahupun melakukan rundingan. Sebab kedua ialah skop: semakan itu tentang sama ada pilihan terisytihar kelihatan serasi, bukan tentang kualiti laluan yang terhasil.

Apa yang 2.7 lakukan apabila melihat baris itu

Dalam 2.7 pilihan itu tiada. Penghurai masih mengenali namanya, itulah sebabnya profil lama dimuatkan tanpa ralat sintaksis, dan ia melaporkan bahawa pilihan itu telah dialihkan dan bukannya melangkaunya secara senyap. Mengenali nama dan menguatkuasakan tingkah laku ialah perkara berbeza, dan hanya yang pertama masih berlaku. Nota pengalihan memberikan sebabnya: sebaik sahaja parameter boleh dirundingkan, dua pihak boleh secara sah mempunyai rentetan pilihan yang berbeza sambil bersetuju tentang sambungan.

Profil yang dihuraikan oleh itu bukan bukti bahawa sebarang semakan kemasukan telah dijalankan. Jika satu-satunya isyarat anda ialah klien telah bersambung, anda telah mengetahui bahawa sintaksis itu diterima.

Di mana kegagalan itu sebenarnya berada

Simpan ralat konkrit pertama sebelum mengubah apa-apa, kerana mesej kemudian biasanya akibat daripadanya. Kegagalan rundingan saluran data tergolong dalam dasar sifer yang diluluskan dan keupayaan yang benar-benar diiklankan oleh kedua-dua pihak. Kegagalan versi atau suite TLS tergolong dalam saluran kawalan. Penolakan sijil memerlukan identiti dan rantaian kepercayaan, bukan bendera keserasian.

Kenal pasti enjin di kedua-dua hujung juga. Aplikasi desktop boleh membawa binaan yang berbeza daripada binari baris arahan yang anda uji, dan sokongan pilihan berbeza antara keduanya. Semak dokumentasi enjin itu dan bukannya menganggap setiap program yang mengimport profil berkelakuan sama.

Ganti niat, bukan hanya baris

Jika pelayan terurus yang lebih lama benar-benar bergantung pada semakan ketekalan, catat kekangan apa yang dikuatkuasakannya sebelum peningkatan. Mengekalkan pilihan yang diabaikan dalam profil yang lebih baharu tidak dapat memelihara dasar itu, dan memadam baris secara sembarangan juga tidak dapat.

Jangan membalas cadangan lama bahawa semua sifer dilumpuhkan dengan mendayakan setiap algoritma sejarah.

Selepas pembetulan yang diluluskan, periksa hasil yang dirundingkan pada sambungan baharu dan uji aplikasi yang benar-benar diperlukan oleh pengguna. Simpan versi pelayan dan dasar berkesan di sebelah hasil itu, supaya orang seterusnya dapat melihat apa yang dipersetujui dan bukan hanya apa yang diterima.

Matlamatnya ialah kekangan yang disokong dan laluan disahkan yang berfungsi, bukan bendera lama yang masih dihuraikan.