Üks tc-kujundaja ei piira iga VPN-kliendi eraldi
Kliendipõhine piirang vajab loendusidentiteeti, kahte suunda ja klassifitseerimispunkti. Üks kujundaja tunnelil ei ole üks kvoot kasutaja kohta.
Juhend kõlab täielikuna: piira iga VPN-klient 20 Mbit/s peale. See ei ole täielik ja üksainus järjekorradistsipliin tunneliliidesel ei anna seda. Kliendi all võib mõelda tunneli aadressi, seadet või kontot ning iga valik klassifitseerib pakette erinevalt. Enne mis tahes reegli kirjutamist otsusta, millist neist nõue tegelikult nimetab.
Kõik allpool puudutab vahet selle lause ja millegi toimiva vahel.
Mida peab «kliendi kohta» kõigepealt tähendama
Tunneli aadressi on lihtne klassifitseerida ja lihtne ringlusse võtta. Seade on raskem, sest üks konto võib kanda mitut ja seadmel võib olla mitu aadressi, eriti IPv6 puhul. Õigluspoliitika jaoks on konto kõige mõttekam üksus ja paketipäises kõige raskemini märgatav. Iga definitsioon eeldab oma loendusvõtit, seega nende vahel triiviv poliitika ei tee seda, mida kirjeldus väidab.
Suund on teine puuduv sõna. Üleslaadimine, allalaadimine ja kombineeritu on kolm erinevat nõuet ning üksainus väljundreegel ühel liidesel katab harva mõlemat teed.
Vali punkt, kus klient on veel nähtav
Iga suund on määratletud liidese suhtes. See, mis väljub serveri tunnelist kaugkliendi poole, loetakse selle kliendi allalaadimiseks; see, mida klient saadab, siseneb tunnelisse ja väljub seejärel sihtkoha poole. Vali iga suuna jaoks planeerimispunkt ja küsi, millised väljad seal olemas on. Enne lähte-NAT-i kannab üleslaadimine endiselt kliendi sisemist aadressi; pärast tõlkimist ei pruugi lihtne lähtekattuvus seda enam tuvastada.
Krüpteeritud teel kuuluvad päised VPN-transpordile, seega sisemisi aadresse sobitaval filtril pole millegagi sobitada. Disain võib klassifitseerida varem ja anda märgi hilisemale planeerijale, kuid see üleandmine peab olema sihilik: paketimärgid, ühendusemärgid ja planeerija klassid on erinev olek, mitte üks edasi antav väärtus.
Ämbrid ei teki iseenesest
Liidese külge kinnitatud märgiämber kujundab mis tahes liiklust, mis seda kasutab; see ei vermi iga lähteaadressi jaoks uut ämbrit. Klassipõhine disain seevastu sorteerib valitud liikluse klassidesse, filtrid otsustavad kuulumise ja HTB käsiraamat eraldab klassi kiiruse selle laest, kui vanemal on vaba ribalaiust. Kui kavatsus on kõva ülempiir, sea lagi ja otsusta laenamiskäitumine sihilikult; ära käsitle iga kiirusnumbrit absoluutse maksimumina.
Kui nõue on kliendi kohta, peaksid kaks korraga jooksvat ülekannet jagama üht kvooti. Igale voolule täiskiiruse andmine on teine poliitika ja see peab vastu igale testile, mis jälgib ainult üht allalaadimist.
Kaks seadet, üks konto, üks kvoot?
Kahe seadmeaadressi eraldi piiramine ei liitu kunagi üheks kontopõhiseks kvoodiks, isegi kui mõlemad seadmed logivad sisse sama isikuna. Sama kehtib terve LAN-i kohta, mis on tõlgitud ühe peeri taga, või täiendavate IPv6-aadresside kohta, mida klassifitseerija kunagi ei oodanud. Hoia aadressi ja identiteedi seos ajakohasena ning pea meeles, et stabiilne aadress lihtsustab kaarti, ilma et see omanikku autendiks.
Määratle ka purske- ja järjekorrakäitumine. Märgiämbrid lubavad lühikesi purskeid üle keskmise ja puhverdamine lisab viivitust; ülejäägi piiramine ja selle hilisemaks järjekorda panemine on erinevad otsused erinevate sümptomitega.
Kontrollimiseks käivita ühest kliendist kaks ülekannet, lisa teine klient ja loe klassilugejaid kummaski suunas.