On pertoca una quota mensual de dades per compte d’OpenVPN

Una quota que es reinicia cada cop que el túnel es reconnecta no és un límit, i això és exactament el que obteniu quan es cargola un comptador de bytes en un servidor VPN sense cap lloc on desar estat durador. El comptador pertany a una sessió; la quota pertany a una persona o a un contracte de dispositiu. Tota la dificultat de la funcionalitat ve d’aquest desajustament, així que les comprovacions de sota tracten d’on viu l’estat i quina capa té permís per decidir.

Fixeu la quota a un compte, no a un túnel

Comenceu nomenant el subjecte de la quota. Una persona pot tenir tres certificats de dispositiu, i cap d’ells no hauria de rebre un pressupost mensual independent només perquè s’autentiquen per separat. Un identificador de compte estable que sobrevisqui a reconnexions, adreces de túnel noves i un trasllat a una segona passarel·la és l’única àncora que pot fer servir una quota. El nom comú d’un certificat funciona com a clau només si la vostra política d’emissió garanteix un compte per nom.

Una adreça de túnel assignada no és mai la resposta. Les adreces es reciclen, les pools es comparteixen, i el mateix compte pot aparèixer dues vegades en dues passarel·les en el mateix minut. Si el llibre major es basa en una adreça, desconnectar i tornar a connectar és prou per omplir el dipòsit.

Registreu prou informació per sessió perquè l’aritmètica sigui auditable: el compte, el període de facturació, la instància de passarel·la, la identitat de sessió, els últims comptadors observats i el total compromès. Incloeu una generació d’arrencada del dimoni a la identitat de sessió, perquè un servidor reiniciat reutilitza identificadors de client i una correspondència ingenua heretaria la línia base anterior.

Fixeu la unitat, la direcció i la frontera de reinici

Cal fixar quatre definicions per escrit abans que comenci cap recollida. La quota compta els bytes que el client envia, els que rep, o la suma dels dos? Un gigabyte és 10^9 bytes o 2^30? A quina hora local i en quina zona horària es gira el període? I què mesura exactament el comptador, tenint en compte que la sobrecàrrega del túnel i les retransmissions hi són incloses mentre que la mida del fitxer de l’aplicació i la factura del proveïdor no?

Cap d’aquestes tries no és incorrecta, però la implementació i el número que veu el client han de coincidir. Dues meitats del mateix sistema que no es posen d’acord sobre GiB, o sobre un gir que passa a mitjanit UTC en lloc de l’hora local, produeixen exactament la mena de tiquet que erosiona la confiança en tota la quota.

Convertiu els totals de bytes en un sol delta cobrat

La interfície de gestió informa línies BYTECOUNT_CLI periòdiques que porten un identificador de client més totals acumulats de bytes en cada direcció, i l’ordre bytecount fixa amb quina freqüència arriben. Des del punt de vista del servidor, la xifra rebuda compta els bytes que el client ha enviat i la xifra enviada compta els bytes lliurats a ell. Fixeu l’interval en una cosa que el llibre major pugui absorbir; un interval molt curt compra una precisió que en realitat no obteniu.

Una restricció dóna forma a tot el disseny: el sòcol de gestió accepta una única connexió de control. Un exportador de monitoratge, una GUI i el vostre controlador no poden obrir cadascun la seva. Decidiu quin procés posseeix el canal i deixeu que els altres llegeixin l’estat d’ell, perquè aquesta interfície atorga accions administratives i de tota manera no s’hauria d’exposar fora de l’amfitrió.

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

Comprometeu les noves línies base i l’increment d’ús alhora, perquè reproduir una mostra no cobri res en lloc de cobrar dues vegades. Un comptador que retrocedeix és un senyal, no un deute: vol dir que la sessió s’ha substituït o que el dimoni s’ha reiniciat, i la resposta correcta és reconciliar la identitat de sessió en lloc d’abonar un import negatiu.

El camí de desconnectació necessita la mateixa cura. Si un esdeveniment final porta totals de fi de sessió, cobreu només la diferència respecte de l’última mostra compromesa. Afegir el total complet després que el mostreig periòdic ja s’hagi cobrat és el doble comptatge més habitual en sistemes de quota casolans. Les sessions que travessen una frontera de període també necessiten una regla, ja que un sol total final no porta cap informació sobre quan els bytes van creuar la mitjanit.

Feu que l’esgotament denegui l’admissió, no només mati el túnel

Quan un compte arriba al seu límit, han de passar dues coses: les sessions existents s’acaben i les noves es rebutgen. El protocol de gestió ofereix client-kill per identificador de client, cosa que resol la primera meitat sempre que enumerou cada sessió viva del compte en lloc de matar l’única adreça que us heu fixat.

La segona meitat és on fallen els dissenys de quota. Una mort sola és una cursa contra el bucle de reconnexió del client, que tornarà de bon grat uns segons després. L’admissió ha de consultar el llibre major compartit, i en un desplegament multi-passarel·la aquesta comprovació no pot ser un fitxer per màquina. Cada instància que pugui acceptar un inici de sessió ha de veure el mateix estat esgotat.

Les reconnexions basades en testimonis mereixen la seva pròpia prova. OpenVPN 2.6 pot validar un testimoni de sessió internament amb auth-gen-token, saltant-se la crida d’autenticació externa que el vostre controlador feia servir per fer complir el sostre. Un testimoni encara vàlid, doncs, prova identitat, no quota restant, i cada nova instància de client ha de consultar igualment el llibre major. Si activeu management-client-auth en lloc d’això, el controlador es converteix en autenticador i hereta l’obligació d’analitzar l’estat de sessió i rebutjar testimonis caducats o invàlids pel seu compte.

Accepteu l’excés que crea el mostreig

L’observació periòdica més la desconnectació us donen una quota mostrejada amb una tolerància coneguda. Un client pot superar-la aproximadament en un interval d’informe més el temps que el controlador triga a actuar, i les sessions concurrents en un compte multipliquen aquesta finestra. Digueu-ho a la interfície en lloc d’anunciar un tall exacte a l’últim byte que no podeu lliurar.

Un sostre dur de veritat és un problema d’enginyeria diferent: aplicació dins del camí de reenviament, lligada al mateix compte a través de les sessions. Llegir els comptadors més de pressa no és el mateix, i no sobreviu a un client que simplement obre més túnels.

Abans del desplegament, executeu els casos d’acceptació que trenquen les implementacions ingenues: reconnexions repetides, dos dispositius alhora, reinicis del controlador i de la passarel·la, un esdeveniment de desconnectació perdut, un gir a mig sessió i un intent de reconnexió amb testimoni just després de l’esgotament. Després decidiu el mode de fallada per a les interrupcions de comptabilitat. Un llibre major durador protegeix l’ús que heu registrat; no pot ressuscitar observacions que mai no van arribar, i el client mereix saber en quina d’aquestes dues situacions es troba.