Един tc шейпър не ограничава сам по себе си всеки VPN клиент
Ограничението за клиент изисква идентичност за отчитане, две посоки и точка за класификация. Един шейпър по тунела не е една квота на потребител.
Инструкцията звучи завършена: ограничи всеки VPN клиент до 20 Mbit/s. Тя не е завършена и една дисциплина на опашката върху интерфейса на тунела няма да я осигури. „За клиент“ може да значи за адрес на тунела, за устройство или за акаунт и всеки избор класифицира пакетите различно. Преди да напишете каквото и да е правило, решете кое от тях всъщност назовава изискването.
Всичко по-долу се отнася за разликата между това изречение и нещо, което работи.
Какво първо трябва да означава „за клиент“
Адресът на тунела е лесен за класифициране и лесен за преизползване. Устройството е по-трудно, защото един акаунт може да носи няколко и едно устройство може да държи няколко адреса, особено с IPv6. За политика за справедливост акаунтът е най-смислената единица и най-трудната за откриване в заглавката на пакета. Всяко определение предполага свой ключ за отчитане, така че политика, която се люлее между тях, няма да направи това, което твърди описанието.
Посоката е втората липсваща дума. Качване, сваляне и комбинирано са три различни изисквания, а едно изходящо правило на един интерфейс рядко покрива и двата пътя.
Изберете точка, където клиентът все още се вижда
Всяка посока се дефинира спрямо интерфейс. Това, което напуска тунела на сървъра към отдалечен клиент, се брои за сваляне за този клиент; това, което клиентът изпраща, влиза в тунела и след това излиза към дестинацията си. Изберете точка за планиране за всяка посока и попитайте кои полета съществуват там. Преди NAT на източника качването все още носи вътрешния адрес на клиента; след транслацията просто съвпадение по източник може вече да не го идентифицира.
По шифрования път заглавките принадлежат на транспорта на VPN, така че филтър, който съпоставя вътрешни адреси, няма какво да съпостави. Един дизайн може да класифицира по-рано и да предаде маркер на по-късен планировчик, но това предаване трябва да е умишлено: маркерите на пакети, маркерите на връзки и класовете на планировчика са различно състояние, а не една стойност, предавана нататък.
Кофите не се появяват сами
Кофа с токени, прикачена към интерфейс, оформя какъвто и трафик да я използва; тя не създава нова кофа за всеки адрес на източник. Дизайнът, базиран на класове, вместо това подрежда избрания трафик в класове, филтрите решават членството, а ръководството на HTB разделя скоростта на класа от тавана му, когато родителят има свободна честотна лента. Ако целта е твърд таван, задайте тавана и решете умишлено поведението на заемане; не третирайте всяка цифра за скорост като абсолютен максимум.
Когато изискването е за клиент, два трансфера, които текат едновременно, трябва да си разделят една квота. Даването на всеки поток пълната скорост е друга политика и тя издържа всеки тест, който гледа само едно сваляне.
Две устройства, един акаунт, една квота?
Ограничаването на два адреса на устройства поотделно никога не се събира до една квота за целия акаунт, дори когато двете устройства влизат като един и същ човек. Същото важи за цяла LAN, транслирана зад един партньор, или за допълнителни адреси IPv6, които класификаторът не е очаквал. Поддържайте връзката адрес–идентичност актуална и помнете, че стабилният адрес опростява картата, без да удостоверява собственика ѝ.
Дефинирайте и поведението на изблици и опашка. Кофите с токени позволяват кратки изблици над средното, а буферирането добавя закъснение; полицирането на излишъка и поставянето му на опашка за по-късно са различни решения с различни симптоми.
За проверка пуснете два трансфера от един клиент, добавете втори клиент и прочетете броячите на класовете във всяка посока.