Обход NAT с пограничными контроллерами сеансов

Трансляторы сетевых адресов (NAT) используются для преодоления нехватки адресов IPv4 , скрывая сеть предприятия или даже оператора за одним или несколькими IP-адресами . Устройства за NAT используют частные IP-адреса , которые не маршрутизируются в общедоступном Интернете. Протокол инициирования сеанса (SIP) зарекомендовал себя как стандарт де-факто для передачи голоса по IP (VoIP). Чтобы установить вызов, вызывающий абонент отправляет SIP- сообщение, содержащее его собственный IP-адрес. Предполагается, что вызываемый абонент ответит SIP-сообщением, предназначенным для IP-адресов, включенных в полученное SIP-сообщение. Это, очевидно, не будет работать, если вызывающий абонент находится за NAT и использует частный IP-адрес.

Вероятно, самой большой ошибкой при разработке SIP было игнорирование существования NAT. Эта ошибка возникла из-за убеждения руководства IETF в том, что пространство IP-адресов будет исчерпано быстрее и потребует глобального обновления до IPv6 и устранения необходимости в NAT. Стандарт SIP предполагал, что NAT не существует, но это предположение оказалось неудачным. SIP просто не работал у большинства пользователей Интернета, использующих NAT. В то же время стало очевидно, что жизненный цикл стандартизации медленнее, чем рынок: пограничные контроллеры сеансов (SBC) родились и начали исправлять то, что не смогли сделать стандарты: обход NAT .

Если пользовательский агент расположен за NAT, он будет использовать частный IP-адрес в качестве своего контактного адреса в контакте и через заголовки, а также в части SDP . Эта информация тогда будет бесполезна для любого, кто попытается связаться с этим пользовательским агентом из общедоступного Интернета.

Существуют различные решения для обхода NAT, такие как STUN , TURN и ICE. Какое решение использовать, зависит от поведения NAT и сценария вызова. При использовании SBC для решения проблем прохождения NAT наиболее распространенным подходом является использование SBC в качестве общедоступного интерфейса пользовательских агентов. Это достигается путем замены контактной информации пользовательского агента на информацию SBC.

Обработка SBC регистрации пользователей и прохождения NAT

Обработка прохождения NAT с помощью SBC во время установления вызова

Чтобы пользовательский агент был доступен через общедоступные интерфейсы SBC, SBC будет манипулировать регистрационной информацией пользовательского агента. Пользователь включает свой частный IP-адрес в качестве контактной информации в запросах REGISTER . Вызовы на этот адрес завершится неудачно, поскольку он не маршрутизируется публично. SBC заменяет информацию в заголовке контакта своим собственным IP-адресом. Это информация, которая затем регистрируется у регистратора. Вызовы, предназначенные пользователю, затем будут перенаправляться на SBC.

Чтобы SBC знал, с каким агентом пользователя на самом деле связываются, SBC может сохранить локальную копию регистрации агента пользователя. пользователя, Локальная копия включает в себя частный IP-адрес и SIP URI а также общедоступный IP-адрес, включенный в IP-заголовок, который был назначен сообщению SIP с помощью NAT.

В качестве альтернативы SBC может хранить эту информацию в пересылаемых сообщениях SIP. Это показано на рисунке здесь. Контактная информация пользователя объединяется в специальный формат и добавляется в качестве дополнительного параметра в заголовок контакта. Контактная информация включает частный IP-адрес пользователя и SIP URI, а также общедоступный IP-адрес в IP-заголовке сообщения SIP. Когда регистратор получит запрос на пользователя, регистратор вернет полную контактную информацию прокси-серверу, который включит эту информацию в SIP-сообщение. Затем SBC может получить эту информацию из запроса SIP и использовать ее для правильной маршрутизации запроса пользователю.

Добавление контактной информации пользовательского агента к зарегистрированной контактной информации имеет множество преимуществ. Поскольку SBC не нужно хранить локальную регистрационную информацию, это решение легко реализовать и не требует памяти для хранения информации. Кроме того, запросы, предназначенные пользовательскому агенту, не обязательно должны проходить через SBC, который обработал регистрационные сообщения пользовательского агента. Любой SBC, который может связаться с пользовательским агентом, может правильно маршрутизировать сообщения, предназначенные пользовательскому агенту, на основе информации, включенной в запрос SIP. Однако это преимущество применимо только в некоторых случаях. Если NAT, используемый перед пользовательским агентом, принимает трафик только с IP-адресов, с которыми пользовательский агент ранее связывался, тогда только SBC, который обработал запросы REGISTER пользовательского агента, сможет связаться с пользовательским агентом.

