Ien tc-foarmjouwer beheint net elke VPN-klant op himsels

De opdracht klinkt kompleet: behein elke VPN-klant ta 20 Mbit/s. Dat is er net, en ien inkelde wachtrige-dissipline op de tunnelinterface sil it net leverje. Per klant kin per tunneladres, per apparaat of per akkount betsjutte, en elke kar klassifisearret pakketten oars. Foar't jo in regel skriuwe, beslute hokker fan dizze de eask eins neamt.

Alles hjirûnder giet oer de ôfstân tusken dy sin en eat dat wurket.

Wat «per klant» earst betsjutte moat

In tunneladres is maklik te klassifisearjen en maklik te recycljen. In apparaat is hurder, want ien akkount kin ferskate drage, en in apparaat kin ferskate adressen hâlde, benammen mei IPv6. Foar in rjochtfeardigensbelied is it akkount de meast betsjuttingsfolle ienheid, en de minst maklike om yn in pakketkop te sjen. Elke definysje ymplisearret syn eigen telsleutel, dus in belied dat tusken harren driuwt sil net dwaan wat de beskriuwing beweart.

Rjochting is it twadde ûntbrekkende wurd. Oplade, delade en kombinearre binne trije ferskillende easken, en ien inkelde útgongsregel op ien interface dekt selden beide paden.

Kies in punt dêr't de klant noch sichtber is

Elke rjochting wurdt tsjin in interface definiearre. Wat de tunnel fan 'e tsjinner ferlit nei in fiere klant jildt as delade foar dy klant; wat in klant stjoert giet de tunnel yn en ferlit him dêrnei nei syn bestimming. Kies in planningspunt foar elke rjochting en freegje hokker fjilden dêr bestean. Foar boarne-NAT draacht in oplade noch it ynderlike adres fan 'e klant; nei oersetting kin in ienfâldige boarnematch him miskien net mear identifisearje.

Op it fersifere paad hearre de koppen by it VPN-ferfier, dus in filter dat ynderlike adressen oerienkomt hat neat om oerien te kommen. In ûntwerp kin earder klassifisearje en in mark oerdrage oan in lettere planner, mar dy oerdracht moat bewust wêze: pakketmarken, ferbiningmarken en plannerklassen binne ferskillende tastân, net ien wearde dy't trochjûn wurdt.

Emmers ferskine net fansels

In token-emmer oan in interface foarmet elk ferkear dat him brûkt; hy makket gjin nije emmer per boarneadres. In klassebasearre ûntwerp sortearret ynstee selektearre ferkear yn klassen, filters beslute it lidmaatskip, en de HTB-hânlieding skiedt de faasje fan in klasse fan syn plafond as de âlder frije bânbreedte hat. As de bedoeling in hurde limyt is, set it plafond en beslute it lieningsgedrach mei opsetsin; behannelje net elk faasjesifer as in absolút maksimum.

As de eask per klant is, moatte twa oerdrachten dy't tagelyk rinne ien kwota diele. Eltse stream de folsleine faasje jaan is in oar belied, en it oerlibbet elke test dy't mar ien delade sjocht.

Twa apparaten, ien akkount, ien kwota?

Twa apparaatadressen apart beheine komt nea út op ien akkountbrede kwota, sels as beide apparaten har as deselde persoan oanmelde. Itselde jildt foar in hiel LAN dat efter ien peer oerset wurdt, of foar ekstra IPv6-adressen dy't de klassifisearrer nea ferwachte. Hâld de adres-ta-identiteit-ferbining by, en tink deroan dat in stabyl adres de kaart ferienfâldiget sûnder de eigner te autentisearjen.

Definiearje ek burst- en wachtrilegedrach. Token-emmers tastean koarte bursts boppe it gemiddelde, en buffering foeget fertraging ta; it oerskot polisearje en it letter yn 'e wachtrige sette binne ferskillende besluten mei ferskillende symptomen.

Foar falidaasje, rin twa oerdrachten fan ien klant, foegje in twadde klant ta, en lês de klasse-tellers yn elke rjochting.