Базовая настройка Mikrotik с нуля для работы в VoIP-сетях часть 3

Практическая классификация трафика VoIP в сетях с Asterisk и его последующей приоритизации средствами MikroTik RouterOS. Рассматриваются типичные сложности (неизвестные адреса серверов, плавающие RTP-порты, смешанные среды с софтофонами и IP-телефонами), а также устойчивые приёмы: маркировка в Mangle, использование DSCP, особенности conntrack/SIP helper, настройка очередей Simple Queue/Queue Tree и современные типы очередей FQ-CoDel/CAKE.

Исходная проблема: как выделять голос среди «всего остального»

В реальной эксплуатации нередко отсутствуют точные знания об адресах SIP-регистраторов и диапазонах RTP-портов (например, коворкинги, распределённые офисы, BYOD). Стандартного «универсального» диапазона RTP нет — у разных провайдеров и платформ он различается. Из-за этого простая фильтрация «порт 5060 + некий диапазон UDP» даёт ложные срабатывания (вплоть до попадания торрента/видеостриминга).

Базовый инструмент: Mangle в RouterOS

Классификация выполняется в таблице Mangle (аналогично Linux). Рекомендованный паттерн:

1. Mark Connection — маркировать соединение по узнаваемому признаку.
2. Mark Packet — на базе метки соединения присвоить метку пакетам (используется далее в QoS).

Это уменьшает нагрузку (пакеты наследуют метку соединения) и упрощает логику приоритизации.

Важно:

1. У каждого пакета может быть только одна connection-mark, одна packet-mark и одна routing-mark. Не допускать повторной перемаркировки.
2. Для снижения нагрузки целесообразно метить только connection-state=new (дальше сработает наследование). Исключение: состояние related — отдельно описано ниже.
3. Для сдерживания «перетираний» марок удобно использовать условия вида connection-mark=no-mark.

Признаки для классификации (от надёжных к более эвристическим)

Адреса и интерфейсы

Если телефоны/АТС в известной подсети/VLAN — использовать src-address/dst-address, in-interface/out-interface. Это самый чистый признак.

Порты

• SIP-сигналинг — чаще UDP/TCP 5060, но бывает и нестандартно.
• RTP — у каждого вендора диапазон свой; ориентироваться вслепую опасно (в диапазон легко попадают нежелательные потоки).

DSCP (предпочтительный универсальный способ)

Лучший способ «подсветить» голос — ставить DSCP на краях (телефон/софтофон/АТС) и далее доверять метке в сети.

Рекомендации по значениям:

• RTP (media): EF = 46 (Expedited Forwarding).
• SIP (signaling): обычно CS3 = 24 или AF31 = 26.

На IP-телефонах DSCP настраивается в конфиге; во многих моделях уже предзадано. Для софтофонов под Windows метки можно задать через Политики QoS (GPO):

• Конфигурация компьютера → Политики → Параметры Windows → Политики QoS.
• Создать политику, задать значение DSCP, ограничить по исполняемому файлу (путь к .exe) и нужным протоколам/портам.

Диагностика: утилита Torch в RouterOS показывает текущие DSCP-метки на интерфейсе — удобно проверять, кто реально метит.

Состояние соединения related (через SIP helper)

Ядро Linux имеет модуль nf_conntrack_sip (в RouterOS — SIP helper). При наличии установленных SIP-соединений он создаёт «ожидаемые» (expectations) для медиапотоков и помечает такие RTP как connection-state=related. Это точный сетевой признак, не завязанный на диапазон портов.

Ключевой нюанс: в инфраструктурах с Asterisk SIP helper/ALG обычно отключают (чтобы не искажать SIP/SDP). Если SIP helper выключен, признак related для RTP не сработает. Если helper включён осознанно, признак related можно использовать для аккуратного захвата RTP, в том числе при раздельной доставке SIP/RTP разными адресами. Direct Media может менять адреса — нужна валидация в пилоте.

Скорость соединения (connection-rate) и размер пакетов

Это эвристики. На низких скоростях могут отсеяться «тяжёлые» потоки, но ложноположительные случаи неизбежны (особенно при первичных пакетах в BitTorrent и др.). Применять с осторожностью.

Безопасная логика правил Mangle

