Tünel her yeniden bağlandığında sıfırlanan bir kota sınır değildir ve kalıcı durum için yer olmadan bir VPN sunucusuna bayt sayacı vidalandığında tam olarak bu elde edilir. Sayaç bir oturuma aittir; kota bir kişiye ya da bir cihaz sözleşmesine aittir. Bu özelliğin tüm zorluğu bu uyumsuzluktan gelir, bu yüzden aşağıdaki kontroller durumun nerede yaşadığı ve hangi katmanın karar vermesine izin verildiğiyle ilgilidir.

Kotayı tünele değil, hesaba bağlayın

Kotanın öznesini adlandırarak başlayın. Bir kişi üç cihaz sertifikası tutabilir ve hiçbiri yalnızca ayrı ayrı kimlik doğruladıkları için bağımsız bir aylık bütçe almamalıdır. Yeniden bağlanmalara, yeni tünel adreslerine ve ikinci bir ağ geçidine taşınmaya dayanan kararlı bir hesap tanımlayıcısı, bir kotanın kullanabileceği tek çıpadır. Bir sertifikanın ortak adı bu anahtar olarak yalnızca verme politikanız ad başına bir hesap garanti ettiğinde işe yarar.

Atanmış bir tünel adresi asla cevap değildir. Adresler geri dönüştürülür, havuzlar paylaşılır ve aynı hesap aynı dakikada iki ağ geçidinde iki kez görünebilir. Defter bir adrese göre anahtarlanıyorsa, depoyu yeniden doldurmak için bağlantıyı kesip yeniden bağlanmak yeterlidir.

Her oturum için aritmetiğin denetlenebilir olmasını sağlayacak kadar kayıt tutun: hesap, faturalama dönemi, ağ geçidi örneği, oturum kimliği, son gözlenen sayaçlar ve taahhüt edilen toplam. Oturum kimliğine bir daemon başlangıç nesli ekleyin, çünkü yeniden başlatılan sunucu istemci kimliklerini yeniden kullanır ve naif bir eşleşme önceki temel çizgiyi devralırdı.

Birimi, yönü ve sıfırlama sınırını sabitleyin

Herhangi bir toplama başlamadan önce dört tanım yazılı olarak sabitlenmelidir. Kota istemcinin gönderdiği baytları mı, aldığı baytları mı, yoksa ikisinin toplamını mı sayıyor? Bir gigabayt 10^9 bayt mı yoksa 2^30 mu? Dönem hangi yerel saatte ve hangi saat diliminde dönüyor? Ve sayaç tam olarak neyi ölçüyor, tünelin ek yükü ve yeniden iletimler dahilken uygulama dosyasının boyutu ve sağlayıcının faturası dahil değilken?

Bu seçimlerin hiçbiri yanlış değildir, ancak uygulama ile müşterinin gördüğü sayı uyuşmalıdır. Aynı sistemin iki yarısı GiB konusunda ya da yerel saat yerine UTC gece yarısında gerçekleşen bir dönüş konusunda anlaşamıyorsa, tüm kotaya duyulan güveni aşındıran tam o türden bir bilet üretir.

Bayt toplamlarını tek bir faturalanan farka dönüştürün

Yönetim arayüzü, istemci kimliği ve her yönde birikmiş bayt toplamlarını taşıyan dönemsel BYTECOUNT_CLI satırlarını bildirir ve bytecount komutu bunların ne sıklıkla geldiğini belirler. Sunucu açısından, alınan sayı istemcinin gönderdiği baytları sayar ve gönderilen sayı ona teslim edilen baytları sayar. Aralığı defterin sindirebileceği bir değere ayarlayın; çok kısa bir aralık gerçekte elde etmediğiniz bir hassasiyeti satın alır.

Tek bir kısıt tüm tasarımı şekillendirir: yönetim soketi tek bir denetim bağlantısı kabul eder. Bir izleme dışa aktarıcısı, bir GUI ve denetleyiciniz her biri kendi bağlantısını açamaz. Kanalın hangi sürece ait olduğuna karar verin ve diğerlerinin durumu oradan okumasına izin verin, çünkü bu arayüz yönetici işlemleri verir ve zaten ana makinenin dışına açılmamalıdır.

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

