Di Mana Kuota Data Bulanan Berada per Akun OpenVPN

Kuota yang diatur ulang setiap kali terowongan tersambung ulang bukanlah batas, dan itulah yang Anda dapatkan ketika penghitung byte dipasang ke server VPN tanpa tempat menyimpan status yang tahan lama. Penghitung itu milik satu sesi; kuota milik seseorang atau kontrak perangkat. Semua kesulitan fitur ini berasal dari ketidakcocokan itu, jadi pemeriksaan di bawah ini membahas di mana status hidup dan lapisan mana yang boleh memutuskan.

Kaitkan kuota ke akun, bukan ke terowongan

Mulailah dengan menamai subjek kuota. Satu orang dapat memegang tiga sertifikat perangkat, dan tidak satu pun seharusnya mendapat anggaran bulanan mandiri hanya karena mereka mengautentikasi secara terpisah. Pengenal akun stabil yang bertahan melalui penyambungan ulang, alamat terowongan baru, dan perpindahan ke gateway kedua adalah satu-satunya jangkar yang bisa dipakai kuota. Nama umum sertifikat berfungsi sebagai kunci itu hanya bila kebijakan penerbitan Anda menjamin satu akun per nama.

Alamat terowongan yang ditetapkan tidak pernah menjadi jawabannya. Alamat didaur ulang, kumpulan dibagi, dan akun yang sama dapat muncul dua kali di dua gateway pada menit yang sama. Jika buku besar berkunci pada alamat, memutus dan menyambung ulang sudah cukup untuk mengisi tangki lagi.

Catat cukup banyak per sesi agar aritmetikanya dapat diaudit: akun, periode penagihan, instans gateway, identitas sesi, penghitung terakhir yang diamati, dan total yang telah dikomit. Sertakan generasi mulai daemon dalam identitas sesi, karena server yang dimulai ulang memakai kembali ID klien dan pencocokan naif akan mewarisi garis dasar sebelumnya.

Tetapkan satuan, arah, dan batas pengaturan ulang

Empat definisi harus ditetapkan secara tertulis sebelum pengumpulan apa pun dimulai. Apakah kuota menghitung byte yang dikirim klien, byte yang diterimanya, atau jumlah keduanya? Apakah satu gigabyte 10^9 byte atau 2^30? Pada jam lokal mana dan di zona waktu mana periode bergulir? Dan apa tepatnya yang diukur penghitung, mengingat overhead terowongan dan pengiriman ulang termasuk sementara ukuran berkas aplikasi dan faktur penyedia tidak?

Tidak ada pilihan itu yang salah, tetapi implementasi dan angka yang dilihat pelanggan harus sepakat. Dua bagian dari sistem yang sama yang tidak sepakat soal GiB, atau soal pergantian yang terjadi pada tengah malam UTC alih-alih waktu lokal, menghasilkan persis jenis tiket yang menggerus kepercayaan pada seluruh kuota.

Ubah total byte menjadi satu delta yang ditagih

Antarmuka manajemen melaporkan baris BYTECOUNT_CLI berkala yang membawa ID klien plus total byte kumulatif di setiap arah, dan perintah bytecount menetapkan seberapa sering baris itu datang. Dari sudut pandang server, angka yang diterima menghitung byte yang dikirim klien dan angka yang dikirim menghitung byte yang dikirimkan kepadanya. Atur intervalnya ke sesuatu yang dapat diserap buku besar; interval yang sangat pendek membeli presisi yang sebenarnya tidak Anda dapatkan.

Satu batasan membentuk seluruh desain: soket manajemen menerima satu koneksi kendali saja. Eksportir pemantauan, GUI, dan pengendali Anda tidak dapat masing-masing membuka miliknya sendiri. Putuskan proses mana yang memiliki kanal itu dan biarkan yang lain membaca status darinya, karena antarmuka ini memberikan tindakan administratif dan lagipula tidak boleh diekspos di luar host.

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

