Um único shaper tc não limita cada cliente VPN por si só

A instrução parece completa: limitar cada cliente VPN a 20 Mbit/s. Não está, e uma única disciplina de filas na interface do túnel não a entregará. Por cliente pode significar por endereço de túnel, por dispositivo ou por conta, e cada escolha classifica os pacotes de forma diferente. Antes de escrever qualquer regra, decida qual delas o requisito realmente nomeia.

Tudo o que segue trata da distância entre essa frase e algo que funcione.

O que «por cliente» deve significar primeiro

Um endereço de túnel é fácil de classificar e fácil de reciclar. Um dispositivo é mais difícil, porque uma conta pode carregar vários e um dispositivo pode ter vários endereços, sobretudo com IPv6. Para uma política de equidade, a conta é a unidade mais significativa e a mais difícil de ver num cabeçalho de pacote. Cada definição implica a sua própria chave de contagem, por isso uma política que oscile entre elas não fará o que a descrição afirma.

A direção é a segunda palavra que falta. Envio, receção e combinado são três requisitos diferentes, e uma única regra de saída numa interface raramente cobre os dois caminhos.

Escolha um ponto onde o cliente ainda seja visível

Cada direção é definida em relação a uma interface. O que sai do túnel do servidor para um cliente remoto conta como receção para esse cliente; o que um cliente envia entra no túnel e depois sai para o seu destino. Escolha um ponto de agendamento para cada direção e pergunte que campos existem ali. Antes do NAT de origem, um envio ainda leva o endereço interno do cliente; após a tradução, uma simples correspondência de origem pode já não o identificar.

No caminho cifrado, os cabeçalhos pertencem ao transporte VPN, pelo que um filtro que compara endereços internos não tem nada a comparar. Um desenho pode classificar mais cedo e entregar uma marca a um agendador posterior, mas essa passagem tem de ser deliberada: marcas de pacote, marcas de ligação e classes do agendador são estados diferentes, não um único valor transmitido.

Os baldes não aparecem sozinhos

Um balde de tokens ligado a uma interface molda qualquer tráfego que o use; não cunha um balde novo por cada endereço de origem. Um desenho baseado em classes, em vez disso, ordena o tráfego selecionado em classes, com filtros a decidir a pertença, e o manual do HTB separa a taxa de uma classe do seu teto quando o pai tem largura de banda sobrante. Se a intenção é um teto rígido, defina o teto e decida o comportamento de empréstimo de propósito; não trate cada número de taxa como máximo absoluto.

Quando o requisito é por cliente, um par de transferências simultâneas deveria repartir uma só cota. Dar a cada fluxo a taxa completa é outra política, e sobrevive a qualquer teste que observe apenas uma transferência.

Dois dispositivos, uma conta, uma cota?

Limitar dois endereços de dispositivo em separado nunca soma uma única cota ao nível da conta, mesmo quando ambos os dispositivos iniciam sessão como a mesma pessoa. O mesmo se aplica a toda uma LAN traduzida atrás de um único par, ou a endereços IPv6 adicionais que o classificador nunca esperou. Mantenha atualizada a associação entre endereço e identidade, e lembre-se de que um endereço estável simplifica o mapa sem autenticar o seu dono.

Defina também o comportamento de rajada e de fila. Os baldes de tokens permitem rajadas curtas acima da média, e o buffering acrescenta atraso; policiar o excesso e colocá-lo em fila para mais tarde são decisões diferentes com sintomas diferentes.

Para validar, execute duas transferências a partir de um cliente, acrescente um segundo cliente e leia os contadores de classe em cada direção.