Mengapa menambahkan opt-verify tidak akan memperbaiki galat cipher OpenVPN Anda

Anda menemukan saran untuk menambahkan opt-verify, menambahkan baris itu, dan galat cipher tetap persis di tempatnya. Hasil itu dapat diprediksi, karena opsi tersebut tidak pernah menegosiasikan cipher. Itu adalah pemeriksaan konsistensi opsi, usang pada 2.6 dan dihapus pada 2.7, dan profil yang masih dapat diurai dengannya tidak dengan demikian menegakkan apa pun.

Berguna untuk mengetahui apa yang dahulu dilakukan baris itu sebelum menyimpulkan bahwa ia adalah bagian yang hilang. Sejarahnya juga menjelaskan mengapa ia tidak dapat membantu sekarang.

Apa yang dahulu ditegakkan opsi itu

Manual 2.6 menandai opt-verify sebagai usang dan menjelaskan perilaku sebelumnya: server menjatuhkan klien yang opsi terdeklarasinya tidak cocok dengan opsinya sendiri, membandingkan hal-hal seperti jenis perangkat dan MTU. Pemeriksaan itu juga bergantung pada pemeriksaan konsistensi opsi tetap aktif, jadi server yang berjalan dengan disable-occ tidak pernah memilikinya. Perhatikan dari apa perbandingan itu dibangun: teks yang menjelaskan konfigurasi pihak lain. Itu tidak mengatakan apa pun tentang cipher mana yang akan digunakan kanal data.

Itulah alasan pertama mengapa flag itu tidak dapat memperbaiki galat cipher. Pemilihan cipher diatur oleh kebijakan data-ciphers dan oleh apa yang didukung kedua pihak, dan pemeriksaan konsistensi tekstual tidak memperluas daftar itu maupun melakukan negosiasi. Alasan kedua adalah cakupan: pemeriksaan itu tentang apakah opsi terdeklarasi tampak kompatibel, bukan tentang kualitas jalur yang dihasilkan.

Apa yang dilakukan 2.7 ketika melihat baris itu

Pada 2.7 opsi itu sudah tidak ada. Pengurai masih mengenali namanya, itulah sebabnya profil lama dimuat tanpa galat sintaksis, dan ia melaporkan bahwa opsi itu dihapus alih-alih melewatinya dalam diam. Mengenali nama dan menegakkan perilaku adalah hal berbeda, dan hanya yang pertama masih terjadi. Catatan penghapusan memberikan alasannya: begitu parameter dapat dinegosiasikan, dua pihak dapat secara sah memiliki string opsi yang berbeda sementara mereka menyetujui koneksinya.

Profil yang dapat diurai karena itu bukan bukti bahwa pemeriksaan penerimaan apa pun dijalankan. Jika satu-satunya sinyal Anda adalah klien terhubung, Anda telah mengetahui bahwa sintaksisnya diterima.

Di mana kegagalan sebenarnya berada

Pertahankan galat konkret pertama sebelum mengubah apa pun, karena pesan berikutnya biasanya merupakan konsekuensinya. Kegagalan negosiasi kanal data termasuk dalam kebijakan cipher yang disetujui dan kemampuan yang benar-benar diiklankan kedua pihak. Kegagalan versi atau suite TLS termasuk dalam kanal kontrol. Penolakan sertifikat membutuhkan identitas dan rantai kepercayaan, bukan flag kompatibilitas.

Identifikasi juga mesin di kedua ujung. Aplikasi desktop dapat memuat build yang berbeda dari biner baris perintah yang Anda uji, dan dukungan opsi berbeda di antara keduanya. Periksa dokumentasi mesin itu alih-alih menganggap setiap program yang mengimpor profil berperilaku sama.

Ganti maksudnya, bukan hanya barisnya

Jika server terkelola yang lebih lama benar-benar mengandalkan pemeriksaan konsistensi, catat batasan apa yang ditegakkannya sebelum peningkatan. Mempertahankan opsi yang diabaikan dalam profil yang lebih baru tidak dapat melestarikan kebijakan itu, dan menghapus baris secara sembarangan juga tidak dapat.

Jangan menanggapi saran lama bahwa semua cipher dinonaktifkan dengan mengaktifkan setiap algoritme historis.

Setelah koreksi yang disetujui, periksa hasil yang dinegosiasikan pada koneksi baru dan uji aplikasi yang benar-benar dibutuhkan pengguna. Simpan versi server dan kebijakan efektif di samping hasil itu, agar orang berikutnya dapat melihat apa yang disepakati, bukan hanya apa yang diterima.

Tujuannya adalah batasan yang didukung dan jalur terautentikasi yang berfungsi, bukan flag lama yang masih dapat diurai.