• Сначала узкие и надёжные условия (адреса/VLAN/DSCP/related), ниже — более общие.
• Использовать passthrough по ситуации: либо продолжить обработку, либо «зафиксировать» результат и прекратить.
• Опасно метить «широкими» условиями (например, «весь UDP 10000–20000»): туда попадают нерелевантные потоки и ломают QoS.

Применение меток в QoS (Simple Queue / Queue Tree)

Simple Queue (быстрый старт)

Наиболее удобна для большинства сценариев. Очереди строятся по packet-mark. Обязателен правильный порядок: специфические очереди (SIP/RTP) — выше, «catch-all» — ниже.

Полезные опции:

• Поле Interface — привязать к конкретному провайдеру; для Dual-WAN сделать копию дерева на второй uplink (QoS «поедет» за активным провайдером без скриптов).
• Scheduler по времени — ограничивать, например, бэкапный трафик днём и отпускать ночью.

Queue Tree (детальная иерархия)

Более тонкое управление на global-уровне предпочтительней интерфейсного (проще разделять направления и провайдеров). Однако в интерфейсных Queue Tree отсутствуют некоторые удобные поля Simple Queue; нередко используется гибридный подход.

Учёт всего трафика

Для корректного QoS необходимо пометить всё: не только forward, но и input/output (VPN-сервисы, сервисный трафик роутера), иначе часть потока окажется «неучтённой».

Типы очередей: почему стоит уйти от классического FIFO

Классические очереди (PFIFO/byte-fifo) дропают самые новые пакеты при переполнении. Это ведёт к пилению скорости TCP и «залипанию» поздних запросов (в браузере: первые вкладки открываются, последние — умирают по таймауту).

Современные типы:

• FQ-CoDel — делит трафик на множества потоков и удаляет самые старые пакеты с избыточной задержкой (минимизирует буферблоут). Дефолтные параметры обычно годятся; interval ~100 ms — для Интернета, в LAN можно уменьшить. Рекомендуется как базовый тип для уже классифицированных классов (SIP, Web и т.п.).
• CAKE — развитие FQ-CoDel с пресетами RTT/overhead, режимами изоляции хостов и DiffServ-профилями

Даже «чистый» CAKE без сложной классификации часто работает лучше, чем PCQ/Default Small. Для Wi-Fi целесообразно заменить wireless-default на FQ-CoDel (и при желании — на CAKE) сразу на уровне профилей.

Практические рецепты классификации

1. DSCP-first. Включить DSCP на телефонах/АТС/софтофонах (EF для RTP; CS3/AF31 для SIP). В RouterOS в Mangle выделять по DSCP и назначать connection-mark/packet-mark.
2. SIP helper осознанно. Если helper включён: использовать connection-state=related для RTP (надёжно даже при Direct Media и раздельных адресах). Если helper отключён (типично для Asterisk): не надеяться на related; опираться на DSCP/адреса/интерфейсы.
3. Адреса/VLAN. При наличии отдельных подсетей для телефонов — включить как дополнительный фильтр.
4. Порты. Использовать только как дополнительный признак; избегать широких UDP-диапазонов без других ограничителей.
5. Страховка от перемаркировок. В правилах Mangle проверять connection-mark=no-mark, метить только new, а ниже — «ловить» наследование.
6. Порядок очередей. Специфические классы (SIP/RTP) ставить выше иерархически и по порядку обработки; «прочее» — в хвост.
7. Dual-WAN. Дублировать Simple Queue на каждого провайдера с указанием соответствующего интерфейса.
8. Типы очередей. Для голосового и интерактивного трафика предпочесть FQ-CoDel/CAKE; default-small (PFIFO) заменить.
9. Мониторинг. Torch — проверка DSCP и попадания потоков в нужный класс. Connection Tracking — видна connection-mark (но не packet-mark), удобен для верификации логики Mangle.

Частые вопросы и ответы

Что делать, если провайдер даёт SIP и RTP с разных адресов?
При активном SIP helper признак related корректно «свяжет» RTP с исходным диалогом SIP. Без helper — опираться на DSCP и дополнительные условия (адреса/VLAN).

Можно ли отфильтровать голос по «низкой скорости соединения» (connection-rate)?

Только как вспомогательную эвристику. Полностью от ложных срабатываний не избавляет.

Есть ли «универсальный размер RTP-пакета» для фильтрации?
Нет. Размер зависит от кодека, настроек телефонов/АТС, наличия SRTP и т.д. На размер рассчитывать нельзя.