Onde corresponde unha cota mensual de datos por conta de OpenVPN

Unha cota que se reinicia cada vez que o túnel se reconecta non é un límite, e iso é exactamente o que se obtén cando se atornilla un contador de bytes a un servidor VPN sen un lugar onde gardar estado duradeiro. O contador pertence a unha sesión; a cota pertence a unha persoa ou a un contrato de dispositivo. Toda a dificultade da función vén dese desaxuste, así que as comprobacións de abaixo tratan de onde vive o estado e que capa ten permiso para decidir.

Fixa a cota a unha conta, non a un túnel

Comeza por nomear o suxeito da cota. Unha persoa pode ter tres certificados de dispositivo, e ningún deles debería recibir un orzamento mensual independente só porque se autentican por separado. Un identificador de conta estable que sobreviva a reconexións, novas direccións de túnel e un traslado a unha segunda pasarela é a única áncora que pode usar unha cota. O nome común dun certificado serve como esa chave só cando a túa política de emisión garante unha conta por nome.

Unha dirección de túnel asignada nunca é a resposta. As direccións recíclanse, os pools compártense e a mesma conta pode aparecer dúas veces en dúas pasarelas no mesmo minuto. Se o libro maior se basea nunha dirección, desconectar e volver conectar abonda para encher o depósito.

Rexistra o suficiente por sesión para que a aritmética sexa auditable: a conta, o período de facturación, a instancia da pasarela, a identidade da sesión, os últimos contadores observados e o total comprometido. Inclúe unha xeración de arranque do daemon na identidade da sesión, porque un servidor reiniciado reutiliza identificadores de cliente e unha correspondencia inxenua herdaría a liña base anterior.

Fixa a unidade, a dirección e o límite de reinicio

Cómpre fixar catro definicións por escrito antes de que comece calquera recollida. A cota conta os bytes que o cliente envía, os que recibe ou a suma de ambos? Un gigabyte son 10^9 bytes ou 2^30? A que hora local e en que zona horaria cambia o período? E que mide exactamente o contador, dado que a sobrecarga do túnel e as retransmisións están incluídas mentres que o tamaño do ficheiro da aplicación e a factura dun provedor non?

Ningunha desas escollas é errónea, pero a implementación e o número que ve o cliente deben coincidir. Dúas metades do mesmo sistema que discrepan sobre GiB, ou sobre un cambio que ocorre a medianoite UTC en lugar da hora local, producen exactamente a clase de tícket que erosiona a confianza en toda a cota.

Converte os totais de bytes nun só delta cobrado

A interface de xestión informa liñas BYTECOUNT_CLI periódicas que levan un identificador de cliente máis totais acumulados de bytes en cada dirección, e a orde bytecount fixa con que frecuencia chegan. Desde o punto de vista do servidor, a cifra recibida conta os bytes que o cliente enviou e a cifra enviada conta os bytes entregados a el. Fixa o intervalo en algo que o libro maior poida absorber; un intervalo moi curto compra unha precisión que en realidade non se obtén.

Unha restrición dá forma a todo o deseño: o socket de xestión acepta unha única conexión de control. Un exportador de monitorización, unha GUI e o teu controlador non poden abrir cada un a súa. Decide que proceso posúe a canle e deixa que os demais lean o estado del, porque esta interface concede accións administrativas e en calquera caso non debería exporse fóra do 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

Compromete as novas liñas base e o incremento de uso á vez, para que reproducir unha mostra non cobre nada en lugar de cobrar dúas veces. Un contador que retrocede é un sinal, non unha débeda: significa que a sesión foi substituída ou que o daemon se reiniciou, e a resposta correcta é reconciliar a identidade da sesión en lugar de abonar un importe negativo.

A ruta de desconexión necesita o mesmo coidado. Se un evento final leva totais de fin de sesión, cobra só a diferenza respecto da última mostra comprometida. Engadir o total completo despois de que o mostrexo periódico xa se cobrou é o dobre cómputo máis habitual nos sistemas de cota caseiros. As sesións que cruzan un límite de período tamén necesitan unha regra, xa que un só total final non leva información sobre cando os bytes cruzaron a medianoite.

Fai que o esgotamento denegue a admisión, non só que mate o túnel

Cando unha conta alcanza o seu límite, deben ocorrer dúas cousas: as sesións existentes rematan e as novas rexéitanse. O protocolo de xestión ofrece client-kill por identificador de cliente, o que resolve a primeira metade sempre que enumeres cada sesión viva da conta en lugar de matar a única dirección que se fixou.

A segunda metade é onde fallan os deseños de cota. Unha morte por si soa é unha carreira contra o bucle de reconexión do cliente, que volverá encantado uns segundos despois. A admisión debe consultar o libro maior compartido, e nun despregamento con varias pasarelas esa comprobación non pode ser un ficheiro por máquina. Cada instancia que poida aceptar un inicio de sesión debe ver o mesmo estado esgotado.

As reconexións baseadas en testemuños merecen a súa propia proba. OpenVPN 2.6 pode validar un testemuño de sesión internamente con auth-gen-token, saltando a chamada de autenticación externa que o teu controlador usaba para impoñer o tope. Un testemuño que segue sendo válido, por tanto, demostra identidade, non cota restante, e cada nova instancia de cliente debe seguir consultando o libro maior. Se activas management-client-auth no seu lugar, o controlador convértese en autenticador e herda a obriga de analizar o estado da sesión e rexeitar testemuños caducados ou inválidos pola súa conta.

Acepta o exceso que crea o mostrexo

A observación periódica máis a desconexión danche unha cota mostrexada cunha tolerancia coñecida. Un cliente pode excederse en aproximadamente un intervalo de informe máis o tempo que tarda o controlador en actuar, e as sesións simultáneas nunha conta multiplican esa xanela. Díxoo na interface en lugar de anunciar un corte exacto no último byte que non podes entregar.

Un teito duro de verdade é outro problema de enxeñaría: aplicación dentro da ruta de reenvío, ligada á mesma conta a través das sesións. Ler os contadores máis rápido non é o mesmo, e non sobrevive a un cliente que simplemente abre máis túneles.

Antes do despregamento, executa os casos de aceptación que rompen as implementacións inxenuas: reconexións repetidas, dous dispositivos á vez, reinicios do controlador e da pasarela, un evento de desconexión perdido, un cambio a metade de sesión e un intento de reconexión con testemuño xusto despois do esgotamento. Despois decide o modo de fallo para as interrupcións da contabilidade. Un libro maior duradeiro protexe o uso que rexistraches; non pode resucitar observacións que nunca chegaron, e o cliente merece saber en cal desas dúas situacións está.