CommuniGate Pro
Версия 6.2
Сигнализация
 
 
NAT

Прохождение NAT

"Базовая", "оригинальная" модель голосовых коммуникаций подразумевает, что конечные устройства могут взаимодействовать напрямую, то есть все "участники", как клиенты (телефоны, софтфоны, приложения PBX), так и сервера имеют "реальные" Интернет IP адреса. В этом случае все участники могут обмениваться медиа данными напрямую, отправляю медиа пакеты (обычно, используя протокол RTP или T.120) непосредственно друг-другу.

Как это часто бывает, в реальной жизни ситуация довольно сильно отличается от этой модели, и конечные устройства не могут обмениваться медиа данными напрямую. Сервер CommuniGate Pro решает эту проблему путём автоматического проксирования медиа данных, предписывая конечным устройствам отправлять медиа данные через Медиа Прокси для их дальнейшей ретрансляции.

Проксирование Медиа применяется в следующих случаях:
  • одно конечное устройство находится в локальной сети LAN, а другое в глобальной WAN.
  • одно конечно устройство находится за удалённым NAT, тогда как другое не находится за этим же NAT.
  • одно конечно устройства находится в сети IPv4, а другое находится в сети IPv6.
  • проксирование Медиа явно затребовано компонентом Signal.

Проксирование Медиа также применяется компонентами SIP и XIMSS в случаях, когда вызов отправляется удалённому участнику.

Прохождение NAT и Проксирование Медиа Потоков

"Базовая", модель коммуникаций подразумевает, что конечные устройства могут взаимодействовать напрямую, то есть, все "участники", как клиенты (телефоны, софтфоны, приложения PBX), так и сервера имеют "реальные" Интернет IP адреса. В такой ситуации Серверу необходимо только установить соединение. Медиа данные и (в случае SIP) управляющие сигналы в течение звонка циркулируют непосредственно между конечными устройствами:

Базовый SIP Вызов

В реальной жизни множество клиентов находится в удалённых локальных сетях ("позади NAT") или в различных локальных сетях и не могут взаимодействовать напрямую. Для коммуникаций в реальном времени, основывающихся на публичных стандартах, CommuniGate Pro поддерживает автоматическое "Прохождение NAT".


Ближнее Прохождение NAT

Модули SIP и XIMSS CommuniGate Pro определяют запросы на установление сессии, отправленные от одной стороны через NAT другой стороне (запрос от клиента в локальной сети, направляемый участнику в Интернет/WAN и наоборот). В этом случае сервер использует специальный локальный порт сервера (или набор таких портов, в зависимости от используемого медиа протокола) и осуществляет проксирование медиа данных. Сервер изменяет запросы на установление сессии и направляет трафик обоих сторон через такой прокси.

Медиа Прокси ретранслирует медиа данные между "плечом LAN" и "плечом WAN" медиа соединения:
Ближнее Прохождение NAT для SIP

Модули SIP и XIMSS CommuniGate Pro определяют запросы на изменения сессии (команду re-INVITE протокола SIP) и запросы на закрытие сессии (команду BYE протокола SIP) и, соответственно, изменяют или удаляют Медиа Прокси. Для удаления "заброшенных" Медиа Прокси используется механизм тайм-аутов.

CommuniGate Pro обеспечивает услуги проксирования NAT для:

Обратите внимание: Если вам необходимо использовать функции Проксирования Медиа, убедитесь, что данные о конфигурации LAN и NAT на странице с настройками Адреса LAN и NAT заданы корректно.

Обратите внимание: Сервер автоматически выполняет Медиа Проксирование при ретрансляции запросов, приходящих с IPv4 адресов на IPv6 адреса и наоборот.


Дальнее Прохождение NAT

SIP и XIMSS модули CommuniGate Pro обладают также возможностями "дальнего" прохождения NAT, обнаруживая запросы, приходящие от клиентов, находящихся за удалёнными межсетевыми экранами или NAT.
Модули добавляют соответствующие заголовки Record-Route и Path к таким запросам и организовывают Медиа Проксирование, ретранслируя трафик между такими клиентами.

Дальнее Прохождение NAT для SIP

Обратите внимание: современные SIP клиенты поддерживают различные методы прохождения NAT (STUN и т.д.). Многие из этих реализаций работают неустойчиво, так что часто надёжнее будет просто отключить методы прохождения NAT на стороне клиента и вместо этого воспользоваться имеющимися в CommuniGate Pro возможностями по "дальнему" прохождению NAT.

