Примеры настройки маршрутизаторов и межсетевых экранов для правильной работы функции NAT в Asterisk - Зайцев Я - Флудилка
^ В верх

Зайцев.Я

Все самое интересное в разделе "Флудилка"


Войти
x
x

Кто на сайте

Флудилка

Обсуждение Joomla , Virtuemart 2 , Cisco IOS , Asterisk , PHP

  • Категории
    Категории Страница отображения списка категорий системы блогов сайта.
Добавлено : Дата: в разделе: АТС Asterisk

Примеры настройки маршрутизаторов и межсетевых экранов для правильной работы функции NAT в Asterisk

Проблема обхода NAT

Вряд ли стоит долго объяснять, почему NAT является проблемой для голосового трафика. Достаточно уже того факта, что голосовой трафик обособлен от сигнализации и использует динамически назначенные номера портов. А IP-адреса и номера портов, помещаемые находящимся за NAT-пользовательским агентом в поля заголовков Contact и Via, а также в SDP-сообщение, не маршрутизируемы. Маршрутизатор с поддержкой NAT-транспортного уровня модели OSI, а SIP-заголовки формируются на уровне приложения. Следовательно такое устройство не может проанализировать заголовки и SDP-сообщение и переопределить анонсированные там IP-адреса и номера портов (а также открыть обратный канал для маршрутизации входящего трафика к пользовательскому агенту), равно как и не может знать, к какому SIP-диалогу относится тот или иной медиапоток.

Как результат, каждый не понаслышке знакомый с IP-телефонией человек сталкивался с явлениями односторонней слышимости или вовсе отсутствия звукового потока. Сразу следует заметить, что «серебряной пули» здесь нет: все решения этой проблемы в большей или меньшей степени частные.

Впрочем, проблема обхода NAT медиатрафиком – это лишь одна сторона медали. Вначале мы рассмотрим, какие препятствия создаёт NAT для сигнальных сообщений и какие расширения SIP были разработаны для их преодоления.

Обход NAT SIP-сигнализацией

При использовании протоколов транспортного уровня без гарантии доставки отправка ответа на SIP-запрос производится на тот IP-адрес, с которого запрос был получен. Этот IP-адрес транспортный уровень протокола SIP заносит в параметр received заголовка Via перед передачей сообщения вышележащим уровням. Номер же порта для отправки извлекается из заголовка Via. В случае применения NAT – это порт, на котором ожидает ответа находящийся за NAT пользовательский агент, а не тот порт, через который происходит NAT-трансляция и на котором NAT ожидает поступления ответа; следовательно, ответ не может достичь адресата.

Решение этой проблемы было предложено в RFC 3581 [1] и заключается в отправке ответа на порт, с которого запрос был получен, вместо порта, взятого из заголовка Via. При этом сам порт заносится в специальный параметр rport-заголовка Via. Таким образом, прокси-сервер отсылает ответное сообщение на порт и IP-адрес, с которых пришёл запрос. Это позволяет ответу найти соответствие в таблице трансляции NAT и достичь целевого узла. Этот метод называется симметричной маршрутизацией ответов.

Вторая проблема заключается в необходимости корректной маршрутизации входящих SIP-запросов. SIP не обеспечивает механизма, который бы позволял отправлять новые запросы по тому соединению транспортного уровня, которое было образовано при регистрации пользователя. Записи в таблице трансляции NAT имеют ограниченное время жизни (чтобы таблица не переполнялась в том числе) и, чтобы входящие SIP-запросы могли достичь UA за NAT, записи в таблице трансляции NAT надо периодически обновлять. Это касается как протоколов без установления соединения, так и протоколов с установлением соединения.

