Onde se encaixa uma franquia mensal de dados por conta OpenVPN

Uma franquia que é reiniciada sempre que o túnel se reconecta não é um limite, e é exatamente isso que se obtém quando um contador de bytes é aparafusado a um servidor VPN sem um lugar para guardar estado durável. O contador pertence a uma sessão; a franquia pertence a uma pessoa ou a um contrato de dispositivo. Toda a dificuldade do recurso vem desse descompasso, então as verificações abaixo tratam de onde o estado vive e qual camada pode decidir.

Prenda a franquia a uma conta, não a um túnel

Comece nomeando o sujeito da franquia. Uma pessoa pode ter três certificados de dispositivo, e nenhum deles deveria receber um orçamento mensal independente só porque se autenticam separadamente. Um identificador de conta estável que sobrevive a reconexões, novos endereços de túnel e uma mudança para um segundo gateway é a única âncora que uma franquia pode usar. O nome comum de um certificado funciona como essa chave apenas quando sua política de emissão garante uma conta por nome.

Um endereço de túnel atribuído nunca é a resposta. Endereços são reciclados, pools são compartilhados, e a mesma conta pode aparecer duas vezes em dois gateways no mesmo minuto. Se o livro-razão se baseia em um endereço, desconectar e reconectar basta para encher o tanque novamente.

Registre o suficiente por sessão para que a aritmética seja auditável: a conta, o período de cobrança, a instância do gateway, a identidade da sessão, os últimos contadores observados e o total comprometido. Inclua uma geração de início do daemon na identidade da sessão, porque um servidor reiniciado reutiliza IDs de cliente e uma correspondência ingênua herdaria a linha de base anterior.

Fixe a unidade, o sentido e a fronteira de reinício

Quatro definições precisam ser estabelecidas por escrito antes de qualquer coleta começar. A franquia conta os bytes que o cliente envia, os que recebe, ou a soma dos dois? Um gigabyte é 10^9 bytes ou 2^30? A que hora local e em que fuso horário o período vira? E o que exatamente o contador mede, dado que a sobrecarga do túnel e as retransmissões estão incluídas enquanto o tamanho do arquivo da aplicação e a fatura de um provedor não estão?

Nenhuma dessas escolhas está errada, mas a implementação e o número que o cliente vê precisam concordar. Duas metades do mesmo sistema em desacordo sobre GiB, ou sobre uma virada que acontece à meia-noite UTC em vez do horário local, produzem exatamente o tipo de chamado que corrói a confiança em toda a franquia.

Transforme totais de bytes em um único delta cobrado

A interface de gerenciamento reporta linhas BYTECOUNT_CLI periódicas que carregam um ID de cliente mais totais acumulados de bytes em cada direção, e o comando bytecount define com que frequência elas chegam. Do ponto de vista do servidor, o número recebido conta os bytes que o cliente enviou e o número enviado conta os bytes entregues a ele. Defina o intervalo como algo que o livro-razão consiga absorver; um intervalo muito curto compra uma precisão que na prática você não obtém.

Uma restrição molda todo o desenho: o soquete de gerenciamento aceita uma única conexão de controle. Um exportador de monitoramento, uma GUI e seu controlador não podem abrir cada um a sua. Decida qual processo é dono do canal e deixe os outros ler o estado a partir dele, porque essa interface concede ações administrativas e de qualquer forma não deveria ser exposta fora 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

Comprometa as novas linhas de base e o incremento de uso juntos, para que repetir uma amostra não cobre nada em vez de cobrar duas vezes. Um contador que anda para trás é um sinal, não uma dívida: significa que a sessão foi substituída ou que o daemon foi reiniciado, e a resposta correta é reconciliar a identidade da sessão em vez de creditar um valor negativo.

O caminho de desconexão exige o mesmo cuidado. Se um evento final carrega totais de fim de sessão, cobre apenas a diferença em relação à última amostra comprometida. Adicionar o total completo depois que a amostragem periódica já foi cobrada é a contagem dupla mais comum em sistemas de franquia caseiros. Sessões que atravessam uma fronteira de período também precisam de uma regra, já que um único total final não traz informação sobre quando os bytes cruzaram a meia-noite.

Faça o esgotamento negar a admissão, não apenas matar o túnel

Quando uma conta atinge seu limite, duas coisas precisam acontecer: as sessões existentes terminam e as novas são recusadas. O protocolo de gerenciamento oferece client-kill por ID de cliente, o que resolve a primeira metade desde que você enumere toda sessão viva da conta em vez de matar o único endereço que você notou por acaso.

A segunda metade é onde os projetos de franquia falham. Matar sozinho é uma corrida contra o laço de reconexão do cliente, que voltará de bom grado segundos depois. A admissão precisa consultar o livro-razão compartilhado, e em uma implantação com vários gateways essa checagem não pode ser um arquivo por máquina. Cada instância que pode aceitar um login precisa ver o mesmo estado esgotado.

Reconexões baseadas em token merecem um teste próprio. O OpenVPN 2.6 pode validar um token de sessão internamente com auth-gen-token, pulando a chamada de autenticação externa que seu controlador usava para impor o teto. Um token ainda válido, portanto, prova identidade, não franquia restante, e cada nova instância de cliente ainda precisa consultar o livro-razão. Se você ativar management-client-auth em vez disso, o controlador passa a ser o autenticador e herda a obrigação de analisar sozinho o estado da sessão e recusar tokens expirados ou inválidos.

Aceite o excesso que a amostragem cria

A observação periódica mais a desconexão dão a você uma franquia amostrada com uma tolerância conhecida. Um cliente pode ultrapassar em cerca de um intervalo de relatório mais o tempo que o controlador leva para agir, e sessões simultâneas em uma conta multiplicam essa janela. Diga isso na interface em vez de anunciar um corte exato no último byte que você não consegue entregar.

Um teto rígido de verdade é outro problema de engenharia: aplicação dentro do caminho de encaminhamento, ligada à mesma conta através das sessões. Ler contadores mais rápido não é a mesma coisa, e não sobrevive a um cliente que simplesmente abre mais túneis.

Antes da implantação, execute os casos de aceitação que quebram implementações ingênuas: reconexões repetidas, dois dispositivos ao mesmo tempo, reinícios do controlador e do gateway, um evento de desconexão perdido, uma virada no meio da sessão e uma tentativa de reconexão por token logo após o esgotamento. Depois decida o modo de falha para interrupções na contabilidade. Um livro-razão durável protege o uso que você registrou; ele não pode ressuscitar observações que nunca chegaram, e o cliente merece saber em qual dessas duas situações está.