Un seul shaper tc ne plafonne pas chaque client VPN à lui seul

La consigne semble complète : limiter chaque client VPN à 20 Mbit/s. Elle ne l’est pas, et une seule discipline de file sur l’interface du tunnel ne la fournira pas. Par client peut signifier par adresse de tunnel, par appareil ou par compte, et chaque choix classe les paquets différemment. Avant d’écrire une règle, décidez laquelle l’exigence nomme réellement.

Tout ce qui suit porte sur l’écart entre cette phrase et quelque chose qui fonctionne.

Ce que « par client » doit d’abord vouloir dire

Une adresse de tunnel est facile à classer et facile à recycler. Un appareil est plus difficile, car un compte peut en porter plusieurs et un appareil peut détenir plusieurs adresses, surtout avec IPv6. Pour une politique d’équité, le compte est l’unité la plus significative, et la plus difficile à repérer dans un en-tête de paquet. Chaque définition implique sa propre clé de comptage, donc une politique qui dérive entre elles ne fera pas ce que la description affirme.

La direction est le second mot manquant. Envoi, réception et combiné sont trois exigences différentes, et une seule règle de sortie sur une interface couvre rarement les deux chemins.

Choisissez un point où le client est encore visible

Chaque direction se définit par rapport à une interface. Ce qui quitte le tunnel du serveur vers un client distant compte comme réception pour ce client ; ce qu’un client envoie entre dans le tunnel puis sort vers sa destination. Choisissez un point d’ordonnancement pour chaque direction et demandez quels champs y existent. Avant le NAT source, un envoi porte encore l’adresse interne du client ; après traduction, une simple correspondance de source peut ne plus l’identifier.

Sur le chemin chiffré, les en-têtes appartiennent au transport VPN, donc un filtre qui compare les adresses internes n’a rien à comparer. Une conception peut classer plus tôt et remettre une marque à un ordonnanceur ultérieur, mais ce passage doit être délibéré : les marques de paquet, les marques de connexion et les classes d’ordonnanceur sont des états différents, pas une seule valeur transmise.

Les seaux n’apparaissent pas tout seuls

Un seau à jetons attaché à une interface façonne tout trafic qui l’utilise ; il ne frappe pas un seau neuf par adresse source. Une conception par classes trie plutôt le trafic sélectionné en classes, les filtres décidant l’appartenance, et le manuel HTB sépare le débit d’une classe de son plafond lorsque le parent dispose de bande passante libre. Si l’intention est un plafond dur, fixez le plafond et décidez délibérément le comportement d’emprunt ; ne traitez pas chaque chiffre de débit comme un maximum absolu.

Quand l’exigence est par client, deux transferts simultanés devraient se partager une seule allocation. Donner à chaque flux le débit complet est une autre politique, et elle survit à tout test qui ne surveille qu’un seul téléchargement.

Deux appareils, un compte, une allocation ?

Limiter deux adresses d’appareil séparément ne totalise jamais une seule allocation à l’échelle du compte, même lorsque les deux appareils se connectent comme la même personne. Il en va de même pour tout un LAN traduit derrière un seul pair, ou pour des adresses IPv6 supplémentaires que le classifieur n’attendait pas. Gardez l’association adresse-identité à jour, et rappelez-vous qu’une adresse stable simplifie la carte sans authentifier son propriétaire.

Définissez aussi le comportement de rafale et de file. Les seaux à jetons autorisent de courtes rafales au-dessus de la moyenne, et la mise en mémoire tampon ajoute du délai ; policer l’excédent et le mettre en file pour plus tard sont des décisions différentes aux symptômes différents.

Pour valider, lancez deux transferts depuis un client, ajoutez un second client et lisez les compteurs de classe dans chaque direction.