На рис. 1 запрос REGISTER был отправлен клиентом с порта 8023 и получен прокси-сервером на порту 5060, создав при этом запись в таблице трансляции NAT и (в случае использования транспортного протокола с установлением соединения) соединение транспортного уровня. При необходимости отправки запроса данному UA, прокси-сервер отправляет сформированный запрос на IP-адрес и порт, взятые из заголовка Contact при регистрации. Этот же IP-адрес не маршрутизируем; следовательно, для корректной маршрутизации входящих запросов сервер регистрации должен сохранить в базе данных с информацией о местоположении пользователей IP-адрес и номер порта, с которых запрос был на самом деле получен, в качестве контакта пользователя.

1nat1

Рисунок 1. Маршрутизация входящих запросов

Но запись в таблице трансляции NAT удаляется после истечения определенного промежутка времени (чаще всего – несколько минут). Проблема актуальна не только в период после регистрации пользователя: во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы трансляции была удалена. Имеющиеся SIP-стеки решают эту проблему путём периодической посылки SIP-запросов re-INVITE, OPTIONS, INFO, NOTIFY или (при использовании UDP) дейтаграмм, не содержащих полезной нагрузки.

Более полная и совершенная техника описана в проекте Managing Client Initiated Connections in SIP Инженерной проблемной группы Интернет (IETF) [2]. Остановимся на ней подробнее.

При регистрации пользователя регистратор сохраняет данные о транспортном соединении, через которое был получен запрос. Два специальных параметра instance-id и reg-id заголовка Contact позволяют найти в базе данных сервера регистрации данные о соединении и направить входящий запрос к UA по тому соединению транспортного уровня, через которое был получен запрос регистрации. Также в черновике описаны механизмы для постоянного обновления записей таблицы трансляции NAT.

Подытожим сказанное небольшим примером регистрации пользователя, находящегося за NAT и использующего UDP (см. рис. 2).

1nat2

Рисунок 2. Обход NAT SIP-сигнализацией

Запрос REGISTER содержит параметр заголовка Via rport, информирующий UAS о поддержке RFC 3581, а также параметры reg-id и +sip.instance в заголовке Contact:

nat3

Ответ прокси-сервера выглядит так:

nat4

Параметры reg-id и +sip.instance делают возможным повторное использование соединения транспортного уровня, по которому был получен REGISTER, в соответствии с [2]. Заметьте, что IP-адрес и порт, с которых был получен запрос, прокси-сервер заносит в параметры received и rport заголовка Via. На них же и производится отправка ответа в соответствии с RFC 3261 и RFC 3581. Причём ответ должен быть отправлен прокси-сервером с того же IP-адреса и порта, на котором был получен запрос, чтобы ответ был опознан NAT-транслятором, как принадлежащий к установленному соединению.

Обход NAT медиатрафиком

Решение проблемы обхода NAT медиатрафиком требует более сложных изменений, поскольку необходимо заменить IP-адрес и номер порта, анонсированные в SDP-сообщении, таковыми, что обеспечат доставку потоков нужному адресату за NAT (см. рис. 3).

2nat5

Рисунок 3. Обход NAT медиатрафиком

Simple Traversal of UDP through NAT (STUN)

