Sesi pertama menang: membatasi login OpenVPN sebelum penggusuran

Kebijakan yang mengizinkan satu sesi per akun tampak beres sampai login kedua datang. Ada dua kemungkinan hasil: pendatang baru menggantikan sesi yang sedang berjalan, atau sesi yang berjalan mempertahankan slot dan pendatang baru ditolak. Hanya yang kedua merupakan kebijakan sesi pertama menang. Opsi klien yang paling sering dipakai orang mengaktifkan konkurensi dan karena itu tidak menghasilkan hal tersebut.

Dua kontrak bersembunyi di balik satu pengaturan

Dengan konkurensi dimatikan, koneksi kedua yang membawa nama sertifikat sama dapat menggeser sesi yang sudah berjalan. Menyalakan konkurensi mengizinkan beberapa sesi sekaligus, yang merupakan kebalikan dari batas. Tak satu pun dari kedua keadaan itu merupakan kebijakan penolakan, jadi keputusan harus diambil di tempat lain sepenuhnya.

Tuliskan kontraknya sebelum menerapkan apa pun: siapa yang ditolak, bukti apa yang mengenali sesi yang berjalan, dan apa yang terjadi ketika sesi mati tanpa pemutusan bersih. Kebijakan yang tidak pernah dinyatakan dengan cara itu tidak dapat diuji kemudian.

Penggusuran terjadi sebelum kait koneksi Anda

Pada jalur kode server 2.6, persiapan awal untuk klien baru menghapus instans yang sudah ada dengan nama sama ketika konkurensi dimatikan. Penghapusan itu terjadi sebelum rantai penangan koneksi berjalan. Skrip yang menyadari duplikat dan mengembalikan kegagalan karena itu menolak pendatang baru setelah sesi yang berjalan sudah dibuang - tepat hasil yang ingin dicegah kebijakan. Urutan panggilan balik dalam implementasi upstream adalah satu-satunya jawaban andal untuk build Anda.

Mengambil data berkala dari berkas status juga bukan gerbang. Dua percobaan yang datang bersamaan dapat sama-sama melihat slot kosong sebelum salah satunya menetapkannya, dan keduanya melanjutkan.

Pindahkan keputusan ke autentikasi

Antarmuka manajemen dapat mengambil alih keputusan autentikasi setelah verifikasi sertifikat. Dalam susunan itu pengendali bukan pemantau: ia menerima setiap instans klien yang menghubung dan menjawab apakah instans itu boleh melanjutkan. Karena jawabannya datang sebelum pembentukan, penolakan membiarkan sesi yang berjalan tak tersentuh. Kanal yang sama melaporkan pemutusan, dan begitulah pengendali mengetahui bahwa sebuah slot dilepas secara sah.

Setiap instans baru harus melewati gerbang itu, termasuk penyambungan ulang dan jalur apa pun yang mengautentikasi ulang tanpa permintaan. Gerbang yang tidak pernah dicapai sebagian instans tidak melindungi apa pun, dan kelalaian itu tetap tak terlihat sampai seseorang mencoba jalan pintasnya.

Token dapat melewati gerbang

Setelah token diterbitkan, server dapat memvalidasinya secara internal dan melewati autentikasi eksternal untuk koneksi itu. Panggilan manajemen tidak pernah terjadi, jadi pemeriksaan slot yang diterapkan hanya di sana tidak pernah melihat instans baru. Perilaku itu kenyamanan bagi pengguna dan lubang bagi kebijakan konkurensi. Buat koneksi terautentikasi token melewati pemeriksaan otoritatif yang setara, atau matikan jalur token ketika kebijakan menuntut keputusan pada setiap koneksi.

Jangan menebusnya dengan menerima setiap token tanpa syarat. Token yang kedaluwarsa atau tidak valid tetap harus gagal, dan harus gagal melalui titik keputusan yang sama seperti yang lain.

Ikat reservasi ke instans, bukan ke alamat

Alamat adalah identitas yang lemah: penyambungan ulang dari laptop yang sama dapat datang dari alamat lain, dan kredensial yang disalin dapat datang dari alamat yang sama. Ikat reservasi ke instans klien yang diberikan server, sehingga autentikasi ulang instans yang sudah diterima dikenali sebagai pemilik. Pengenal instans baru harus memperoleh slotnya sendiri melalui keputusan yang pertama menang bahkan ketika ia menyajikan token yang sama.

Lepaskan hanya reservasi milik percobaan yang gagal. Peristiwa pemutusan tertunda dari percobaan lama tidak boleh menghapus slot pemilik yang lebih baru, itulah sebabnya pelepasan menyebut instans dan bukan akun. Setelah pengendali dimulai ulang, cocokkan sesi yang hidup sebelum menerima siapa pun, dan terapkan aturan yang sama pada setiap gateway yang melayani akun.

Putuskan secara terpisah bagaimana slot yang benar-benar usang dipulihkan. Administrator memerlukan cara terdokumentasi untuk membersihkannya, dan jalur itu tidak boleh dapat dijangkau oleh pengguna yang hanya mengeklik sambung ulang.

Uji pasangan yang penting: dua login yang hampir bersamaan, penyambungan ulang setelah pemutusan bersih, autentikasi ulang sesi yang berjalan, pendatang baru yang ditolak, dan pengendali yang dimulai ulang. Dalam setiap kasus sesi yang berjalan harus tetap dapat dipakai dan pendatang baru harus ditolak tanpa kerusakan pada akun lain.