Другой вариант — сохранить локальную копию регистрационной информации, что, однако, может увеличить требования к обработке на SBC. SBC придется управлять местной регистрационной базой данных. Помимо требований к памяти, SBC придется реплицировать эту информацию в систему резервного копирования, чтобы обеспечить высокую доступность. Это еще больше увеличит требования к обработке на SBC и увеличит потребление полосы пропускания.

Однако хранение локальной копии регистрационной информации также имеет свои преимущества. При получении сообщения от пользовательского агента транслятор сетевых адресов связывает частный IP-адрес пользовательского агента с общедоступным IP-адресом. Эта привязка будет оставаться активной в течение определенного периода времени – периода привязки. Если пользовательский агент не отправляет и не получает никаких сообщений в течение периода времени, превышающего период привязки, NAT удалит привязку, и пользовательский агент больше не будет доступен извне. Чтобы привязка оставалась активной, пользовательскому агенту придется регулярно ее обновлять. Это достигается за счет отправки запросов REGISTER через интервалы времени, меньшие, чем период привязки. Поскольку сообщения REGISTER обычно требуют аутентификации, необходимость иметь дело с сообщениями REGISTER, отправляемыми с высокой частотой, приведет к значительному снижению производительности инфраструктуры оператора. SBC могут помочь разгрузить эту нагрузку. Когда пользовательский агент отправляет первый запрос REGISTER, SBC пересылает запрос REGISTER на серверы регистрации оператора. После того как регистрация будет успешно подтверждена и принята оператором, SBC сохранит локальную копию регистрационной информации. Вместо пересылки каждого входящего запроса REGIETER на серверы регистрации оператора SBC будет отправлять запросы REGISTER на серверы регистрации только через довольно большие промежутки времени (в диапазоне часов). Запросы на регистрацию, поступающие от пользовательского агента, которые не меняют информацию о регистрации контента, будут обработаны самим SBC. SBC также проинформирует сервер регистрации об истечении срока действия или изменении локальной регистрации.

Обработка SBC установления вызова и прохождения NAT

Обход NAT с SBC во время регистрации пользователя

Как и в случае с регистрацией, SBC также будет включать себя в путь INVITE и других сообщений запроса. При получении INVITE от пользовательского агента за NAT SBC включит заголовок via со своим собственным адресом, заменит информацию в заголовке контакта своим собственным адресом, а также заменит информацию об адресе в теле SDP своим собственным адресом. Таким образом, все сообщения SIP и медиа-пакеты будут проходить через SBC.

Обработка SBC медиа-пакетов и обход NAT

После установления вызова с использованием SIP происходит обмен медиа-пакетами, а именно голосом, видео или данными, обычно с использованием транспортного протокола реального времени (RTP). Хотя прохождение SIP-сообщений через NAT в конце концов может показаться сложным, еще более сложной задачей является обеспечение возможности прохождения мультимедиа через NAT. Исходная постановка задачи та же. Если устройства SIP за NAT объявляют свои IP-адреса, их одноранговые узлы на другой стороне NAT не смогут маршрутизировать к ним трафик. Решение, предложенное SBC, просто игнорирует принцип работы SIP. Вместо отправки мультимедиа на IP-адрес и номер порта, объявленные в телах SIP SDP, SBC отправляют мультимедиа для пользовательского агента симметрично обратно туда, откуда агент отправил свои собственные мультимедиа. Эта симметричная связь обычно работает, потому что это модель трафика, к которой производители NAT привыкли до появления VoIP .

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

Другим заметным недостатком является «треугольная маршрутизация»: SBC должен ретранслировать весь трафик VoIP для вызова, чтобы сделать пути вызывающий абонент-SBC и SBC-вызываемый симметричными. На самом деле это большие накладные расходы для оператора VoIP. При использовании наиболее распространенного кодека G.711 ретранслируемый вызов потребляет четыре потока со скоростью 87,2 кбит/с: два исходящих и два входящих.

Могут возникнуть и некоторые другие тревожные ограничения. Например, если устройство SIP использует обнаружение голосовой активности (VAD) и изначально не может отправить какие-либо голосовые пакеты, SBC не узнает свой адрес и не будет пересылать на него входящие мультимедиа.