duplicate-cn memberi dua perangkat satu identitas, bukan dua

Salin profil ke tablet, sambungkan, dan laptop terlempar keluar. Tambahkan duplicate-cn, keduanya tetap tersambung, dan masalahnya tampak beres sampai kedua perangkat berebut alamat tunnel yang sama atau satu tablet hilang membuat seluruh akun offline. Opsi ini mengubah satu hal dan hanya satu hal: apakah server mengizinkan sesi kedua di bawah nama yang sudah pernah dilihatnya. Semua yang orang harapkan diperbaikinya, dari independensi perangkat sampai pengalamatan per perangkat dan pencabutan selektif, tetap dilakukan oleh identitas, dan identitas di sini adalah sertifikat.

Mitos: sesi kedua adalah identitas kedua

Intuisinya adalah dua koneksi harus dua klien, dan dua klien seharusnya dua perangkat dengan haknya sendiri. Server tidak memodelkannya begitu. Ia melihat satu nama umum, dan dengan duplicate-cn aktif ia menerima lebih dari satu sesi hidup yang membawa nama itu, masing-masing mendapat status sesinya sendiri di daemon.

Tidak ada bagian dari penerimaan itu yang menyentuh verifikasi sertifikat. Sertifikat yang sama tetap menjadi kredensial, kunci yang sama tetap menjadi kunci privat, dan kebijakan apa pun yang bertumpu pada subjek sertifikat tetap mengarah ke nilai yang sama dua kali. Sesi kedua adalah soket kedua, bukan identitas kedua.

Perbedaan itu tidak terlihat selama semuanya berjalan. Ia menjadi sangat terlihat pada saat Anda harus membedakan kedua perangkat, yang biasanya adalah hari ketika salah satunya hilang.

Apa yang benar-benar berubah ketika dua sesi berbagi satu nama

Tanpa opsi ini, koneksi baru di bawah nama umum yang sudah tersambung menggeser sesi sebelumnya. Itulah sebabnya laptop terlempar saat tablet tersambung, dan itu adalah penjaga ambiguitas yang disengaja, bukan bug. Dengan opsi ini, kedua sesi tetap hidup dan server melacaknya secara terpisah per sesi, bukan per perangkat.

Setiap sesi tetap mendapat koneksi luarnya sendiri dan kunci hasil negosiasinya sendiri, jadi throughput bersamaan benar-benar bersamaan. Yang mereka bagi adalah semua yang diturunkan dari kredensial: pencarian kebijakan, konfigurasi khusus klien, identitas log, dan pencabutan. Status sesi milik koneksi dan mati bersamanya, sementara fakta tingkat kredensial bertahan untuk keduanya. Itu sebabnya keluaran status dapat mencantumkan nama yang sama dua kali sementara penghitungnya tetap terpisah.

Pastikan apa yang sebenarnya dilakukan build Anda sebelum merancang di atasnya, karena efek opsi ditentukan oleh opsi itu sendiri, bukan oleh cerita yang beredar:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

Alamat statis yang Anda kira telah Anda tetapkan

Konfigurasi per klien dicari berdasarkan nama, dan di situlah jebakannya. Berkas client-config-dir yang dinamai menurut nama umum berlaku untuk setiap perangkat yang memakai nama itu, sehingga ifconfig-push di dalamnya memberi kedua perangkat alamat tunnel yang sama. Sesi kedua entah gagal terbentuk atau bertabrakan dengan cara yang tampak seperti kerusakan routing.

Kumpulan dinamis berperilaku lebih baik secara kebetulan, karena setiap sesi dialokasikan alamat dari kumpulan secara mandiri. Itu tetap tidak memberi Anda alamat stabil per perangkat, dan jelas tidak memberi Anda kebijakan per perangkat yang terikat pada alamat itu.

Jika penerapan memakai username-as-common-name, kunci pencariannya menjadi nama pengguna yang terautentikasi alih-alih subjek sertifikat, dan tabrakan yang sama menyusul bagi siapa pun yang masuk dua kali. Nama yang menggerakkan konfigurasi harus unik per perangkat agar konfigurasi per perangkat bermakna.

Apa yang tidak bisa dilakukan identitas bersama saat pencabutan

Pencabutan bekerja pada sertifikat, bukan pada nama tampilan dan bukan pada sesi. Cabut sertifikat itu dan setiap perangkat yang memegang salinannya kehilangan akses sekaligus, termasuk yang ada di kantor yang tidak ingin diganggu siapa pun. Pertahankan dan perangkat yang hilang tetap berfungsi, karena tidak ada apa pun dalam protokol yang membedakannya dari salinan yang disetujui.

Log mewarisi ambiguitas yang sama. Keluaran status menampilkan satu nama umum dan satu alamat nyata, dan keduanya bisa menjadi milik perangkat mana pun. Tinjauan insiden yang perlu tahu mesin mana melakukan apa tidak dapat menjawab pertanyaan itu dari catatan VPN sendiri, seberapa rinci pun tingkat lognya.

Tidak ada jalan pintas kriptografis untuk ini. Dua perangkat yang menyajikan sertifikat yang sama, bagi server, adalah peserta yang sama dua kali, dan skema apa pun yang berpura-pura sebaliknya hanyalah konvensi penamaan, bukan kendali.

Kapan berbagi tepat, dan bagaimana membatasinya

Berbagi punya kegunaan sah: akun laboratorium yang dipakai beberapa mesin uji, atau rumah tangga yang perangkatnya dikelola bersama dan kerincian pencabutan tidak penting. Dalam kasus itu, aktifkan opsi ini dengan sengaja, jauhkan kredensial bersama dari kebijakan per perangkat, dan beri ruang pada kumpulan agar sesi tidak bertabrakan pada satu alamat.

Untuk apa pun yang membutuhkan alamat terpisah, log terpisah, atau penghapusan terpisah, terbitkan sertifikat terpisah lewat jalur pendaftaran biasa. Itu memberi setiap sistem hilir objek tersendiri untuk dijadikan tumpuan, dan opsi ini berhenti penting karena namanya sudah unik.

Jalur mana pun yang Anda pilih, ujilah model pengelolaan, bukan proses masuknya. Sambungkan kedua perangkat, pastikan keduanya memegang alamat berbeda, lalu simulasikan kehilangan dan periksa bahwa Anda dapat menghapus tepat satu di antaranya. Manual openvpn(8) menetapkan cakupan opsi; prosedur penghapusan Anda yang menetapkan apakah berbagi benar-benar dapat diterima.