Un só moldeador tc non limita cada cliente VPN por si mesmo

A instrución soa completa: limita cada cliente VPN a 20 Mbit/s. Non o está, e unha soa disciplina de colas na interface do túnel non o vai entregar. Por cliente pode significar por enderezo de túnel, por dispositivo ou por conta, e cada elección clasifica os paquetes de forma distinta. Antes de escribir calquera regra, decide cal delas nomea realmente o requisito.

Todo o que segue trata da distancia entre esa frase e algo que funcione.

Que debe significar primeiro «por cliente»

Un enderezo de túnel é doado de clasificar e doado de reciclar. Un dispositivo é máis difícil, porque unha conta pode levar varios e un dispositivo pode ter varios enderezos, sobre todo con IPv6. Para unha política de equidade, a conta é a unidade máis significativa e a máis difícil de ver nunha cabeceira de paquete. Cada definición implica a súa propia clave de reconto, así que unha política que derive entre elas non fará o que afirma a descrición.

A dirección é a segunda palabra que falta. Subida, baixada e combinada son tres requisitos distintos, e unha soa regra de saída nunha interface raramente cobre os dous camiños.

Escolla un punto onde o cliente aínda sexa visible

Cada dirección defínese contra unha interface. O que sae do túnel do servidor cara a un cliente remoto conta como baixada para ese cliente; o que un cliente envía entra no túnel e despois sae cara ao seu destino. Escolla un punto de planificación para cada dirección e pregunte que campos existen alí. Antes do NAT de orixe, unha subida aínda leva o enderezo interno do cliente; despois da tradución, unha simple coincidencia de orixe pode que xa non o identifique.

Na ruta cifrada as cabeceiras pertencen ao transporte VPN, así que un filtro que fai coincidir enderezos internos non ten con que coincidir. Un deseño pode clasificar antes e entregar unha marca a un planificador posterior, pero ese traspaso debe ser deliberado: as marcas de paquete, as marcas de conexión e as clases do planificador son estado distinto, non un só valor que se pasa adiante.

Os cubos non aparecen sós

Un cubo de testemuños conectado a unha interface dá forma a calquera tráfico que o use; non acuña un cubo novo por cada enderezo de orixe. Un deseño baseado en clases, en cambio, ordena o tráfico seleccionado en clases, con filtros que deciden a pertenza, e o manual de HTB separa a taxa dunha clase do seu teito cando o pai ten ancho de banda de sobra. Se a intención é un tope duro, fixe o teito e decida o comportamento de préstamo a propósito; non trate cada cifra de taxa como un máximo absoluto.

Cando o requisito é por cliente, un par de transferencias simultáneas deberían repartirse unha soa cota. Darlle a cada fluxo a taxa completa é outra política, e sobrevive a calquera proba que só mire unha baixada.

Dous dispositivos, unha conta, unha cota?

Limitar dous enderezos de dispositivo por separado nunca suma unha soa cota por conta, nin sequera cando ambos os dispositivos inician sesión como a mesma persoa. O mesmo se aplica a toda unha LAN traducida detrás dun só par, ou a enderezos IPv6 adicionais que o clasificador nunca esperou. Manteña actualizada a asociación entre enderezo e identidade, e lembre que un enderezo estable simplifica o mapa sen autenticar o seu dono.

Defina tamén o comportamento de ráfaga e de cola. Os cubos de testemuños permiten ráfagas curtas por riba da media, e o almacenamento en búfer engade atraso; vixiar o exceso e encolalo para máis tarde son decisións distintas con síntomas distintos.

Para validar, execute dúas transferencias desde un cliente, engada un segundo cliente e lea os contadores de clase en cada dirección.