8(499)-709-97-83
Работаем с 8:00 до 19:00

NAT и как его обойти. Протоколы TURN, RSIP и ICE

  • 12 февраля 2015

Мы уже рассказывали о проблемах прохождения NAT (и о том какие виды NAT бывают), используя протокол STUN. Посмотреть это можно здесь, здесь и здесь. Протокол STUN это один из первых протоколов, используемых для прохождения NAT. STUN корректно работает при использовании Port Restricted Cone NAT, а иногда и с Restricted Cone NAT. Так же, есть проблема с прохождением TCP трафика, через STUN. Но прогресс не стоит на месте и сегодня мы рассмотрим более совершенные протоколы TURN (Traversal Using Relay NAT), ICE (Interactive Connectivity Establishment) и RSIP (Realm-Specific IP).

Вспомним какие бывают виды 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 такого типа, проверяется транспортный протокол, адрес и порт назначения, а также адрес и порт источника.
 

Протокол TURN

Рассмотрим принцип работы протокола TURN. Вначале устройство, сидящее за NAT посылает запрос к TURN серверу для обнаружения своего внешнего IP адреса (запрос напоминает работу со STUN сервером). Однако, вместо того, чтобы отправить клиенту его публичный IP адрес, сервер посылает свой собственный внешний IP адрес и порт. TURN сервер также следит за внешним IP адресом и портом VoIP клиента. VoIP клиент, получив внешний IP адрес TURN сервера, посылает эту информацию в сторону вызываемого клиента VoIP (в SIP пакете). Соответственно вызываемый клиент начинает отправлять сигнальный и медиатрафик на публичный IP адрес TURN сервера.

Таким образом RTP поток направлен на TURN сервер.Так как TURN сервер уже получил внешний IP адрес VoIP клиента, находящегося за NAT, то он может направить поток RTP на этот IP адрес. Т.е. TURN сервер служит неким прокси-сервером для всего последующего сигнального и медиатрафика. К сожалению, это довольно ресурсоемкий метод обхода NAT, с точки зрения сложности управления TURN сервером. По этому использование TURN сервера желательно использовать, только в крайнем случае.

Минусом данного метода являются большие задержки из-за проксирования трафика и повышается вероятность потери пакетов. С недавнего времени TURN больше не считается самостоятельным протоколом: сейчас он описан как расширение к STUN.

Схема работы через TURN сервер представлена на картинке ниже.

RSIP

Realm-Specific IP экспериментальный протокол от IETF, протокол работает как альтернатива NAT`у.

RSIP позволяет зарезервировать хосту один или несколько публичных IP адресов (и TCP/UDP порты к этому IP адресу) на одном или нескольких RSIP шлюзах.

RSIP клиент запрашивает регистрацию на RSIP шлюзе. Шлюз, в свою очередь, обеспечивает либо уникальный (публичный) IP адрес или общий для всех IP адрес, но с уникальным набором портов TCP/UDP и связывает RSIP адрес клиента с своим публичным адресом. RSIP клиент использует этот адрес для отправки пакетов по своему назначению. RSIP шлюз создает "туннель", подменяя заголовки IP пакетов источника своим IP адресом и далее направляя запросы в "мир".

RSIP также может быть использован для передачи трафика между несколькими хостами в приватных сетях.

Технология RSIP должна быть полезна при прохождения NAT. RSIP может использоваться в качестве альтернативы для Universal Plug & Play (UPnP).

Протокол ICE

Протокол ICE (Interactive Connectivity Establishment), разработанный рабочей группой MMUSIC IETF, обеспечивает прохождение трафика через различные устройства NAT. Это облегчает использование VoIP телефонии в повседневной жизни, когда необходимо подключить удаленных пользователей к вашей АТС.

ICE определяет стандартный метод взаимодействия для SIP клиентов (или для клиентов, работающих на других IP протоколах), который позволяет определить, какой тип NAT существуют между клиентами и определить существующий список IP адресов, по которым клиенты могут связаться друг с другом. Используя протоколы и механизмы подключения к сети, такие как STUN, Traversal Using Relay NAT (TURN) и Realm Specific IP (RSIP), ICE узнает о топологии сети, в которой расположены SIP клиенты и их IP адреса.

Когда клиент, c поддержкой ICE, хочет установить сессию с другими устройствами, он сначала собирает информацию о доступных IP адресах (используя протоколы STUN, TURN, RSIP), а так же информацию о настроенных IP адресах на его сетевых интерфейсах, с которых он может получать сетевой трафик. Главным преимуществом, которым обладает протокол ICE, является способность объединять полученную информацию о доступных IP и соответственно строить наиболее удобные маршруты к этим IP адресам.

После сбора IP адресов, SIP клиент отправляет полученную информацию о структуре сети в сторону STUN сервера, а далее отправляет сообщение инициализации сессии в сторону нужного абонента. Это сообщение содержит все комбинации известных ему IP адресов, которые SIP клиент (инициатор сессии) узнал, на этапе сканирования сети.

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

Протокол ICE вобрал в себя все самое лучше от своих предшественников. ICE выполняет всю грязную работу по преодолению различных NAT устройств. Теперь нет необходимости дополнительно настраивать ваши роутеры и маршрутизаторы, для работы с VoIP телефонией.

 

Официальное описание TURN приведено здесь.

Официальное описание RSIP приведено здесь.

Официальное описание ICE приведено здесь.

Некоторые материалы взяты отсюда.

Если вы в статье нашли ошибки или несоответствия, мы будем благодарны, если вы напишите нам о них в комментариях.

 
Powered by SEO CMS ver.: 23.1 TOP 2 (opencartadmin.com)