Обратите внимание: из-за особенностей TCP протокола и самой концепции межсетевого экрана, в общем случае невозможно открыть TCP соединение с клиентом, находящимся за дальним NAT (в конфигурациях с "ближним" NAT такие проблемы отсутствуют). Это означает, что клиенты, находящиеся за "дальними" NAT не могут инициировать TCP (T.120) сессии.

Для того, чтобы решить эту проблему, вы можете:

Услуги Edge

SIP Модуль CommuniGate Pro может оказывать "Услуги Edge" или ALG ("Application Level Gateway", "Шлюз Уровня Приложений"), предоставляя возможности по прохождению NAT для пользователей, зарегистрированных на других серверах.

Услуги Edge SIP

SIP Модуль CommuniGate Pro умеет обнаруживать "медиа петли", когда вызов, совершённый из локальной сети LAN проксируется в глобальную сеть WAN, а затем проксируется обратно в ту же локальную сеть. В этом случае Медиа Проксирование не осуществляется, что позволяет избежать непроизводительных затрат ресурсов сервера и SIP клиенты получают возможность взаимодействовать напрямую внутри локальной сети, тогда как все необходимое взаимодействие с серверами по регистрации пользователей по-прежнему осуществляется вне локальной сети.

Минимизация Медиа Проксирования

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


Адреса за NAT

Для того, чтобы обнаружить клиентов за NAT, Серверу необходимо знать, какие адреса используются в удалённый сетях, находящихся за этими NATами.
Для того, чтобы настроить Адреса за NAT, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Сеть, затем откройте страницу NAT.

Адреса за NAT

Если SIP клиент отправляет запрос в CommuniGate Pro и собственный сетевой адрес клиента, указанный в заголовке запроса, включён в список Адреса за NAT, в то время как Сервер получил этот запрос с другого сетевого адреса, НЕ указанного в списке Адреса за NAT, то Сервер решает, что клиент находится за NAT.


Адреса NAT Серверов

Некоторые сервера NAT пытаются исполнить функции "Шлюза прикладного уровня для SIP", изменяя адреса IP в передаваемых ими пакетах SIP.
Многие такие сервера NATсовершают ошибки в этих попытках, и серверу CommuniGate Pro стоило бы работать с клиентами за такими серверами NAT, используя стандартную технику Дальнего прохождения NAT, но CommuniGate Pro не может определить, что это необходимо, поскольку адреса IP в их пакетах SIP были изменены.
Вы можете указать адреса IP таких серверов NAT в списке Адреса NAT Серверов: пакеты , приходящие с адресов из этого списка, обрабатываются так же, как если бы они приходили от клиентов "за NAT":

Адреса NAT Серверов

Может возникнуть необходимость отправлять запросы на удалённые сервера SIP (например, шлюзы в ТфОП), расположенные за дальним NAT. Поскольку такие сервера не присылают запросы SIP REGISTER на сервер CommuniGate Pro, нет автоматического способа определить необходимость использования дальнего прохождения NAT.
Включите публичные сетевые адреса таких удалённых серверов SIP в список Адреса NAT Серверов, чтобы уведомить Модуль SIP сервера CommuniGate Pro о необходимости использования техник Дальнего прохождения NAT при работе с этими серверами SIP.

Когда клиенты соединяются с сервером CommuniGate Pro из-за файрвола NAT с несколькими публичными адресами, сигнальные запросы (SIP, XIMSS) и потоки медиа (RTP) могут приходить с разных адресов IP.
Когда клиент использует запросы HTTP для сессий Веб Интерфейса Пользователя или XIMSS, запросы HTTP могут приходить с разных публичных адресов.
В таких ситуациях клиенты могут страдать от потери медиа потоков или прерываний сессий из-за запросов с "неправильного адреса IP".

Во избежание таких проблем, два разных адреса IP такого файрвола могут считаться "тем же" адресом, если они оба входит в один диапазон адресов, добавленный в список Адресов NAT Серверов.


Дёргатель NAT-Клиентов

Для того, чтобы позволить другим пользователям осуществлять входящие вызовы клиента SIP, находящегося за NAT, CommuniGate Pro сохраняет "коммуникационный канал" между клиентом и Сервером открытым, периодически отправляя фиктивные пакеты этому клиенту.

Дёргатель NAT-Клиентов
Уровень Журнала: Число Клиентов: Дёргать Клиентов каждые:UDP:
  TCP:
