Peringatan Login VPN: Peristiwa Mana yang Sebenarnya Harus Memicunya?
Keberhasilan autentikasi, tunnel yang terbentuk, dan RADIUS accounting Start adalah tiga klaim berbeda. Pilih yang bisa ditindaklanjuti penerima Anda, lalu korelasikan.
Keberhasilan autentikasi, tunnel yang terbentuk, dan RADIUS accounting Start adalah tiga klaim berbeda, dan email login baru bermakna setelah Anda memilih salah satunya. Sebagian besar rancangan peringatan VPN mencampur ketiganya dan menghasilkan kotak masuk yang tidak dipercaya siapa pun. Keputusannya bergantung pada siapa yang membaca peringatan itu dan apa yang bisa ia lakukan dalam lima menit berikutnya. Jika salah, peringatan menjadi kebisingan yang menyembunyikan satu peristiwa yang Anda butuhkan.
Tiga pertanyaan menentukan pemicunya
Tanyakan siapa yang menerimanya, apa yang akan ia lakukan, dan seberapa cepat tindakan itu harus terjadi. Tim keamanan yang mengawasi penyalahgunaan kredensial menginginkan pola gagal lalu berhasil dari satu akun dalam hitungan menit. Tim operasi yang mengawasi kapasitas menginginkan durasi sesi dan alasan pemutusan, bukan login. Meja bantuan menginginkan identitas sesi agar bisa mencocokkannya dengan tiket.
Jawaban itu menunjuk ke peristiwa yang berbeda, dan tidak ada satu aturan pun yang memenuhi ketiganya. Jika tindakan penerima adalah «telepon pengguna», autentikasi sudah cukup. Jika tindakannya «bebaskan lisensi» atau «pastikan tunnel membawa lalu lintas», hanya pembentukan atau accounting Start yang bisa dipakai. Jika tindakannya «tagih waktunya», Anda perlu catatan Stop, bukan login.
Tuliskan jawabannya sebagai satu kalimat sebelum mengonfigurasi apa pun. «Email ini memberi tahu insinyur jaga bahwa akun X membuka tunnel dari jaringan Y pada waktu Z, sehingga ia dapat memeriksa apakah jendela pemeliharaan dipakai.» Jika Anda tidak dapat mengisi setiap slot, pemicunya belum dipilih.
Cocokkan peristiwa dengan klaim yang Anda buat
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Tabel itu menyembunyikan ketergantungan: setiap baris hanya dapat dipercaya jika gateway mengeluarkannya secara andal dan pengumpul Anda menyimpan bidang yang Anda butuhkan. Bacalah definisi peristiwa untuk versi persis yang Anda jalankan, karena nama «sesi terbentuk» berubah antarversi dan maknanya berubah lebih sering daripada namanya. Ketika definisinya kabur, minta rekaman sesi daripada menebak dari label.
Memperlakukan Access-Accept sebagai penyelesaian semua yang setelahnya adalah kesalahan paling umum. Itu putusan tentang kredensial, bukan sesi. Kesalahan cerminnya adalah membaca kecocokan kebijakan sebagai bukti otorisasi, padahal aturan bisa cocok dan langkah berikutnya tetap bisa gagal.
Satu sesi, satu notifikasi
Satu akun, beberapa perangkat, pengiriman ulang, dan penyambungan ulang: satu email per peristiwa akan salah di kedua arah, menggandakan satu sesi sekaligus memecah sesi lain. Kunci notifikasi pada gateway ditambah pengenal sesi, dan perlakukan nama akun sebagai atribut, bukan kunci. Pengguna dengan laptop dan ponsel dapat memegang dua tunnel sekaligus, dan keduanya layak mendapat barisnya sendiri.
Catatan akuntansi yang dikirim ulang adalah hal normal, jadi hapus duplikat berdasarkan id sesi dan stempel waktu sebelum menyajikan pesan. Sesi berurutan dari perangkat yang sama harus tetap terpisah, dan penyambungan ulang selama jendela pemeliharaan harus tetap terlihat alih-alih melebur ke sesi sebelumnya. Jika pengumpul Anda menulis ulang stempel waktu saat menyerap data, hapus duplikat berdasarkan bidang catatan asli, bukan yang tersimpan.
Catatan Stop yang hilang adalah ketidakpastian, bukan sesi permanen. Mulai ulang gateway, gangguan pengumpul, dan kehilangan UDP semuanya meninggalkan celah, jadi peringatan memerlukan jalur rekonsiliasi yang menanyakan tabel sesi aktif sebelum siapa pun menyimpulkan bahwa tunnel masih hidup.
Pisahkan audit dan notifikasi
Aliran audit dan aliran peringatan memiliki tugas berbeda. Simpan catatan mentah, termasuk akun, gateway, id sesi, stempel waktu, dan alasan penghentian, bahkan ketika email rutin dikelompokkan, ditekan, atau dikirim ke daftar jaga kecil. Ambang keparahan adalah filter pengiriman, bukan pemilihan peristiwa siklus hidup yang hendak Anda umumkan.
Kirim konteks minimum yang diperlukan penerima untuk menemukan catatan terlindungi. Nama akun, alamat internal, dan detail sesi bersifat sensitif, dan email yang mudah diteruskan adalah email yang mudah bocor.
Lalu buktikan dari awal sampai akhir. Jalankan login dan logout normal, penyambungan ulang, dua sesi bersamaan, dan kegagalan pengiriman yang dipaksakan, lalu lacak satu peristiwa dari gateway melalui pengumpul hingga pesan yang terkirim. Jika email tiba tanpa id sesi, kontraknya tidak lengkap. Jika dua email menggambarkan satu sesi, korelasinya rusak. Tidak satu pun masalah itu muncul ketika satu-satunya yang Anda uji adalah pengiriman surat berfungsi.