Проблема прохождения SIP-трафика через NAT — это, пожалуй, одна из самых «древних» и обсуждаемых тем в мире IP-телефонии. Кажется, что за годы существования Asterconf и профильных сообществ всё уже сказано, но вопросы продолжают сыпаться. Всё дело в том, что протокол SIP по своей природе довольно капризный: он живет на седьмом уровне модели OSI, но при этом нагло тащит данные о сетевых адресах прямо внутрь своих пакетов. Когда на пути встает обычный NAT, который умеет менять заголовки только на сетевом уровне, получается классическая ситуация: пакет снаружи вроде бы правильный, а внутри у него «серый» IP-адрес, на который никто не сможет ответить.

Для борьбы с этим безобразием придумали специальные механизмы — SIP ALG (Application Level Gateway), которые в мире MikroTik называют просто SIP Helper. Вокруг этой «палки-выручалки» сломано немало копий. Одни говорят, что её надо выключать сразу после распаковки роутера, другие пытаются с её помощью спасти безнадежные инсталляции. На самом деле, это не магия и не «вредительство» разработчиков, а конкретный инструмент с четкой логикой работы.

Почему SIP и NAT не дружат с самого начала

Чтобы понять, зачем вообще нужен хелпер, стоит вспомнить, как выглядит типичный SIP-пакет. В отличие от многих других протоколов, SIP не просто передает данные, он постоянно «сообщает» собеседнику, куда ему слать ответные пакеты. Это происходит в нескольких ключевых полях:

• Via: показывает путь, по которому пришел запрос.
• Contact: адрес, по которому устройство ожидает новые запросы в рамках диалога.
• SDP (Session Description Protocol): здесь самое интересное — в поле c= (Connection Data) прописывается IP-адрес, на который нужно отправлять голосовой поток (RTP).

Проблема в том, что когда телефон стоит за роутером с NAT, он знать не знает про свой внешний белый адрес. Он честно пишет в пакете свой локальный IP, например 192.168.1.15. Роутер меняет IP в заголовке пакета, но не лезет внутрь. В итоге АТС видит запрос, пытается ответить на внутренний адрес телефона, и на этом связь обрывается. Начинаются проблемы: нет регистрации, нет входящих, или классическая «односторонняя слышимость», когда вы человека слышите, а он вас — нет.

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

Как именно работает SIP Helper в RouterOS

Если зайти в настройки MikroTik в раздел IP -> Firewall -> Service Ports, там можно найти строчку sip. Это и есть наш герой. Важно понимать, что MikroTik не изобретал этот модуль с нуля — это интерфейс к стандартным модулям ядра Linux: nf_conntrack_sip (отвечает за отслеживание соединений) и nf_nat_sip (отвечает за подмену адресов внутри пакетов).

Когда этот сервис включен, роутер начинает внимательно «всматриваться» в трафик, идущий через 5060 порт (или другой, если вы его там укажите). Как только он видит SIP-сообщение, включается следующий алгоритм:

1. Сверка с таблицей NAT. Хелпер не придумывает адреса сам. Он смотрит, сработал ли для этого пакета стандартный Source NAT или Masquerade.
2. Поиск локальных адресов. Если роутер видит внутри пакета (в тех самых полях Contact или SDP) локальный IP-адрес, который совпадает с адресом отправителя до трансляции, он его подменяет.
3. Замена на внешний IP. Вместо «серого» адреса вставляется тот самый внешний IP-адрес, который был назначен пакету на сетевом уровне.

Где именно происходят изменения? Это важный момент для диагностики. Многие пытаются поймать изменения в цепочке forward или prerouting, но там их нет. Пакет меняется «на выходе», уже после того, как отработали правила NAT. Увидеть реальную работу хелпера можно только с помощью Packet Sniffer, если снимать дамп прямо на внешнем интерфейсе роутера.

Сценарии, когда хелпер — это спасение

Несмотря на дурную славу, бывают случаи, когда без этой функции всё будет работать из рук вон плохо.

1. Работа с «глупыми» телефонами
Есть старые модели IP-телефонов или дешевые шлюзы, которые вообще не умеют работать с NAT. У них нет поддержки STUN, они не умеют определять свой внешний адрес. Они просто шлют то, что у них настроено. Если у вас в сети парк таких устройств, SIP Helper станет тем самым костылем, который позволит им связаться с внешним миром без боли.

2. Ситуации с Dual WAN (Два провайдера)
Это, пожалуй, самый сильный аргумент в пользу хелпера. Когда у вас два интернет-канала и один из них падает, роутер переключает трафик на другой. В таблице соединений (Connection Tracking) при этом могут зависнуть старые сессии. Пакеты будут пытаться уйти через новый канал, но со старыми данными внутри.
SIP Helper умеет отслеживать смену внешнего IP. Как только он видит, что NAT-адрес изменился, он помогает быстрее «перестроить» SIP-диалоги под новые реалии. Это избавляет от необходимости вручную сбрасывать соединения или ждать, пока они отвалятся по тайм-ауту. Часто это критично, когда выполняется установка Asterisk в компаниях с повышенными требованиями к отказоустойчивости.

3. Сложные схемы с VPN
Иногда Ip-телефония для удаленных сотрудников настраивается через VPN-туннели, внутри которых всё равно есть NAT (например, из-за пересечения подсетей). В таких запутанных случаях хелпер может помочь корректно пробросить заголовки через несколько этапов трансляции.

Почему же его рекомендуют отключать?

Если всё так здорово, почему первая заповедь любого инженера телефонии — «выключи SIP ALG»? На это есть веские причины.

Хелпер часто «умничает» там, где не просят. Современные АТС (тот же Asterisk) и современные телефоны сами отлично умеют работать с NAT. В настройках Asterisk есть параметры externip или nat=yes, которые заставляют станцию сразу подставлять правильные адреса. Если телефон сам подставил свой внешний адрес, а потом по этому пакету «проехался» SIP Helper, он может повторно что-то изменить и в итоге испортить пакет. В результате — битые заголовки и неработающая связь.

Нагрузка на процессор. Глубокий анализ пакетов (DPI на минималках) требует ресурсов. Если у вас сотни одновременных звонков, роутер может начать «захлебываться», перебирая содержимое каждого пакета.

Проблемы с безопасностью. SIP Helper динамически открывает порты для RTP. В некоторых реализациях это может стать лазейкой для злоумышленников. Чтобы спать спокойно, лучше периодически проводить Аудит IP-ATC и проверять, не торчит ли из вашей сети что-то лишнее. Полноценная защита IP-ATC обычно строится на строгих правилах Firewall, а «автоматика» хелпера может эти правила неявно обходить.

Нюансы настройки: Тайм-ауты и Connection Tracking

Если вы всё же решили использовать SIP Helper или просто хотите, чтобы телефония через MikroTik работала стабильно, нужно обратить внимание на настройки Connection Tracking.

У UDP-трафика (а SIP и RTP — это чаще всего UDP) есть одна неприятная особенность: если пакеты долго не ходят, роутер «забывает» про соединение и закрывает дырку в NAT.

• Если телефон шлет регистрацию раз в 10 минут, а udp-timeout в MikroTik стоит 30 секунд, то через полминуты после регистрации входящий звонок до телефона не дойдет — роутер его просто не пропустит.
• Решение: Либо уменьшать время перерегистрации на телефонах до 60–120 секунд, либо увеличивать udp-timeout в настройках роутера.

Однако помните: слишком большие тайм-ауты забьют таблицу соединений мусором, а слишком маленькие — заставят станцию постоянно переваривать новые регистрационные пакеты, что создаст нагрузку на «железо».