Un solo moldeador tc no limita cada cliente VPN por sí mismo

La instrucción suena completa: limita cada cliente VPN a 20 Mbit/s. No lo está, y una sola disciplina de colas en la interfaz del túnel no lo entregará. Por cliente puede significar por dirección de túnel, por dispositivo o por cuenta, y cada elección clasifica los paquetes de forma distinta. Antes de escribir cualquier regla, decide cuál de ellas nombra realmente el requisito.

Todo lo que sigue trata de la distancia entre esa frase y algo que funcione.

Qué debe significar primero «por cliente»

Una dirección de túnel es fácil de clasificar y fácil de reciclar. Un dispositivo es más difícil, porque una cuenta puede llevar varios y un dispositivo puede tener varias direcciones, sobre todo con IPv6. Para una política de equidad, la cuenta es la unidad más significativa y la más difícil de ver en una cabecera de paquete. Cada definición implica su propia clave de conteo, así que una política que derive entre ellas no hará lo que afirma la descripción.

La dirección es la segunda palabra que falta. Subida, bajada y combinada son tres requisitos distintos, y una sola regla de salida en una interfaz rara vez cubre ambos caminos.

Elija un punto donde el cliente siga siendo visible

Cada dirección se define contra una interfaz. Lo que sale del túnel del servidor hacia un cliente remoto cuenta como bajada para ese cliente; lo que un cliente envía entra en el túnel y luego sale hacia su destino. Elija un punto de planificación para cada dirección y pregunte qué campos existen allí. Antes del NAT de origen, una subida todavía lleva la dirección interna del cliente; tras la traducción, una simple coincidencia de origen puede que ya no lo identifique.

En la ruta cifrada las cabeceras pertenecen al transporte VPN, así que un filtro que hace coincidir direcciones internas no tiene con qué coincidir. Un diseño puede clasificar antes y entregar una marca a un planificador posterior, pero ese traspaso debe ser deliberado: las marcas de paquete, las marcas de conexión y las clases del planificador son estado distinto, no un solo valor que se pasa adelante.

Los cubos no aparecen solos

Un cubo de testigos conectado a una interfaz da forma a cualquier tráfico que lo use; no acuña un cubo nuevo por cada dirección de origen. Un diseño basado en clases, en cambio, ordena el tráfico seleccionado en clases, con filtros que deciden la pertenencia, y el manual de HTB separa la tasa de una clase de su techo cuando el padre tiene ancho de banda de sobra. Si la intención es un tope duro, fije el techo y decida el comportamiento de préstamo a propósito; no trate cada cifra de tasa como un máximo absoluto.

Cuando el requisito es por cliente, un par de transferencias simultáneas deberían repartirse una sola cuota. Dar a cada flujo la tasa completa es otra política, y sobrevive a cualquier prueba que solo mire una bajada.

¿Dos dispositivos, una cuenta, una cuota?

Limitar dos direcciones de dispositivo por separado nunca suma una sola cuota por cuenta, ni siquiera cuando ambos dispositivos inician sesión como la misma persona. Lo mismo se aplica a toda una LAN traducida detrás de un solo par, o a direcciones IPv6 adicionales que el clasificador nunca esperó. Mantenga actualizada la asociación entre dirección e identidad, y recuerde que una dirección estable simplifica el mapa sin autenticar a su dueño.

Defina también el comportamiento de ráfaga y de cola. Los cubos de testigos permiten ráfagas cortas por encima de la media, y el almacenamiento en búfer añade retardo; vigilar el exceso y encolarlo para más tarde son decisiones distintas con síntomas distintos.

Para validar, ejecute dos transferencias desde un cliente, añada un segundo cliente y lea los contadores de clase en cada dirección.