Cara OpenVPN data-sandis memilih sandi kanal data

Tunnel menyala, log menampilkan sandi, dan peninjauan profil berlanjut. Lalu peningkatan tiba di salah satu peer dan profil yang sama gagal dengan pesan tidak ada sandi bersama, yang membuat orang mencari direktif untuk dihapus. Hal yang berguna untuk dipahami adalah data-sandis menggambarkan negosiasi, bukan pengaturan. Satu sisi menawarkan daftar, sisi lain memilih darinya, dan hasilnya satu algoritme yang didukung keduanya. Membaca pertukaran itu menjelaskan sebagian besar kegagalan ini sebelum Anda mengubah satu baris.

Dua kanal, dua konfigurasi

Satu OpenVPN sesi memiliki kanal kontrol dan kanal data. Kanal kontrol menjalankan jabat tangan TLS yang mengautentikasi peer dan menegosiasikan kunci. Kanal data mengenkripsi paket yang membawa lalu lintas Anda.

data-sandis mengonfigurasi yang kedua. Kanal kontrol punya opsi sendiri, dan pemeriksaan identitas profil adalah urusan ketiga yang terpisah. Perubahan pada satu tidak memperbaiki yang lain, karena itu profil bisa tampak benar dan tetap gagal pada tahap tertentu.

Simpan ketiganya di kotak masing-masing saat Anda membaca berkas konfigurasi.

Baca negosiasi dari log

Log klien menyebut kedua hasil saat koneksi berhasil. Satu baris melaporkan kanal kontrol dan detail TLS-nya, dan baris lain melaporkan sandi kanal data yang dipilih.

Baca keduanya, karena keduanya menjawab pertanyaan berbeda. Kegagalan kanal kontrol menghentikan koneksi sebelum sandi data mana pun menjadi penting. Ketidakcocokan kanal data muncul setelah jabat tangan yang berhasil, dengan pesan tidak ada sandi bersama.

Lalu bandingkan daftar yang ditawarkan di kedua sisi. Nama yang tidak disediakan oleh versi satu peer atau backend kripto-nya tidak dapat dipilih, tidak peduli seberapa awal nama itu muncul di daftar peer lain.

Bagaimana pemilihan sebenarnya terjadi

Server mendorong daftar data-sandis-nya ke klien selama jabat tangan, dan klien memilih entri pertama dalam daftar itu yang juga didukungnya. Urutan karena itu milik konfigurasi server, bukan konfigurasi klien.

Detail itu menjelaskan sekelompok hasil yang membingungkan. Mengurutkan ulang daftar klien tidak mengubah apa pun selama daftar server yang menentukan. Menambahkan sandi yang tidak dapat disediakan klien juga tidak mengubah apa pun, karena klien harus dapat menggunakan entri yang dipilihnya.

Rilis yang lebih baru mengubah daftar bawaan dan mengganti nama opsi yang dulu memuatnya, sehingga dua peer pada versi berbeda bisa berselisih tanpa ada yang menyunting profil. Periksa versi di setiap sisi sebelum menganggapnya salah ketik.

Daftar bukan peringkat kekuatan secara abstrak. Itu adalah kumpulan kandidat, dan yang dipilih adalah entri pertama yang saling didukung dalam urutan server. Itu sebabnya dua daftar yang terlihat berbeda dapat menegosiasikan sandi yang sama. Itu juga sebabnya dua daftar yang terlihat identik dapat gagal.

Peer lama memerlukan cadangan yang disengaja

Peer yang tidak dapat bernegosiasi sama sekali, karena lebih tua dari mekanisme atau menonaktifkannya, memerlukan pengaturan kompatibilitas yang terdokumentasi. Opsi cadangan ada tepat untuk kasus itu dan berlaku bagi peer yang tidak ikut bernegosiasi.

Itu tidak sama dengan mengaktifkan setiap sandi lama agar pesan hilang. Daftar yang lebar melemahkan sesi bagi setiap peer, termasuk yang seharusnya menegosiasikan sesuatu yang kuat.

Koordinasikan kedua sisi alih-alih menyunting nama algoritme yang tidak terkait. Jika peningkatan server menghapus opsi lama, perbaikan itu milik rencana versi, bukan upaya panik di klien.

Jaga verifikasi tetap utuh

Ketidakcocokan kanal data bukan alasan untuk menerima server yang tidak terverifikasi. Verifikasi sertifikat, nama server yang diharapkan, dan pengaturan perlindungan kanal kontrol terpisah dari pemilihan sandi dan harus bertahan terhadap perubahan kompatibilitas apa pun.

Catat sandi data yang dinegosiasikan, versi klien, dan versi server bersama-sama, agar perbandingan berikutnya mulai dari fakta, bukan dari berkas profil.

Setelah koreksi yang didukung, uji koneksi awal dan negosiasi ulang, karena sesi yang pernah terbentuk masih bisa gagal saat kunci diperbarui.

Jika tunnel terbentuk dan situs masih gagal, sandi bukan lagi tersangka. Lanjutkan dengan perutean dan DNS. Urutan kerja: baca kedua baris log, bandingkan kedua daftar, periksa versi, tambahkan cadangan hanya untuk peer yang membutuhkannya, lalu uji ulang jalur pembaruan.