Терминология NAT и сведения о разных типах NAT были изложены в [3]. Там же был рассмотрен протокол STUN (Simple Traversal of UDP through NAT, RFC 3489 [4]), позволяющий определить факт наличия NAT и его тип путем отправки на STUN-сервер последовательности зондирующих запросов. В контексте SIP нас интересует возможность определения пользовательским агентом публичного IP-адреса NAT и записей в таблице трансляции с помощью STUN. Но вначале напомню специфику разных типов NAT.

  • Full Cone NAT – такой NAT транслирует все запросы от одного и того же внутреннего IP-адреса в один и тот же внешний IP-адрес и один и тот же номер порта. Отправка пакетов хосту, находящемуся за NAT такого типа, извне, легко осуществима – проверяются только транспортный протокол, адрес назначения и порт назначения, а адрес и порт источника значения не имеют. Приложению нужно лишь слушать на том же IP-адресе и порту, с которых оно отправляет запросы.
  • Restricted Cone NAT – от предыдущего типа он отличается тем, что выполняется проверка адреса источника. Иными словами, хосту, находящемуся за NAT такого типа, хост с IP-адресом X сможет отправить пакет только в том случае, если перед этим внутренний хост уже отправлял пакеты на IP-адрес X.
  • Port Restricted Cone NAT – в дополнение к проверке адреса источника здесь также выполняется проверка порта источника. Хост с IP-адресом X, отправляющий пакеты с порта P, сможет «достучаться» до хоста за NAT такого типа только в том случае, если перед этим внутренний хост уже отправлял пакеты на IP-адрес X и порт P.
  • Symmetric NAT – все запросы от одного и того же внутреннего IP-адреса и направленные на один и тот же IP-адрес и порт транслируются в один и тот же внешний IP-адрес и один и тот же порт. При изменении IP-адреса или порта назначения создается новая запись в таблице трансляции. При отправке пакетов хосту, находящемуся за NAT такого типа, проверяется транспортный протокол, адрес и порт назначения, а также адрес и порт источника.

Алгоритм работы STUN следующий. Клиент STUN (встроенный в UA) отправляет на расположенный снаружи NAT STUN-сервер зондирующие сообщения. STUN-сервер анализирует это сообщение и информирует клиента о том, какие IP-адрес и порт были использованы NAT (cм. рис. 4). Эти IP-адрес и порт клиент и помещает в SDP-часть SIP-запроса (а также поля заголовков Via и Contact). Путём отправки специальной последовательности запросов клиент может точно определить тип NAT.

1nat6.jpg

Рисунок 4. STUN

Наконец, мы подошли к главному. STUN не решает проблему обхода NAT в SIP в общем случае. Да, он работает в сценариях Port Restricted Cone NAT, а иногда – и в Restricted Cone NAT, но наиболее распространенным типом NAT был и остается симметричный, и здесь STUN бесполезен. К тому же не все UA даже в случае более дружественных типов NAT хорошо «дружат» с STUN, а в более старых устройствах поддержка STUN не была широко распространена.

Ещё одна «ложка дёгтя» – в существующих реализациях STUN не работает с SIP поверх TCP, поскольку не отслеживает должным образом состояние открытых TCP-сессий.

Traversal Using Relay NAT (TURN)

Дальнейшим развитием STUN является протокол TURN (Traversal Using Relay NAT). TURN позволяет клиенту получить маршрутизируемый IP-адрес для общения с одним внешним узлом (и не пригодный для чего либо еще). TURN-сервер, обычно располагаемый  DMZ абонентской сети или в сети сервис-провайдера, имитирует поведение Restricted Cone NAT: он транслирует пакеты с внешнего IP-адреса к клиенту только в том случае, если клиент ранее уже отправлял пакеты на внешний узел через TURN-сервер.

Таким образом, TURN-сервер служит транзитным узлом (прокси-сервером) для всего последующего сигнального и медиатрафика (см. рис. 5). При этом он приемлемо работает даже с клиентами за симметричным NAT. Для выделения IP-адреса и отправки пакетов в спецификации протокола определены специальные запросы Allocate и Send; в остальном же структура протокола аналогична STUN. В качестве транспортных протоколов для сигнального и медиатрафика TURN поддерживает TCP и UDP.

1nat7

Рисунок 5. Обход NAT SIP-сигнализацией

Недостаток данного метода очевиден: вследствие проксирования всего трафика увеличивается односторонняя задержка и повышается вероятность потери пакетов. По этой причине TURN рекомендуется использовать лишь в тех случаях, когда менее «дорогие» методы обхода NAT бессильны. Заметим, что с недавнего времени TURN больше не считается самостоятельным протоколом: сейчас он описан как расширение к STUN в [5].

Interactive Connectivity Establishment (ICE)

