Batas koneksi VPN: status langsung versus riwayat yang disimpan
Batas tiga koneksi memerlukan status slot langsung, bukan riwayat penjelajahan: apa yang harus disimpan mekanisme, apa yang dapat dibuangnya, dan ke mana status itu pergi selanjutnya.
Tiga koneksi bersamaan adalah keputusan penerimaan, dan untuk menjawabnya perlu diketahui slot mana yang terisi saat ini, bukan apa yang terjadi bulan lalu. Layanan dapat menolak sesi keempat dari tabel kecil berisi catatan aktif dan tidak pernah membangun garis waktu sama sekali. Itu pernyataan tentang mekanisme, bukan tentang operator, dan perbedaannya penting saat Anda membaca kebijakan privasi. Model di bawah menunjukkan apa yang dibutuhkan keputusan itu dan apa yang dapat dibuangnya.
Mekanisme: tabel slot, bukan log
Implementasi paling sederhana mengaitkan langganan dengan hingga tiga catatan sesi aktif. Setiap sesi yang diterima mengambil satu slot, dan slot dilepaskan saat layanan memutuskan bahwa sesi itu telah berakhir. Catatan memerlukan identitas yang cukup spesifik sehingga melepaskan satu koneksi tidak melepaskan slot koneksi lain; itulah sebabnya pengenal sesi lebih penting daripada nama akun.
Keterisian dan riwayat adalah struktur data yang berbeda. Keterisian menjawab pertanyaan ya atau tidak tentang masa kini, dan dapat dibuang pada saat sesi berakhir. Riwayat adalah aliran peristiwa yang hanya bisa ditambahi, dan ia bertahan karena seseorang memilih menyimpannya. Layanan dapat memiliki salah satu, keduanya, atau tidak sama sekali.
Perbedaannya tidak terlihat dari luar. Batas koneksi yang terlihat cocok dengan penghitung kecil di memori, tabel basis data bersama, dan arsip peristiwa lengkap dengan dasbor. Tidak ada apa pun pada batas itu yang memberi tahu Anda mana yang sedang berjalan.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Mengapa model langsung tetap memerlukan koordinasi
Koneksi yang hilang mungkin tidak langsung dikenali sebagai berakhir. Gateway menunggu waktu habis, kegagalan keepalive, atau penghentian akuntansi, dan sampai salah satunya tiba slot tetap terisi. Pengguna yang menyambung ulang selama jendela itu melihat penolakan yang tidak ada hubungannya dengan perangkat keempat.
Server yang dimulai ulang harus merekonsiliasi statusnya, dan beberapa gateway yang melayani akun yang sama memerlukan keputusan bersama. Jika tidak, akun dapat melampaui kuotanya dengan menyambung ke lokasi berbeda. Status bersama atau yang dapat dipulihkan menyelesaikan itu, dan status bersama adalah persyaratan desain, bukan bukti pengawasan.
Tidak ada bagian dari koordinasi itu yang memerlukan riwayat penjelajahan. Gateway yang meneruskan paket tidak perlu tahu situs mana yang dikunjungi sesi untuk menghitung sesi, dan kedua aliran data itu biasanya ditangani komponen yang sama sekali berbeda.
Menyimpan hitungan di memori juga tidak membuat fakta terkait menjadi anonim. Selama layanan berjalan, catatan yang terkait langganan mengungkapkan bahwa akun memiliki koneksi aktif, dan baik akses ke status itu maupun masa hidupnya sama-sama layak dipertanyakan.
Ke mana status itu pergi setelahnya
Pertanyaan privasi bukanlah apakah server dapat menghitung. Tanyakan apa yang terjadi pada sesi yang berakhir: apakah catatan dihapus, atau menjadi peristiwa dalam deret pemantauan? Lalu tanyakan komponen lain mana yang melihat peristiwa yang sama, karena log autentikasi, catatan akuntansi, dan cadangan masing-masing dapat menyimpan salinan yang dibuang jalur penegakan.
Akuntansi RADIUS adalah contoh paling jelas. Pasangan Start dan Stop ada untuk mendukung penagihan dan kendali sesi, dan itu membuat catatan koneksi terlepas dari apakah seseorang pernah menanyakannya sebagai riwayat. Layanan yang menegakkan batas melalui akuntansi karena itu menyimpan lebih dari sekadar tabel slot secara konstruksi.
Penghapusan juga punya bentuk. Catatan yang dihapus dari tabel langsung dapat bertahan dalam cadangan yang diambil satu jam sebelumnya, dan masa retensi cadangan itu adalah pernyataan kebijakan tersendiri. Membaca hanya penyimpanan utama memberi jawaban yang tidak lengkap.
Ajukan pertanyaan dalam bentuk bidang
Panduan minimalisasi data RFC 6973 mengaitkan data yang dikumpulkan dan disimpan dengan tujuan yang dilayani. Diterapkan di sini, pertanyaan yang berguna adalah bidang mana yang benar-benar dibutuhkan tugas penerimaan bersamaan, dan tujuan apa yang membenarkan menyimpan masing-masing setelah tugas itu berakhir.
Pernyataan layanan yang tepat memisahkan status koneksi langsung yang digunakan untuk menegakkan kuota dari catatan apa pun yang disimpan setelah penghentian, dan menyebutkan sistem lain dalam cakupan janji itu. Kalimat yang hanya menyatakan bahwa tiga koneksi ditegakkan tidak membuktikan bahwa arsip ada maupun bahwa tidak ada.
Ketika siklus hidup tidak jelas, catat itu sebagai pertanyaan retensi yang belum terjawab alih-alih putusan. Adanya batas bukan bukti riwayat tersembunyi, dan penjelasan status langsung yang masuk akal bukan audit terhadap penyedia.