Позначення порту VPN не дає пріоритету голосовим викликам

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

Тунель приховує потік, який ви хотіли класифікувати

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

Значення DSCP, задане вихідним застосунком, зберігається лише якщо щось копіює його назовні. У OpenVPN 2.6 є passtos, задокументований з областю IPv4; IPsec застосовує власну політику копіювання або зіставлення на межі тунелю. Без цього кроку зовнішній пакет позначається будь-яким типовим значенням, яке використовує інтерфейс тунелю, і черга нижче так і не дізнається, що всередині є виклик.

Скопійовані позначки заслуговують на таку саму недовіру, як будь-яке значення, надане клієнтом. Робоча станція може вимагати прискореного пересилання для завдання резервного копіювання, тому допуск і перепозначення на межі довіри мають бути в проєкті перш ніж позначці повірять.

Пріоритет має значення лише там, де утворюється черга

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

Справедлива черговість і активне керування чергами допомагають навіть без голосового класу, бо не дають одному масовому потоку заповнити буфер. CAKE у Linux об'єднує формування, справедливість на потік і додаткові класи Diffserv в одному qdisc, і розгорнутий мережевий менеджер має володіти цією конфігурацією, а не другою конкуруючою настройкою черги. Без формування клас, що стоїть вище за масовий трафік, усе одно чекає за вже повним буфером.

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

Що виживає в публічному інтернеті

Архітектура Diffserv описує поводження всередині адміністративних доменів, тому провайдер може ігнорувати або переписувати позначку на межі. Протилежне твердження, що кожна мережа завжди її знімає, так само необґрунтоване. Чесне питання — що саме цей шлях зобов'язаний робити за договором і під контролем. Перевірте це позначеним зондом, а не повторенням правила, прочитаного десь.

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

План вимірювань, що ізолює етап

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

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

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