Komit garis dasar baru dan kenaikan pemakaian secara bersamaan, sehingga memutar ulang sebuah sampel tidak menagih apa pun alih-alih menagih dua kali. Penghitung yang bergerak mundur adalah sinyal, bukan utang: artinya sesi diganti atau daemon dimulai ulang, dan tanggapan yang benar adalah merekonsiliasi identitas sesi alih-alih mengkredit jumlah negatif.

Jalur pemutusan memerlukan kehati-hatian yang sama. Jika peristiwa akhir membawa total akhir sesi, tagih hanya selisih dari sampel terakhir yang dikomit. Menambahkan total penuh setelah pengambilan sampel berkala sudah ditagih adalah penghitungan ganda paling umum dalam sistem kuota buatan sendiri. Sesi yang melintasi batas periode juga memerlukan aturan, karena satu total akhir tidak membawa informasi tentang kapan byte melewati tengah malam.

Kehabisan menolak masuk, bukan hanya mematikan terowongan

Ketika sebuah akun mencapai batasnya, dua hal harus terjadi: sesi yang ada berakhir dan sesi baru ditolak. Protokol manajemen menyediakan client-kill berdasarkan ID klien, yang menangani separuh pertama asalkan Anda menyebutkan setiap sesi hidup untuk akun itu alih-alih mematikan satu alamat yang kebetulan Anda perhatikan.

Separuh kedua adalah tempat desain kuota gagal. Membunuh saja adalah perlombaan melawan lingkar penyambungan ulang klien, yang akan dengan senang hati kembali beberapa detik kemudian. Penerimaan harus berkonsultasi dengan buku besar bersama, dan pada penerapan multi-gateway pemeriksaan itu tidak bisa berupa berkas per mesin. Setiap instans yang dapat menerima login harus melihat status habis yang sama.

Penyambungan ulang berbasis token layak mendapat ujinya sendiri. OpenVPN 2.6 dapat memvalidasi token sesi secara internal dengan auth-gen-token, melewati panggilan autentikasi eksternal yang dipakai pengendali Anda untuk menegakkan batas. Token yang masih valid karena itu membuktikan identitas, bukan sisa kuota, dan setiap instans klien baru tetap harus berkonsultasi dengan buku besar. Jika Anda mengaktifkan management-client-auth sebagai gantinya, pengendali menjadi pengautentikasi dan mewarisi kewajiban mengurai status sesi serta menolak token kedaluwarsa atau tidak valid sendiri.

Terima kelebihan yang diciptakan pengambilan sampel

Pengamatan berkala plus pemutusan memberi Anda kuota tersampel dengan toleransi yang diketahui. Klien dapat melewati sekitar satu interval pelaporan plus waktu yang dibutuhkan pengendali untuk bertindak, dan sesi bersamaan pada satu akun melipatgandakan jendela itu. Katakan itu di antarmuka alih-alih mengiklankan pemotongan tepat pada byte terakhir yang tidak dapat Anda sediakan.

Plafon keras yang sesungguhnya adalah masalah rekayasa lain: penegakan di dalam jalur penerusan, terikat pada akun yang sama lintas sesi. Membaca penghitung lebih cepat bukan hal yang sama, dan itu tidak bertahan terhadap klien yang sekadar membuka lebih banyak terowongan.

Sebelum peluncuran, jalankan kasus penerimaan yang merusak implementasi naif: penyambungan ulang berulang, dua perangkat sekaligus, mulai ulang pengendali dan gateway, peristiwa pemutusan yang hilang, pergantian periode di tengah sesi, dan upaya penyambungan ulang token tepat setelah kehabisan. Lalu putuskan mode kegagalan untuk gangguan akuntansi. Buku besar yang tahan lama melindungi pemakaian yang Anda catat; ia tidak dapat menghidupkan kembali pengamatan yang tidak pernah tiba, dan pelanggan berhak tahu dalam situasi mana dari keduanya ia berada.