Пометка порта VPN не даёт приоритета голосовым вызовам
Пометка порта VPN как приоритетного продвигает вызов и резервную копию в одном туннеле. Голосу нужна классификация до шифрования и очередь, которой вы управляете.
Пометка UDP-порта VPN как высокоприоритетного — самое частое изменение QoS для голоса, и оно не отделяет вызов от передачи файлов, использующей тот же туннель. Оба потока выходят через один и тот же зашифрованный сокет. Метка сообщает следующему узлу, что всё одинаково важно, а это то же самое, что не сказать ничего. Вызов защищают доверенная классификация до шифрования и очередь, которой вы действительно управляете.
Туннель скрывает поток, который вы хотели классифицировать
Шифрование заменяет внутренние заголовки одним внешним заголовком на туннель. После этого голос и резервный трафик имеют один и тот же источник, назначение и транспортный порт, поэтому классификатор, опирающийся на порт туннеля, не может их различить. Что бы вы ни продвигали, вы продвигаете это целиком.
Значение DSCP, заданное исходным приложением, сохраняется только если что-то копирует его наружу. В OpenVPN 2.6 есть passtos, документированный с областью IPv4; IPsec применяет собственную политику копирования или отображения на границе туннеля. Без этого шага внешний пакет помечается любым значением по умолчанию, которое использует интерфейс туннеля, и очередь ниже так и не узнаёт, что внутри есть вызов.
Скопированные метки заслуживают такого же недоверия, как любое значение, предоставленное клиентом. Рабочая станция может требовать ускоренной пересылки для задачи резервного копирования, поэтому допуск и перемаркировка на границе доверия должны быть в проекте прежде, чем метке поверят.
Приоритет имеет значение только там, где образуется очередь
Именно насыщенный исходящий канал превращает хороший кодек в роботизированный голос, а очередь, которая заполняется, обычно находится в устройстве доступа или в буфере провайдера. Формирование исходящего пути до доступной скорости, минус накладные расходы туннеля и канала, удерживает эту очередь на оборудовании, которым управляете вы, а не в чужом буфере.
Справедливая очередность и активное управление очередями помогают даже без голосового класса, потому что не дают одному массовому потоку заполнить буфер. CAKE в Linux объединяет формирование, справедливость на поток и дополнительные классы Diffserv в одном qdisc, и развёрнутый сетевой менеджер должен владеть этой конфигурацией, а не второй конкурирующей настройкой очереди. Без формирования класс, стоящий выше массового трафика, всё равно ждёт за уже полным буфером.
Обработка входящего трафика не бесполезна, но действует после того, как пакет прошёл принимающий канал. Она может повлиять на отзывчивого отправителя и не может вернуть задержку, уже потраченную выше по пути, поэтому это смягчение, а не гарантия.
| Stage | What you can control | What to verify |
|---|---|---|
| Application to client | Which flows are trusted for marking | The marked packets are the ones you intended |
| Tunnel boundary | Whether the inner mark is copied outward | Outer header carries the expected value |
| Your uplink | Shaping rate and class treatment | Queue counters move for the voice class |
| Provider path | Almost nothing | Whether the service enforces the marking at all |
| Receiving side | Local policy after arrival | Delay that is already in the past |
Что выживает в публичном интернете
Архитектура Diffserv описывает обработку внутри административных доменов, поэтому провайдер может игнорировать или переписывать метку на границе. Обратное утверждение, будто каждая сеть всегда её удаляет, столь же необоснованно. Честный вопрос — что именно этот путь обязан делать по договору и под контролем. Проверьте это помеченным зондом, вместо того чтобы повторять правило, прочитанное где-то.
Спросите, что провайдер делает с классом, а затем измерьте. Метка, которая сохраняется, но не планируется, — украшение; путь, который планирует, не видя метки, — другая проблема, и обеим нужны разные исправления.
План измерений, изолирующий этап
Проведите один обычный вызов с контролируемой конкурирующей загрузкой, затем повторите его на проводном канале. Посмотрите, что потерял вызов, что записали счётчики класса и насколько близко интерфейс работает к своему реальному пределу, а не к заявленной скорости тарифа.
tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.netЕсли счётчик голосового класса остаётся на нуле, классификация или копирование метки сломаны, и никакой приоритет не поможет. Если счётчик класса растёт локально, а задержка продолжает увеличиваться, узкое место находится за вашим шлюзом. Ни один из двух результатов не исправляется повышением значения приоритета.