Уровень Журнала
Используйте эту настройку, чтобы указать, какую информацию компонент Дёргатель NAT-Клиентов должен сохранять в Журнале работы Сервера. Обычно используется уровень Основное или уровень Проблемы (не фатальные ошибки).
Записи, помещённые компонентом Дёргатель NAT-Клиентов в Системный Журнал работы Сервера, имеют пометку NATPING.
Число Клиентов
Используйте эту настройка для указания количества разных NAT клиентов, который Сервер может дёргать.
Дёргать Клиентов каждые
Используйте эту настройку для указания того, как часто Сервер должен отправлять "дёргающие" пакеты.

Проксирование Медиа

CommuniGate Pro поддерживает разнообразные коммуникации в реальном времени. Большинство таких протоколов реального времени не может работать через NAT/Firewall, но CommuniGate Pro может действовать как "прокси" для таких протоколов.

Когда клиент локальной сети пытается соединиться с удалённой системой через Интернет (WAN), CommuniGate Pro создаёт Медиа Прокси - некий коммуникационный порт на своей системе.
Он заставляет клиента соединяться с этим Медиа Прокси вместо того, чтобы соединяться непосредственно с медиа-портом удалённой системы.
Медиа Прокси CommuniGate Pro сам взаимодействует с удалённой системой, ретранслируя все данные, получаемые от клиента из локальной сети на удалённую систему и обратно.

Проксирование Медиа создано для того, чтобы обеспечить возможность обслуживания пользователей, находящихся за удалёнными NAT устройствами.

Проксирование Медиа так же используется для ретранслирования трафика между IPv4 и IPv6 сетями.

Проксирование Медиа
Уровень Журнала: Тэг UDP TOS:
Проверять порт источника: Проксировать для клиентов за общим NAT:
Уровень Журнала
Используйте эту настройку для того, чтобы указать какую информацию компонент Прокси должен сохранять в Журнале работы Сервера. Обычно используется уровень Основное или уровень Проблемы (не фатальные ошибки). В случае, если в работе компонента Прокси возникают проблемы, то, возможно, целесообразным будет увеличить детализацию до уровня Подробности или Всё: в этом случае в Системный Журнал будет записываться более подробная информация о работе модуля на уровне протокола или на уровне ссылок.
Записи, помещённые компонетом Медиа прокси в журнал работы Сервера, имеют пометку MEDIAPROXY .
Для Медиа прокси может быть создано несколько потоковых прокси для каждого медиа потока (например, один прокси для медиа потока аудио, и ещё один - для видео потока). Записи, помещённые компонентом Прокси в Журнал работы Сервера, имеют пометку UDPPROXY или TCPPROXY.
Проверять порт источника
Когда эта опция включена, данные медиа, передающиеся по UDP из внешних источников, принимаются в случае прихода с корректного IP адреса и номера порта.
Если эта опция не задана, проверяется только IP адрес источника медиа. Это помогает при работе с медиа устройствами. которые указывают неправильный порт в SDP.
UDP TOS Тэг
Если эта опция не установлена в значение выбор ОС, то UDP пакеты с медиа данными получают указанное значение тэга TOS (тип сервиса). Это может быть полезным при задании приоритетов медиа трафика в случае, если ваша сетевая инфраструктура может назначать более высокий приоритет пакетам с указанным значением тэга TOS.
Проксировать для клиентов за общим NAT
Когда два клиента расположены за общим дальнми NAT (то есть, их видимые публичные адреса одинаковы), с помощью этой опции можно управлять созданием Медиа прокси для таких клиентов.
Никогда
Медиа прокси для таких клиентов не строится. Используйте эту опцию, когда клиенты за общим NAT могут взаимодействовать напрямую.
NAT Сервера
Медиа прокси будет построен, если видимые адреса клиентов пересекаются со списком Адресов NAT Серверов.
Всегда
Медиа прокси для таких клиентов строится всегда.

Обратите внимание: некоторые системы NAT имеют несколько публичных адресов. В этом случае сигнальные запросы могут приходить с одного сетевой адреса такой системы, а медиа потоки могут приходить с другого сетевого адреса.
Медиа прокси CommuniGate Pro может поддерживать такие системы NAT , если все их публичные адреса входят в один общий диапазон сетевых адресов, указанный в списке Адресов NAT Серверов.


Руководство CommuniGate® Pro. Copyright © 1998-2017, Stalker Software, Inc.