Один шейпер tc сам собою не обмежує кожного клієнта VPN

Інструкція звучить повно: обмежити кожного клієнта VPN до 20 Mbit/s. Але вона не повна, і одна дисципліна черги на інтерфейсі тунелю цього не забезпечить. «На клієнта» може означати на адресу тунелю, на пристрій або на обліковий запис, і кожен вибір класифікує пакети по-різному. Перш ніж писати будь-яке правило, вирішіть, який саме з них називає вимога.

Усе нижче — про відстань між цим реченням і чимось, що працює.

Що спершу має означати «на клієнта»

Адресу тунелю легко класифікувати й легко перевикористати. Пристрій складніший, бо один обліковий запис може нести кілька, а пристрій може мати кілька адрес, особливо з IPv6. Для політики справедливості обліковий запис — найосмисленіша одиниця і найважча для виявлення в заголовку пакета. Кожне визначення передбачає власний ключ підрахунку, тож політика, що дрейфує між ними, не зробить того, що обіцяє опис.

Напрямок — друге слово, якого бракує. Вивантаження, завантаження й сумарне — три різні вимоги, і одне правило виходу на одному інтерфейсі рідко покриває обидва шляхи.

Виберіть точку, де клієнт ще видно

Кожен напрямок визначається відносно інтерфейсу. Те, що залишає тунель сервера в бік віддаленого клієнта, вважається завантаженням для цього клієнта; те, що клієнт надсилає, входить у тунель і потім виходить до свого призначення. Виберіть точку планування для кожного напрямку і запитайте, які поля там існують. До NAT джерела вивантаження ще несе внутрішню адресу клієнта; після трансляції простий збіг за джерелом може його вже не ідентифікувати.

На зашифрованому шляху заголовки належать транспорту VPN, тож фільтру, що зіставляє внутрішні адреси, нема чого зіставляти. Проєкт може класифікувати раніше й передати мітку пізнішому планувальнику, але ця передача має бути навмисною: мітки пакетів, мітки з’єднань і класи планувальника — це різний стан, а не одне передане далі значення.

Ведра не з’являються самі

Ведро токенів, прив’язане до інтерфейсу, формує будь-який трафік, що його використовує; воно не створює нове ведро на кожну адресу джерела. Проєкт на основі класів натомість розкладає вибраний трафік за класами, фільтри вирішують членство, а посібник HTB відокремлює швидкість класу від його стелі, коли в батька є вільна смуга. Якщо мета — жорстка межа, задайте стелю і навмисно вирішіть поведінку позичання; не вважайте кожну цифру швидкості абсолютним максимумом.

Коли вимога на клієнта, дві одночасні передачі мають поділити одну квоту. Давати кожному потоку повну швидкість — інша політика, і вона проходить будь-який тест, що стежить лише за одним завантаженням.

Два пристрої, один обліковий запис, одна квота?

Роздільне обмеження двох адрес пристроїв ніколи не додається до однієї квоти на рівні облікового запису, навіть коли обидва пристрої входять як та сама особа. Те саме стосується всієї локальної мережі, трансльованої за одним партнером, або додаткових адрес IPv6, яких класифікатор зовсім не очікував. Тримайте зв’язок адреси та ідентичності актуальним і пам’ятайте, що стабільна адреса спрощує карту, але не засвідчує власника.

Визначте також поведінку сплесків і черги. Ведра токенів дозволяють короткі сплески вище середнього, а буферизація додає затримку; обмежувати надлишок і ставити його в чергу на потім — різні рішення з різними симптомами.

Для перевірки запустіть дві передачі з одного клієнта, додайте другого клієнта і прочитайте лічильники класів у кожному напрямку.