Di Mana Kuota Data Bulanan Berada bagi Setiap Akaun OpenVPN
Kuota yang ditetapkan semula pada setiap sambungan semula bukan had. Jejaki penggunaan mengikut akaun, caj setiap perbezaan bait sekali, dan jadikan kehabisan menghalang kemasukan.
Kuota yang ditetapkan semula setiap kali terowong menyambung semula bukan had, dan itulah yang anda peroleh apabila pembilang bait dipasang pada pelayan VPN tanpa tempat untuk menyimpan keadaan tahan lama. Pembilang itu milik satu sesi; kuota milik seseorang atau kontrak peranti. Semua kesukaran ciri ini datang daripada ketidakpadanan itu, jadi pemeriksaan di bawah menyentuh di mana keadaan hidup dan lapisan mana yang dibenarkan membuat keputusan.
Ikat kuota pada akaun, bukan pada terowong
Mulakan dengan menamakan subjek kuota. Seseorang boleh memegang tiga sijil peranti, dan tiada satu pun daripadanya patut mendapat belanjawan bulanan bebas hanya kerana ia mengesahkan diri secara berasingan. Pengecam akaun stabil yang bertahan melalui sambungan semula, alamat terowong baharu dan perpindahan ke get laluan kedua ialah satu-satunya sauh yang boleh digunakan oleh kuota. Nama umum sijil berfungsi sebagai kunci itu hanya apabila dasar pengeluaran anda menjamin satu akaun bagi setiap nama.
Alamat terowong yang diberikan tidak pernah menjadi jawapannya. Alamat dikitar semula, kolam dikongsi, dan akaun yang sama boleh muncul dua kali pada dua get laluan dalam minit yang sama. Jika buku besar berkunci pada alamat, memutuskan dan menyambung semula sudah cukup untuk mengisi tangki semula.
Rekod secukupnya bagi setiap sesi supaya aritmetik boleh diaudit: akaun, tempoh pengebilan, contoh get laluan, identiti sesi, pembilang terakhir yang diperhatikan dan jumlah yang telah komited. Sertakan generasi permulaan daemon dalam identiti sesi, kerana pelayan yang dimulakan semula menggunakan semula ID klien dan padanan naif akan mewarisi garis dasar sebelumnya.
Tetapkan unit, arah dan sempadan penetapan semula
Empat definisi mesti ditetapkan secara bertulis sebelum sebarang pengumpulan bermula. Adakah kuota mengira bait yang dihantar oleh klien, bait yang diterimanya, atau jumlah kedua-duanya? Adakah satu gigabait ialah 10^9 bait atau 2^30? Pada jam tempatan yang mana dan dalam zon waktu yang mana tempoh itu bergolek? Dan apakah sebenarnya yang diukur oleh pembilang, memandangkan overhed terowong dan penghantaran semula termasuk manakala saiz fail aplikasi dan invois pembekal tidak?
Tiada satu pun pilihan itu salah, tetapi pelaksanaan dan nombor yang dilihat pelanggan mesti bersetuju. Dua separuh sistem yang sama yang tidak bersetuju tentang GiB, atau tentang pertukaran yang berlaku pada tengah malam UTC dan bukannya waktu tempatan, menghasilkan jenis tiket yang menghakis kepercayaan terhadap seluruh kuota.
Tukar jumlah bait menjadi satu delta yang dicaj
Antara muka pengurusan melaporkan baris BYTECOUNT_CLI berkala yang membawa ID klien serta jumlah bait terkumpul dalam setiap arah, dan arahan bytecount menetapkan berapa kerap ia tiba. Dari sudut pandangan pelayan, angka yang diterima mengira bait yang dihantar oleh klien dan angka yang dihantar mengira bait yang disampaikan kepadanya. Tetapkan selang pada sesuatu yang boleh diserap oleh buku besar; selang yang sangat pendek membeli ketepatan yang sebenarnya tidak anda peroleh.
Satu kekangan membentuk seluruh reka bentuk: soket pengurusan menerima satu sambungan kawalan sahaja. Pengeksport pemantauan, GUI dan pengawal anda tidak boleh membuka masing-masing. Tentukan proses mana yang memiliki saluran itu dan biarkan yang lain membaca keadaan daripadanya, kerana antara muka ini memberikan tindakan pentadbiran dan ia tidak sepatutnya didedahkan di luar hos.
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
Komited garis dasar baharu dan kenaikan penggunaan bersama-sama, supaya memainkan semula sampel tidak mencaj apa-apa dan bukannya mencaj dua kali. Pembilang yang bergerak ke belakang ialah isyarat, bukan hutang: ia bermakna sesi telah diganti atau daemon dimulakan semula, dan tindak balas yang betul ialah mendamaikan identiti sesi dan bukannya mengkreditkan jumlah negatif.
Laluan pemutusan memerlukan penjagaan yang sama. Jika peristiwa akhir membawa jumlah akhir sesi, caj hanya perbezaan daripada sampel terakhir yang dikomit. Menambah jumlah penuh selepas persampelan berkala telah dicaj ialah pengiraan berganda yang paling biasa dalam sistem kuota buatan sendiri. Sesi yang merentasi sempadan tempoh juga memerlukan peraturan, kerana satu jumlah akhir tidak membawa maklumat tentang bila bait melintasi tengah malam.
Kehabisan menolak kemasukan, bukan hanya mematikan terowong
Apabila akaun mencapai hadnya, dua perkara mesti berlaku: sesi sedia ada tamat, dan yang baharu ditolak. Protokol pengurusan menyediakan client-kill mengikut ID klien, yang mengendalikan separuh pertama asalkan anda menyenaraikan setiap sesi hidup untuk akaun itu dan bukannya mematikan satu alamat yang kebetulan anda perhatikan.
Separuh kedua ialah tempat reka bentuk kuota gagal. Membunuh sahaja ialah perlumbaan dengan gelung sambungan semula klien, yang akan kembali dengan senang hati beberapa saat kemudian. Kemasukan mesti merujuk buku besar bersama, dan dalam penggunaan berbilang get laluan pemeriksaan itu tidak boleh menjadi fail bagi setiap mesin. Setiap contoh yang boleh menerima log masuk mesti melihat keadaan habis yang sama.
Sambungan semula berasaskan token wajar mendapat ujiannya sendiri. OpenVPN 2.6 boleh mengesahkan token sesi secara dalaman dengan auth-gen-token, melangkau panggilan pengesahan luaran yang digunakan oleh pengawal anda untuk menguatkuasakan had. Oleh itu token yang masih sah membuktikan identiti, bukan baki kuota, dan setiap contoh klien baharu masih mesti merujuk buku besar. Jika anda mengaktifkan management-client-auth sebaliknya, pengawal menjadi pengesah dan mewarisi kewajipan untuk menganalisis keadaan sesi sendiri dan menolak token yang tamat tempoh atau tidak sah.
Terima lebihan yang dicipta oleh persampelan
Pemerhatian berkala serta pemutusan memberi anda kuota tersampel dengan toleransi yang diketahui. Klien boleh melebihi kira-kira satu selang pelaporan serta masa yang diambil oleh pengawal untuk bertindak, dan sesi serentak pada satu akaun menggandakan tetingkap itu. Katakan perkara itu dalam antara muka dan bukannya mengiklankan pemotongan tepat pada bait terakhir yang tidak dapat anda sediakan.
Siling keras yang sebenar ialah masalah kejuruteraan yang berbeza: penguatkuasaan di dalam laluan penghantaran, terikat pada akaun yang sama merentas sesi. Membaca pembilang dengan lebih pantas bukan perkara yang sama, dan ia tidak bertahan terhadap klien yang hanya membuka lebih banyak terowong.
Sebelum pelancaran, jalankan kes penerimaan yang memecahkan pelaksanaan naif: sambungan semula berulang, dua peranti sekali gus, permulaan semula pengawal dan get laluan, peristiwa pemutusan yang hilang, pertukaran tempoh di tengah sesi, dan percubaan sambungan semula token sejurus selepas kehabisan. Kemudian tentukan mod kegagalan untuk gangguan perakaunan. Buku besar tahan lama melindungi penggunaan yang anda rekodkan; ia tidak boleh menghidupkan semula pemerhatian yang tidak pernah tiba, dan pelanggan berhak tahu dalam situasi mana antara kedua-duanya dia berada.