TURN-сервер проксирует весь RTP-трафик даже тогда, когда простого STUN было бы достаточно для обхода NAT. С целью выбора наименее «дорогого» метода обхода NAT путем проведения согласования возможных опций между конечными точками ассоциация IETF предложила инфраструктуру ICE (Interactive Connectivity Establishment). Это не протокол в привычном смысле этого слова; ICE называют инфраструктурой (framework), и базируется он на существующих протоколах STUN и TURN и расширениях SIP.

Механизм работы ICE следующий. Пользовательские агенты производят поиск возможных маршрутов между собой. Каждый UA для начала диалога может использовать либо IP-адрес одного из локальных сетевых интерфейса, либо определённый с помощью STUN (или UPnP, Universal Plug and Play) маршрутизируемый IP-адрес, либо же IP-адрес TURN-сервера. Список маршрутов-кандидатов образуют пары – все возможные комбинации транспортных адресов одного пользовательского агента с транспортными адресами другого.

В списке маршрутов-кандидатов наивысший приоритет получают маршруты без задействования STUN, более низкий – маршруты с задействованием STUN, и наиболее низкий – маршруты с проксированием медиатрафика через TURN-сервер. Изложение здесь намеренно усложнено: на самом деле гибкая система приоритетов позволяет учитывать топологию сети, данные о задержке и вариации задержки, требования к безопасности и т. д. В итоге каждый маршрут получает уникальное значение приоритета. Затем проверяется их работоспособность (достижимость противоположной стороны). Из маршрутов, прошедших проверку, выбирается один с наивысшим приоритетом.

Если в роли транспортного протокола выступают RTP/RTCP, для которых назначаются порты со смежными номерами, с целью оптимизации выполняется согласование маршрутов только для одного порта. К слову, если в результате использования STUN или TURN, назначение для RTCP-порта с номером на единицу большим, чем у порта, выделенного для RTP-трафика, невозможно, специальный атрибут rtcp в SDP-части (RFC 3605) может содержать произвольный номер порта и IP-адрес, на котором UA готов принимать RTCP-сообщения.

Словом, спецификация ICE выглядит весьма многообещающе, и это решение находит поддержку VoIP-индустрии. Описание ICE дано в [6].

Проксирование медиатрафика

Один пример с проксированием как SIP-сигнализации, так и медиатрафика, мы уже видели – это TURN. Рассмотрим, каким образом можно реализовать проксирование одного лишь медиатрафика при помощи RTP-прокси-сервера и B2BUA («Back-to-back user agent» – SIP-узел, состоящий из двух SIP UA, которые общаются между собой строго на прикладном уровне). Критерием для определения факта присутствия NAT чаще всего служит наличие немаршрутизируемого IP-адреса в поле заголовка Contact.

Далее, нам известно, что для того, чтобы RTP-трафик достиг UA за NAT, в качестве адреса и порта назначения следует использовать IP-адрес NAT-устройства и порт, анонсированный в определении медиапотока в SDP части. Следовательно, когда факт присутствия NAT установлен, B2BUA «запоминает» IP-адрес, с которого был получен запрос, и сообщает пару «IP-адрес : номер порта» устройству RTP-прокси, чтобы тот использовал эти данные для отправки трафика инициатору вызова в дальнейшем. RTP-прокси создаёт новый сеанс, выделяет новую пару IP-адрес: порт для медиа-потока и сообщает её B2BUA. Тот подставляет полученные (маршрутизируемый) IP-адрес и порт в SDP-сообщение перед пересылкой запроса адресату. Аналогичные манипуляции выполняются c SDP-сообщением адресата. В результате весь медиатрафик протекает через RTP-прокси.

Для функционирования этого механизма принципиально важным является свойство симметричности пользовательского агента: использование для передачи и приёма одного и того же порта (UA должен отправлять медиа-поток с того порта, который он анонсировал в SDP). Но такой подход идеален в смысле точности данных: не требуется ничего, кроме собственно пакета, и поскольку пакет приходит на тот порт, с которого будет посылаться встречный поток – решаются проблемы со всеми видами NAT. В таком прокси-сервере можно реализовать любую дополнительную функциональность, связанную с модификацией SDP-части. В то же время это вносит дополнительную задержку в сеанс, повышает нагрузку на прокси-сервер и расходы сервис-провайдера.

