tls-auth key-direction: 0 dan 1 harus berbeda, bukan sama
Dengan tls-auth kedua ujung perlu arah berlawanan, 0 dan 1, atau keduanya harus menghilangkan setelan itu. Angka yang sama gagal, dan tls-crypt tidak pernah memakainya.
Satu sisi terowongan menandatangani kanal kontrol dengan slot kunci yang tidak pernah diperiksa sisi lain, dan koneksi mati dengan galat autentikasi sebelum satu sertifikat pun ditukar. Begitulah ketidakcocokan arah pada tls-auth, dan sifatnya deterministik: dua berkas yang sama gagal pada setiap percobaan, dari jaringan mana pun. Tidak ada yang menyebut nama opsi yang Anda cari di log, karena itu orang membangun ulang kunci dan menerbitkan ulang sertifikat yang tidak pernah rusak. Solusinya adalah membuat kedua ujung saling melengkapi, atau membiarkan keduanya dua arah, bukan melemahkan verifikasi.
Kegagalan terjadi sebelum sertifikat
Dengan tls-auth, kedua peer memegang kunci bersama yang sama dan masing-masing memakai satu dari dua slot yang diturunkan darinya: satu slot menandatangani paket kontrol keluar, yang lain memverifikasi paket masuk. Arah 0 dan arah 1 menetapkan peran itu dalam urutan berlawanan, jadi pasangannya harus saling melengkapi agar pemeriksaan HMAC cocok. Ketika penetapan dibalik di satu sisi, penerima mencari tanda tangan di slot yang salah dan menolak paket. Sesi berakhir di situ, karena itu galatnya menyangkut autentikasi paket, bukan sesuatu yang akan dihasilkan penyimpanan sertifikat.
Determinisme penting untuk diagnosis, karena masalah waktu atau jalur meninggalkan jejak berbeda: putus-nyambung berkala, satu arah gagal, atau sesi yang mati hanya di jaringan tertentu. Ketidakcocokan arah gagal pada jabat tangan pertama setiap kali, dan gagal secara identik di mesin lain yang memegang dua berkas yang sama. Baca log pada --verb 4 dan temukan paket pertama yang ditolak, bukan baris terakhir. Jika penolakan itu terjadi sebelum pertukaran sertifikat apa pun, kunci bersama dan arahnya adalah dua hal yang layak diperiksa.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Di mana angka itu tinggal
Panduan OpenVPN 2.6 mendokumentasikan dua tempat untuk arah: argumen kedua tls-auth ketika kunci berada di berkas tersendiri, dan baris key-direction mandiri ketika kunci disisipkan di profil. Keduanya menetapkan nilai yang sama, jadi profil harus memakai satu bentuk atau yang lain, tidak pernah keduanya. Menghilangkannya juga pilihan, dan itu menempatkan kedua peer dalam susunan dua arah yang bekerja bila tidak ada sisi yang menyebut arah. Dua peer yang membawa angka sama tidak berada dalam susunan itu: masing-masing mengharapkan menandatangani di satu slot dan memverifikasi di slot lain, dan keduanya melakukannya dengan cara yang sama.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
Bentuk sisipan adalah direktif pada barisnya sendiri, bukan atribut pada tag pembuka blok kunci, dan menambahkan argumen ke tag itu adalah galat, bukan perubahan arah. Penempatan juga penting: direktif berada di luar blok yang menjadi miliknya, jadi nilai yang ditulis di dalam blok dibaca sebagai materi kunci. Salin susunan yang dimaksudkan distributor profil alih-alih mengarang pasangan, karena profil yang bekerja terhadap satu server mungkin sudah dicerminkan di sisi lain.
Apa yang dibiarkan opsi ini
Opsi ini tidak mengenkripsi lalu lintas aplikasi. tls-auth menaruh HMAC di sekitar paket kanal kontrol, sedangkan kanal data dilindungi kunci sesi yang dinegosiasikan saat jabat tangan, jadi pertanyaan tentang throughput atau cipher tidak ada hubungannya dengan angka arah. Setelan ini juga tidak menambah lapisan enkripsi kedua, dan anggapan itulah yang membuat orang mencari kunci lebih panjang.
Opsi ini tidak berlaku untuk tls-crypt, mekanisme kanal kontrol lain dengan opsi dan penanganan kunci sendiri, dan tidak mengatakan apa pun tentang identitas sertifikat peer mana pun. Jadi kecocokan arah yang bekerja hanya membuktikan kedua ujung sepakat cara mengautentikasi kanal kontrol, bukan bahwa rantai kepercayaan sudah divalidasi.
Sejajarkan pasangan, lalu sambungkan ulang
Bandingkan kedua konfigurasi sebelum mengubah salah satunya, karena menyunting sisi yang sudah benar menggandakan pekerjaan. Grep di bawah menunjukkan mekanisme yang dipilih setiap berkas; jalannya mode verbose menunjukkan apakah kanal kontrol terautentikasi sama sekali. Simpan kedua keluaran, agar perubahan berikutnya dapat dibandingkan dengan keadaan yang diketahui.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Mulai ulang kedua peer setelah setiap perubahan, karena opsi ini dibaca sekali saat mulai dan memuat ulang satu sisi membuat pasangan tidak konsisten selama umur sesi lama. Jika penerapan saat ini bekerja tanpa arah terkonfigurasi, menambahkan setelan pada satu peer mereproduksi kegagalan yang Anda mulai; biarkan keduanya atau konfigurasikan keduanya. Ubah satu ujung setiap kali dan simpan berkas sebelumnya, agar regresi menjadi pengembalian dua menit, bukan pembangunan ulang.
Catat mekanisme, berkas kunci, dan arah untuk setiap ujung dalam catatan penerapan, karena kalau tidak orang berikutnya akan membaca dua berkas serupa dan menganggap angkanya harus saling cocok. Arah adalah detail koordinasi, bukan peningkatan keamanan: ia memisahkan dua arah kanal kontrol dan tidak melakukan apa pun lagi.