Peristiwa hook OpenVPN: mengapa nama dan stempel waktu bukan kunci

Catatan pemutusan koneksi tiba setelah koneksi kedua dengan nama yang sama sudah dimulai, dan penangan yang memperbarui baris terbaru untuk pengguna itu menutup sesi yang salah. Kesalahannya bukan pada perbandingan stempel waktu. Kesalahannya ada pada anggapan bahwa nama ditambah satu detik penuh mengidentifikasi satu sesi. Peristiwa hook menggambarkan koneksi, dan koneksi memerlukan kunci yang hanya dimilikinya.

Mulailah dari apa arti variabel pemutusan koneksi sebenarnya. Baru setelah itu pilihan pengenal masuk akal.

Apa yang sebenarnya dibawa hook pemutusan

Di Community OpenVPN 2.6, referensi hook time_unix mendefinisikannya sebagai saat klien terhubung; nilai ini ditetapkan sebelum hook koneksi berjalan dan tidak didefinisikan ulang ketika hook pemutusan nanti dipicu. time_duration memberikan panjang sesi itu dalam detik, sehingga akhirnya kira-kira waktu koneksi ditambah durasi. Keduanya detik bulat, dan tidak satu pun merupakan saat basis data Anda memproses peristiwa. Menjaga ketiga waktu itu tetap terpisah itulah yang membuat korelasi bertahan, bukan sekadar terlihat benar selama pengujian.

Aritmetika ini layak dituliskan, karena inilah satu-satunya waktu akhir yang ditawarkan hook itu sendiri. Penundaan pemrosesan dan perbedaan jam antarhost masih berada di luarnya.

Mengapa pasangan yang jelas tidak unik

Memasangkan nama dengan waktu koneksi mempersempit pencarian dan tetap tidak mengidentifikasi sesi. Klien dapat menyambung ulang dalam detik yang sama, sehingga dua sesi dapat berbagi kedua nilai itu. Dua instans daemon, atau penggantian server yang mempertahankan konfigurasi yang sama, dapat menghasilkan pasangan itu dari proses yang berbeda. Alamat terowongan didaur ulang karena alasan yang sama, yang menjadikannya atribut suatu sesi, bukan pengenal untuknya.

Mode kegagalannya senyap. Pemutusan yang terlambat untuk sesi pertama cocok dengan baris terbaru dan menghentikan alokasi yang masih dipakai sesi kedua, sehingga pengguna mengalami kehilangan akses acak yang tidak ia sebabkan. Jumlah baris yang tampak benar sesudahnya membuat masalah itu lebih sulit dikenali.

Dari mana identitas stabil berasal

Antarmuka manajemen memberi setiap klien pengenal instans klien, dan pengenal itu dibatasi pada instans daemon yang menerbitkannya. Kunci eksternal yang dapat dipakai menggabungkan pengenal server yang stabil, epoch yang berubah saat daemon mulai, dan ID klien itu. Epoch penting karena pengenal dimulai ulang bersama proses, dan ID proses telanjang dapat dipakai ulang nanti oleh sesuatu yang tidak terkait.

Variabel lingkungan yang ditetapkan di dalam skrip koneksi anak tidak berpindah ke skrip pemutusan daemon induk yang lebih akhir, karena skrip itu berjalan sebagai proses terpisah dengan lingkungannya sendiri. Jadi menghasilkan UUID saat koneksi hanya setengah solusi. Sisi pemutusan harus dapat menyebut UUID yang sama, yang berarti identitas harus berada di suatu tempat yang dapat dijangkau kedua peristiwa.

Buat penghentian bersyarat dan idempoten

Hentikan berdasarkan pemilik sesi, bukan berdasarkan pengguna. Penangan yang menghapus alokasi apa pun yang saat ini milik suatu nama akhirnya akan menghapus yang salah, dan satu-satunya pertahanan adalah memeriksa bahwa catatan yang dihapus adalah catatan yang digambarkan peristiwa ini.

Antarmuka manajemen menerima satu klien manajemen terhubung pada satu waktu, jadi berintegrasilah dengan pihak yang sudah memilikinya daripada memasang pengamat kedua yang bersaing untuk soket yang sama.

Tangani peristiwa berulang tanpa mengubah hasil dua kali, dan simpan peristiwa yang tidak berpasangan untuk rekonsiliasi alih-alih membuangnya. Panggilan balik pemutusan memiliki syarat siklus hidup yang terdokumentasi dan mungkin tidak pernah datang setelah kerusakan atau penghentian paksa, jadi desain perlu cara merepresentasikan sesi yang peristiwa akhirnya hilang.

Uji kasus-kasus canggung dengan sengaja: dua sambungan ulang dalam satu detik, dua instans daemon, koneksi yang pemrosesannya gagal, dan mulai ulang daemon di tengah sesi. Kunci yang bertahan pada keempatnya adalah kunci yang layak dipercaya.