Расширения Cisco COMEDIA

Если быть кратким, эти расширения [7] позволяют маршрутизатору обновить IP-адрес и порт источника, сохранённые для RTP-потока на этапе установления сессии, IP-адресом и портом, с которых был получен первый (прошедший через NAT) RTP-пакет.

Ведь пользовательский агент, находящийся за любым видом NAT, может успешно слать RTP-пакеты другому агенту с маршрутизируемым IP-адресом, а тот, в свою очередь, может достичь инициатора этого трафика по IP-адресу и номеру порта, с которых был получен первый RTP-пакет (при условии, что первый пользовательский агент симметричен). Такой подход напоминает симметричную маршрутизацию ответов, описанную в RFC 3581 [1], но для медиатрафика. Рассмотрим, как это работает в случае обоюдной поддержки COMEDIA сторонами. Пусть в INVITE было получено SDP-описание следующего содержания:

nat8

Наличие атрибута direction говорит о поддержке COMEDIA. Ответный SDP от UAS имеет такой вид:

nat9

UAS обязан дождаться первого пакета от UAC, прежде чем начать отправлять медиапакеты. Затем UAS должен слать RTP-трафик на IP-адрес и порт, с которых пришёл первый медиапакет, вместо анонсированных в первом SDP-предложении 10.1.2.23:49172.

При реализации COMEDIA Cisco руководствовалась сильно устаревшим на сегодняшний день проектом IETF [8] четвёртой версии.

После десятой версии данного документа он был принят как RFC 4145 – TCP-Based Media Transport in SDP и касается теперь лишь передачи медиатрафика поверх TCP. На моей памяти множество случаев, когда применение COMEDIA вызывало потерю аудио при сопровождаемом переводе или разветвлении вызова: фактически маршрутизатор продолжал посылать медиапоток на пару IP-адресов: порт, полученную в первом SDP-предложении, упорно игнорируя все последующие. Причём решить проблему помогало именно отключение (!) поддержки COMEDIA. Посему применять COMEDIA в вышеназванных сценариях следует с долей осторожности.

Другие технологии

Нередко в качестве решения предлагается применять шлюзы уровня приложений (Application Layer Gateway, ALG), обрабатывающие как заголовки пакета IP, так и его информационное наполнение. Функции ALG могут выполнять пограничные контроллеры соединений (Session Border Controller, SBC) или маршрутизаторы, транслирующие управляющие сообщения SIP. К сожалению, обработка каждого пакета требует высокой производительности и повышает стоимость решения. К тому же новые модификации протокола требуют, чтобы ПО SIP ALG постоянно обновлялось, а его производитель следил за всеми изменениями, реализуемыми поставщиками устройств SIP. «Нечестный» SIP ALG может повлиять на нормальное функционирование находящихся за ним устройств. Технология UPnP (Universal Plug and Play) чаще применяется в сегменте SOHO и малых инсталляциях. Впрочем, она не является специфичной для VoIP и к тому же и так неплохо освещена в Сети.

Пример настройки маршрутизатора TL-WR841N

Рисунок 1 - Настройка порта Wan

router 1

Рисунок 2 - Настройка локальной сети

router 2

Рисунок - 3 Настройка DHCP клиентов

router 5

Рисунок 4 - настройка переадресации портов

router 3

Рисунок 5 - Настройка переадресации портов UDP для передачи голосовых данных RTP 

router 4

Поставьте свой рейтинг этой записи блога:
0

Комментарии

Оставить комментарий

Гость
Гость Вторник, 17 Сентябрь 2019
Яндекс.Метрика Рейтинг@Mail.ru