Jeden tc shaper sám o sobě neomezí každého VPN klienta

Instrukce zní úplně: omez každého VPN klienta na 20 Mbit/s. Není úplná a jediná disciplína fronty na rozhraní tunelu to nedodá. „Na klienta“ může znamenat na adresu tunelu, na zařízení nebo na účet, a každá volba klasifikuje pakety jinak. Než napíšete jakékoli pravidlo, rozhodněte, kterou z nich požadavek vlastně jmenuje.

Vše níže se týká vzdálenosti mezi tou větou a něčím, co funguje.

Co musí nejdřív znamenat „na klienta“

Adresa tunelu se snadno klasifikuje a snadno recykluje. Zařízení je těžší, protože jeden účet může nést několik zařízení a zařízení může mít několik adres, zejména s IPv6. Pro politiku spravedlnosti je účet nejsmysluplnější jednotkou a nejhůř se v hlavičce paketu hledá. Každá definice implikuje vlastní klíč počítání, takže politika, která mezi nimi těká, nebude dělat to, co popis tvrdí.

Směr je druhé chybějící slovo. Nahrávání, stahování a kombinace jsou tři různé požadavky a jediné výstupní pravidlo na jednom rozhraní pokryje obě cesty jen zřídka.

Vyberte bod, kde je klient ještě viditelný

Každý směr se definuje vůči rozhraní. Co opouští tunel serveru směrem ke vzdálenému klientovi, se pro toho klienta počítá jako stahování; co klient odešle, vstoupí do tunelu a potom vystoupí k cíli. Vyberte pro každý směr plánovací bod a ptejte se, která pole tam existují. Před zdrojovým NAT nese nahrávání stále vnitřní adresu klienta; po překladu ho jednoduchá shoda zdroje už nemusí identifikovat.

Na šifrované cestě patří hlavičky VPN transportu, takže filtr porovnávající vnitřní adresy nemá co porovnávat. Návrh může klasifikovat dřív a předat značku pozdějšímu plánovači, ale to předání musí být záměrné: značky paketů, značky spojení a třídy plánovače jsou různý stav, ne jedna předávaná hodnota.

Kbelíky nevznikají samy

Kbelík tokenů připojený k rozhraní tvaruje jakýkoli provoz, který ho používá; nevytváří nový kbelík pro každou zdrojovou adresu. Návrh založený na třídách naopak řadí vybraný provoz do tříd, členství rozhodují filtry a příručka HTB odděluje rychlost třídy od jejího stropu, když má rodič volnou šířku pásma. Pokud je záměrem tvrdý strop, nastavte strop a chování vypůjčování rozhodněte záměrně; neberte každé číslo rychlosti jako absolutní maximum.

Když je požadavek na klienta, dvojice přenosů běžících současně by se měla podělit o jednu kvótu. Dát každému toku plnou rychlost je jiná politika a projde každým testem, který sleduje jen jedno stahování.

Dvě zařízení, jeden účet, jedna kvóta?

Oddělené omezení dvou adres zařízení se nikdy nesečte do jedné kvóty na účet, ani když se obě zařízení hlásí jako stejná osoba. Totéž platí pro celou LAN přeloženou za jedním protějškem nebo pro další adresy IPv6, které klasifikátor nečekal. Udržujte asociaci adresy a identity aktuální a pamatujte, že stabilní adresa mapu zjednoduší, aniž by ověřila jejího vlastníka.

Definujte také chování špiček a fronty. Kbelíky tokenů dovolují krátké špičky nad průměrem a bufferování přidává zpoždění; policování přebytku a jeho pozdější zařazení do fronty jsou různá rozhodnutí s různými příznaky.

Pro ověření spusťte dva přenosy z jednoho klienta, přidejte druhého klienta a čtěte čítače tříd v každém směru.