Een tc-vormer begrens nie elke VPN-kliënt op sy eie nie

Die opdrag klink volledig: beperk elke VPN-kliënt tot 20 Mbit/s. Dit is nie volledig nie, en ’n enkele toustaan-dissipline op die tonnelkoppelvlak sal dit nie lewer nie. Per kliënt kan per tonneladres, per toestel of per rekening beteken, en elke keuse klassifiseer pakkette anders. Voordat jy enige reël skryf, besluit watter een die vereiste werklik noem.

Alles hieronder handel oor die afstand tussen daardie sin en iets wat werk.

Wat "Per kliënt" eers moet beteken

’n Tonneladres is maklik om te klassifiseer en maklik om te herwin. ’n Toestel is moeiliker, want een rekening kan verskeie dra, en ’n toestel kan verskeie adresse hou, veral met IPv6. Vir ’n regverdigheidsbeleid is die rekening die sinvolste eenheid, en die moeilikste om in ’n pakketkop te sien. Elke definisie impliseer sy eie tel-sleutel, so ’n beleid wat tussen hulle ronddryf sal nie doen wat die beskrywing belowe nie.

Rigting is die tweede ontbrekende woord. Op-, af- en gekombineerde laai is drie verskillende vereistes, en ’n enkele uitgaande reël op een koppelvlak dek selde albei paaie.

Kies ’n punt waar die kliënt nog sigbaar is

Elke rigting word teen ’n koppelvlak gedefinieer. Wat die bediener se tonnel na ’n afgeleë kliënt verlaat, geld as aflaai vir daardie kliënt; wat ’n kliënt stuur, kom die tonnel binne en verlaat dan na sy bestemming. Kies ’n skeduleringspunt vir elke rigting en vra watter velde daar bestaan. Voor bron-NAT dra ’n oplaai steeds die kliënt se binne-adres; ná vertaling kan ’n eenvoudige bron-ooreenkoms dit dalk nie meer identifiseer nie.

Op die geënkripteerde pad behoort die koppe aan die VPN-vervoer, so ’n filter wat binne-adresse pas het niks om te pas nie. ’n Ontwerp kan vroeër klassifiseer en ’n merkie aan ’n later skeduleerder oorhandig, maar daardie oorhandiging moet doelbewus wees: pakketmerke, verbindingsmerke en skeduleerderklasse is verskillende toestand, nie een waarde wat saamgedra word nie.

Emmer verskyn nie vanself nie

’n Token-emmer wat aan ’n koppelvlak gekoppel is, vorm watter verkeer dit ook al gebruik; dit skep nie ’n nuwe emmer per bronadres nie. ’n Klasgebaseerde ontwerp sorteer eerder geselekteerde verkeer in klasse, met filters wat lidmaatskap besluit, en die HTB-handleiding skei ’n klas se tempo van sy plafon wanneer die ouer oorblywende bandwydte het. As die bedoeling ’n harde perk is, stel die plafon en besluit die leengedrag doelbewus; moenie elke tempotsyfer as ’n absolute maksimum behandel nie.

Wanneer die vereiste per kliënt is, moet ’n paar oordragte wat gelyktydig loop ’n enkele toelating deel. Om elke vloei die volle tempo te gee is ’n ander beleid, en dit oorleef enige toets wat net een aflaai dophou.

Twee toestelle, een rekening, een toelating?

Om twee toesteladresse afsonderlik te beperk kom nooit op een rekeningwye toelating neer nie, selfs wanneer albei toestelle as dieselfde persoon aanmeld. Dieselfde geld vir ’n hele LAN wat agter een portuur vertaal word, of vir bykomende IPv6-adresse wat die klassifiseerder nooit verwag het nie. Hou die adres-tot-identiteit-assosiasie byderhand, en onthou dat ’n stabiele adres die kaart vereenvoudig sonder om sy eienaar te verifieer.

Definieer ook bars- en tougedrag. Token-emmers laat kort barste bo die gemiddelde toe, en buffering voeg vertraging by; om oortolligheid te poliseer en later in die tou te sit is verskillende besluite met verskillende simptome.

Vir validering, laat twee oordragte van een kliënt loop, voeg ’n tweede kliënt by, en lees die klas-tellers in elke rigting.