Un sol modelador tc no limita cada client VPN per si mateix

La instrucció sona completa: limita cada client VPN a 20 Mbit/s. No ho és, i una sola disciplina de cues a la interfície del túnel no ho lliurarà. Per client pot voler dir per adreça de túnel, per dispositiu o per compte, i cada elecció classifica els paquets de manera diferent. Abans d’escriure cap regla, decidiu quin és el que el requisit nomena realment.

Tot el que segueix tracta de la distància entre aquesta frase i una cosa que funcioni.

Què ha de significar primer «per client»

Una adreça de túnel és fàcil de classificar i fàcil de reciclar. Un dispositiu és més difícil, perquè un compte pot portar-ne diversos, i un dispositiu pot tenir diverses adreces, sobretot amb IPv6. Per a una política d’equitat, el compte és la unitat més significativa i la més difícil de veure en una capçalera de paquet. Cada definició implica la seva pròpia clau de recompte, així que una política que derivi entre elles no farà el que afirma la descripció.

La direcció és la segona paraula que falta. Pujada, baixada i combinada són tres requisits diferents, i una sola regla de sortida en una interfície poques vegades cobreix els dos camins.

Trieu un punt on el client encara sigui visible

Cada direcció es defineix respecte d’una interfície. El que surt del túnel del servidor cap a un client remot compta com a baixada per a aquell client; el que un client envia entra al túnel i després surt cap a la seva destinació. Trieu un punt de planificació per a cada direcció i pregunteu quins camps hi existeixen. Abans del NAT d’origen, una pujada encara porta l’adreça interna del client; després de la traducció, una simple coincidència d’origen potser ja no el identifica.

Al camí xifrat, les capçaleres pertanyen al transport VPN, així que un filtre que fa coincidir adreces internes no té res amb què coincidir. Un disseny pot classificar abans i lliurar una marca a un planificador posterior, però aquest traspàs ha de ser deliberat: les marques de paquet, les marques de connexió i les classes del planificador són estats diferents, no un sol valor que es passa endavant.

Les galledes no apareixen soles

Una galleda de testimonis enganxada a una interfície dona forma a qualsevol trànsit que la faci servir; no encunya una galleda nova per cada adreça d’origen. Un disseny basat en classes, en canvi, ordena el trànsit seleccionat en classes, amb filtres que decideixen la pertinença, i el manual d’HTB separa la taxa d’una classe del seu sostre quan el pare té amplada de banda sobrera. Si la intenció és un límit dur, poseu el sostre i decidiu el comportament de préstec a propòsit; no tracteu cada xifra de taxa com un màxim absolut.

Quan el requisit és per client, un parell de transferències simultànies haurien de repartir-se una sola quota. Donar a cada flux la taxa completa és una altra política, i sobreviu a qualsevol prova que només miri una baixada.

Dos dispositius, un compte, una quota?

Limitar dues adreces de dispositiu per separat mai no suma una sola quota per compte, ni tan sols quan tots dos dispositius inicien sessió com la mateixa persona. El mateix s’aplica a tota una LAN traduïda darrere d’un sol parell, o a adreces IPv6 addicionals que el classificador no esperava. Manteniu actualitzada l’associació entre adreça i identitat, i recordeu que una adreça estable simplifica el mapa sense autenticar-ne el propietari.

Definiu també el comportament d’esclat i de cua. Les galledes de testimonis permeten esclats curts per sobre de la mitjana, i l’emmagatzematge afegeix retard; vigilar l’excés i encuar-lo per a més tard són decisions diferents amb símptomes diferents.

Per validar-ho, executeu dues transferències des d’un client, afegiu un segon client i llegiu els comptadors de classe en cada direcció.