Адзін tc-шейпер не абмяжоўвае кожнага кліента VPN сам па сабе
Ліміт на кожнага кліента патрабуе ідэнтычнасці для падліку, двух кірункаў і пункта класіфікацыі. Адзін шейпер на тунелі — не адна квота на карыстальніка.
Інструкцыя гучыць цалкам: абмяжуй кожнага кліента VPN да 20 Mbit/s. Яна не поўная, і адна дысцыпліна чаргі на інтэрфейсе тунеля гэтага не забяспечыць. «На кожнага кліента» можа азначаць на адрас тунеля, на прыладу або на ўліковы запіс, і кожны выбар класіфікуе пакеты па-рознаму. Перш чым пісаць любое правіла, вызначце, якое менавіта называе патрабаванне.
Усё ніжэй тычыцца адлегласці паміж гэтым сказам і тым, што працуе.
Што спачатку павінна азначаць «на кожнага кліента»
Адрас тунеля лёгка класіфікаваць і лёгка перапрацаваць. Прылада складаней, бо адзін уліковы запіс можа несці некалькі прылад, а прылада можа мець некалькі адрасоў, асабліва з IPv6. Для палітыкі справядлівасці ўліковы запіс — самая значная адзінка і самая цяжкая для выяўлення ў загалоўку пакета. Кожнае вызначэнне мае на ўвазе свой ключ падліку, таму палітыка, якая хістаецца паміж імі, не зробіць таго, што абяцае апісанне.
Кірунак — другое прапушчанае слова. Загрузка, спампоўка і сумесны паказнік — тры розныя патрабаванні, і адно правіла выхаду на адным інтэрфейсе рэдка ахоплівае абодва шляхі.
Выберыце пункт, дзе кліент яшчэ бачны
Кожны кірунак вызначаецца адносна інтэрфейса. Тое, што пакідае тунель сервера ў бок аддаленага кліента, лічыцца спампоўкай для гэтага кліента; тое, што кліент адпраўляе, уваходзіць у тунель і потым выходзіць да свайго прызначэння. Выберыце пункт планавання для кожнага кірунку і спытайце, якія палі там існуюць. Да зыходнага NAT загрузка яшчэ нясе ўнутраны адрас кліента; пасля трансляцыі простае супадзенне па крыніцы можа ўжо не ідэнтыфікаваць яго.
На зашыфраваным шляху загалоўкі належаць транспарту VPN, таму фільтр, які супастаўляе ўнутраныя адрасы, не мае з чым супастаўляць. Дызайн можа класіфікаваць раней і перадаць адзнаку позняму планавальніку, але гэтая перадача павінна быць наўмыснай: адзнакі пакетаў, адзнакі злучэнняў і класы планавальніка — гэта розны стан, а не адно значэнне, што перадаецца далей.
Вёдры не з’яўляюцца самі па сабе
Коўш маркераў, прывязаны да інтэрфейса, фармуе любы трафік, які ім карыстаецца; ён не стварае новы коўш для кожнага зыходнага адраса. Класавы дызайн замест гэтага размяркоўвае выбраны трафік па класах, членства вызначаюць фільтры, а кіраўніцтва HTB аддзяляе хуткасць класа ад яго столі, калі ў бацькі ёсць вольная паласа. Калі мэта — жорсткі мяжа, задайце столю і наўмысна вызначце паводзіны запазычання; не разглядайце кожную лічбу хуткасці як абсалютны максімум.
Калі патрабаванне — на кожнага кліента, дзве перадачы адначасова павінны падзяліць адну квоту. Дазволіць кожнаму патоку поўную хуткасць — гэта іншая палітыка, і яна пройдзе любы тэст, які сочыць толькі за адной спампоўкай.
Дзве прылады, адзін уліковы запіс, адна квота?
Абмежаванне двух адрасоў прылад асобна ніколі не складзе адзіную квоту на ўзроўні ўліковага запісу, нават калі абедзве прылады ўваходзяць як адзін і той жа чалавек. Тое ж датычыцца цэлай лакальнай сеткі, якая трансслюецца за адным партнёрам сувязі, або дадатковых адрасоў IPv6, якіх класіфікатар не чакаў. Трымайце сувязь адраса з ідэнтычнасцю актуальнай і памятайце, што стабільны адрас спрашчае карту, але не аўтэнтыфікуе яго ўладальніка.
Вызначыце таксама паводзіны ўсплёскаў і чаргі. Коўшы маркераў дапускаюць кароткія ўсплёскі вышэй за сярэдняе, а буферызацыя дадае затрымку; абмяжоўваць лішак і ставіць яго ў чаргу на пазней — гэта розныя рашэнні з рознымі сімптомамі.
Для праверкі запусціце дзве перадачы з аднаго кліента, дадайце другога кліента і прачытайце лічыльнікі класаў у кожным кірунку.