Un solo shaper tc non limita ogni client VPN da solo

L’istruzione sembra completa: limita ogni client VPN a 20 Mbit/s. Non lo è, e una sola disciplina di coda sull’interfaccia del tunnel non la fornirà. Per client può significare per indirizzo del tunnel, per dispositivo o per account, e ogni scelta classifica i pacchetti in modo diverso. Prima di scrivere una regola, decidi quale l’esigenza nomina davvero.

Tutto ciò che segue riguarda la distanza tra quella frase e qualcosa che funziona.

Che cosa deve significare prima «per client»

Un indirizzo del tunnel è facile da classificare e facile da riciclare. Un dispositivo è più difficile, perché un account può portarne diversi e un dispositivo può avere più indirizzi, soprattutto con IPv6. Per una politica di equità l’account è l’unità più significativa, e la più difficile da notare in un’intestazione di pacchetto. Ogni definizione implica la propria chiave di conteggio, quindi una politica che oscilla tra esse non farà ciò che la descrizione afferma.

La direzione è la seconda parola mancante. Caricamento, scaricamento e combinato sono tre requisiti diversi, e una sola regola in uscita su un’interfaccia raramente copre entrambi i percorsi.

Scegli un punto in cui il client è ancora visibile

Ogni direzione è definita rispetto a un’interfaccia. Ciò che lascia il tunnel del server verso un client remoto conta come scaricamento per quel client; ciò che un client invia entra nel tunnel e poi esce verso la sua destinazione. Scegli un punto di pianificazione per ogni direzione e chiedi quali campi esistono lì. Prima del NAT di origine, un caricamento porta ancora l’indirizzo interno del client; dopo la traduzione, una semplice corrispondenza di origine potrebbe non identificarlo più.

Sul percorso cifrato le intestazioni appartengono al trasporto VPN, quindi un filtro che confronta indirizzi interni non ha nulla da confrontare. Un progetto può classificare prima e consegnare un marchio a uno scheduler successivo, ma questo passaggio deve essere deliberato: marchi di pacchetto, marchi di connessione e classi dello scheduler sono stati diversi, non un solo valore trasmesso.

I secchi non compaiono da soli

Un secchio di token agganciato a un’interfaccia modella qualsiasi traffico che lo usi; non conia un secchio nuovo per ogni indirizzo di origine. Un progetto basato su classi invece ordina il traffico selezionato in classi, i filtri decidono l’appartenenza, e il manuale di HTB separa la velocità di una classe dal suo tetto quando il genitore ha banda libera. Se l’intento è un tetto rigido, imposta il tetto e decidi il comportamento di prestito di proposito; non trattare ogni cifra di velocità come massimo assoluto.

Quando l’esigenza è per client, due trasferimenti simultanei dovrebbero dividersi una sola quota. Dare a ogni flusso la velocità piena è un’altra politica, e sopravvive a qualsiasi test che osservi un solo scaricamento.

Due dispositivi, un account, una quota?

Limitare due indirizzi di dispositivo separatamente non si somma mai in una sola quota a livello di account, anche quando entrambi i dispositivi accedono come la stessa persona. Lo stesso vale per un’intera LAN tradotta dietro un solo peer, o per indirizzi IPv6 aggiuntivi che il classificatore non si aspettava. Tieni aggiornata l’associazione indirizzo-identità, e ricorda che un indirizzo stabile semplifica la mappa senza autenticarne il proprietario.

Definisci anche il comportamento di burst e di coda. I secchi di token consentono brevi burst sopra la media, e il buffering aggiunge ritardo; limitare l’eccesso e accodarlo per dopo sono decisioni diverse con sintomi diversi.

Per validare, avvia due trasferimenti da un client, aggiungi un secondo client e leggi i contatori di classe in ogni direzione.