Yeni temel çizgileri ve kullanım artışını birlikte taahhüt edin, böylece bir örneğin yeniden oynatılması iki kez ücretlendirmek yerine hiçbir şey ücretlendirmez. Geriye doğru hareket eden bir sayaç bir sinyaldir, borç değil: oturumun değiştirildiği ya da daemonun yeniden başlatıldığı anlamına gelir ve doğru yanıt negatif bir tutarı alacaklandırmak değil, oturum kimliğini uzlaştırmaktır.

Bağlantı kesme yolu da aynı özeni gerektirir. Son olay oturum sonu toplamlarını taşıyorsa, yalnızca son taahhüt edilen örnekten farkı ücretlendirin. Dönemsel örnekleme zaten ücretlendirildikten sonra tam toplamı eklemek, ev yapımı kota sistemlerindeki en yaygın çift sayımdır. Dönem sınırını aşan oturumların da bir kurala ihtiyacı vardır, çünkü tek bir son toplam baytların gece yarısını ne zaman geçtiğine dair bilgi taşımaz.

Tükenme girişi reddetsin, yalnızca tüneli öldürmesin

Bir hesap sınırına ulaştığında iki şey olmalıdır: mevcut oturumlar sona erer ve yenileri reddedilir. Yönetim protokolü istemci kimliğine göre client-kill sunar; bu, hesabın her canlı oturumunu saydığınız sürece ilk yarıyı halleder, farkına vardığınız tek adresi öldürmek yerine.

İkinci yarı, kota tasarımlarının başarısız olduğu yerdir. Tek başına öldürme, istemcinin yeniden bağlanma döngüsüne karşı bir yarıştır ve o birkaç saniye sonra memnuniyetle geri döner. Giriş, paylaşılan deftere danışmalıdır ve çok ağ geçitli bir kurulumda bu kontrol makine başına bir dosya olamaz. Oturum açmayı kabul edebilen her örnek aynı tükenmiş durumu görmelidir.

Belirteç tabanlı yeniden bağlanmalar kendi testini hak eder. OpenVPN 2.6, bir oturum belirtecini auth-gen-token ile dahili olarak doğrulayabilir ve denetleyicinizin üst sınırı uygulamak için kullandığı harici kimlik doğrulama çağrısını atlar. Dolayısıyla hâlâ geçerli bir belirteç kimliği kanıtlar, kalan kotayı değil, ve her yeni istemci örneği yine de deftere danışmalıdır. Bunun yerine management-client-auth'u etkinleştirirseniz, denetleyici kimlik doğrulayıcı olur ve oturum durumunu kendi başına çözümleyip süresi dolmuş ya da geçersiz belirteçleri reddetme yükümlülüğünü devralır.

Örneklemenin yarattığı aşımı kabul edin

Dönemsel gözlem artı bağlantı kesme, size bilinen bir toleransla örneklenmiş bir kota verir. Bir istemci yaklaşık bir raporlama aralığı artı denetleyicinin harekete geçmesi için gereken süre kadar aşabilir ve tek bir hesaptaki eşzamanlı oturumlar bu pencereyi katlar. Sağlayamayacağınız son bayttaki kesin kesintiyi ilan etmek yerine bunu arayüzde söyleyin.

Gerçek sert bir tavan başka bir mühendislik sorunudur: iletme yolunun içinde, oturumlar boyunca aynı hesaba bağlı yaptırım. Sayaçları daha hızlı okumak aynı şey değildir ve yalnızca daha fazla tünel açan bir istemciye dayanmaz.

Devreye almadan önce naif uygulamaları kıran kabul durumlarını çalıştırın: yinelenen yeniden bağlanmalar, aynı anda iki cihaz, denetleyici ve ağ geçidi yeniden başlatmaları, kaybolan bir bağlantı kesme olayı, oturum ortasında dönem dönüşü ve tükenmeden hemen sonra belirteçle yeniden bağlanma denemesi. Ardından muhasebe kesintileri için arıza moduna karar verin. Kalıcı bir defter kaydettiğiniz kullanımı korur; hiç gelmeyen gözlemleri diriltemez ve müşteri bu iki durumdan hangisinde olduğunu bilmeyi hak eder.

İlgili makaleler