Stun протокол – Протокол STUN часть 1

voipnotes.ru

Что такое STUN и зачем он нужен?

Так случилось, что очень много пользователей сидят в интернете за NAT (Network Address Translation). Например, наш компьютер в локальной сети имеет IP-адрес 192.168.1.100. Адресов диапазона 192.168.x.x в Интернете быть не может (он зарезервирован для локальных сетей), и такой пакет к отправителю не вернется. Когда пакет из локалки уходит в интернет, NAT (обычно это часть функционала шлюза в интернет) подменяет в нем адрес отправителя на внешний (публичный) адрес NATа, например 1.2.3.4. Когда получатель пакета получит его и решит отправить ответ, то он пошлет его на внешний адрес NATа. А внутри себя NAT заменит адрес обратно на 192.168.1.100 и дошлет пакет компьютеру в локалку.

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

Вроде бы все работает прозрачно для сидящих за NATом компьютеров. Проблема возникает тогда, когда компьютеры сначала договариваются о передаче данных по одному протоколу, сообщая друг другу свои IP-адреса, через которые пойдет обмен (конечно, NAT про протоколы не знает, ему важны номера портов), а потом начинается собственно передача данных. Именно так происходит установление соединения в VoIP — договариваются хосты о соединении по SIP, сообщая друг другу адреса и номера портов для голосовых RTP-потоков по SDP, а обмен идет уже по RTP.

Компьютер с адресом 192.168.1.100 посылает VoIP-шлюзу во внешней сети свой адрес и порт, допустим, 192.168.1.100:40000. Шлюз после установления соединения начинает отправлять RTP поток… куда? Адрес-то левый! В итоге абонент в телефонной сети со стороны шлюза слышит голос из локалки, а его — не слышат. Типичный случай «one-way-voice».

Поэтому компьютер в локальной сети должен сначала узнать свой внешний адрес и номер порта. Для этого в интернете существуют STUN-серверы. Упрощенно это выглядит так: компьютер из локалки посылает STUN-серверу пакет, тот его получает и отправляет обратно, запихнув внутрь адрес и номер порта, с которых он их получил. Дальше предпринимаются еще несколько действий для выяснения типа NATa, но это уже не так важно и хорошо описано в статье по ссылке выше.

Теперь дело техники: компьютер в локалке передаст в SDP не свой локальный адрес, а полученный через STUN. Путь пакетам уже «пробит» запросом к STUN-серверу (т.е. NAT установил соответствие локальный хост : порт <-> внешний порт), поэтому входящие извне пакеты попадут в локалку и слышимость будет обоюдная.

Источник: http://sergetk.livejournal.com/28193.html

mt-ftc.ru

Протокол STUN в VoIP телефонии

Современные routers with voipимеют встроенный сервис STUN. Благодаря этому они способны эффективно обходить механизмы NAT. Аббревиатуру STUN можно расшифровать как Simple Traversal of UDP through NATs, что означает “простой обход UDP через NAT”.

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

Принцип действия

Многие протоколы применяют UDP-пакеты при отправке голосового трафика, а также текстового или графического контента по IP-сетям. Однако в случае, когда оба устройства, принимающие участие в передаче данных, не попадают в зону действия NAT, невозможно установить соединение между ними стандартным способом. Именно в таких ситуациях и приходит на помощь STUN.

Он представляет собой клиент-серверный интернет-протокол. Суть его работы заключается во взаимодействии STUN-клиента (объекта, генерирующего запросы) и STUN-сервера (объекта, принимающего запросы и отправляющего ответы). Клиент посылает запрос к STUN-серверу. Последний осуществляет отправку сведений об адресе брандмауэра NAT, а также о том, какой из портов на данный момент открыт для получения запросов внутри IP-сети.

Интересуетесь VoIP технологиями? Ищете надежный стартап в телекоммуникационном секторе? Тогда вас заинтересует возможность начать бизнес в сфере GSM терминации. Максимальная прибыль при минимальных вложениях! Мы предлагаем готовое решение для новичков от GoAntiFraud, которое включает в себя широкие возможности для эффективной VoIP терминации, а также комплект оборудования GoIP, EjoinTech & China Skyline по низкой стоимости.

Помимо этого, отправляются данные о типе трансляции адреса. Разные брандмауэры/маршрутизаторы производят обработку пакетов UDP различными способами. Протокол STUN, как правило, работает с 4 видами NAT:

• Full Cone;
• Symmetric;
• Adress Restricted;
• Port Restricted.

Как устанавливается соединение

Соединение клиента и сервера осуществляется посредством TCP/UDP порта 3478. При этом STUN предлагает клиенту проверить еще один адрес и № порта (поскольку STUN привязан сразу к двум IP-адресам). Обычо выбор порта и адреса происходит в произвольном режиме. Протокол часто применяет служебные записи DNS SRV для поиска STUN серверов, подключенных к домену.

На данный момент у VoIP устройств отсутствует универсальная поддержка протокола STUN. Начиная с 2015 года, он предусматривается по умолчанию, но в устаревших девайсах его нет.

Данный VoIP протокол имеет и некоторые недостатки. Например, он не способен должным образом работать в IP-сетях, где используется Symmetric NAT, поскольку последний постоянно создает новые адреса и порты при попытке внутреннего хоста установить соединение с внешним voip gateway.

Компания GoAntiFraud предлагает вам начать прибыльный бизнес в сфере GSM терминации! Если вам интересны VoIP технологии, мы поможем вам начать собственное дело, приносящее стабильный доход. Купив наш комплексный пакет New Business, вы сразу начнете зарабатывать! Мы предоставим вам полноценное техническое сопровождение на всех этапах бизнеса.

goantifraud.com

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

Мы уже рассказывали о проблемах прохождения 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 приведено здесь.

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

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

voipnotes.ru

STUN — Википедия. Что такое STUN

STUN (сокр. от англ. Session Traversal Utilities for NAT, Утилиты прохождения сессий для NAT, ранее англ. Simple Traversal of UDP through NATs, Простое прохождение UDP через серверы NAT) — это сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта. Эта информация используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT. Протокол определён в рекомендации RFC 5389 (предыдущая версия — RFC 3489).

Обзор протокола

Существуют протоколы, использующие пакеты UDP для передачи голоса или изображений по IP-сетям. Если обе общающиеся стороны находятся за NAT’ом, соединение не может быть установлено обычным способом. Именно здесь STUN и оказывается полезным.

STUN — это клиент-серверный протокол. VoIP-клиент может включать в себя реализацию клиента STUN, который отправляет запрос серверу STUN. Затем сервер STUN отправляет клиенту обратно информацию о том, каков внешний адрес маршрутизатора NAT, и какой порт открыт на NAT для приема входящих запросов обратно во внутреннюю сеть.

Ответ также позволяет клиенту STUN определить, какой тип трансляции адреса используется, поскольку различные типы маршрутизаторов NAT обрабатывают входящие UDP пакеты по-разному. STUN работает с тремя из четырёх основных типов: Full Cone NAT, Symmetric NAT, Address Restricted NAT и Port Restricted NAT. В случае ограничивающего NAT клиент должен отправить пакет на удаленный узел, прежде чем NAT начнет пропускать пакеты от удаленного узла к клиенту. STUN не будет работать с симметричным NAT’ом (также называемым «двусторонний NAT»), который часто встречается в сетях больших компаний. При симметричном NAT IP-адрес сервера STUN отличается от конечного адреса, и из-за этого адрес NAT, который видит STUN-сервер, отличается от конечного адреса, который будет использоваться для отправки пакетов клиенту.

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

Нужно отметить, что методы, описываемые в рекомендации RFC 3489, не обязательно требуют использования протокола STUN; они могут использовать в рамках любого протокола, основанного на UDP.

Соединение с STUN-сервером устанавливается через UDP-порт 3478, однако сервер предлагает клиентам выполнить проверку также и альтернативного IP-адреса и номера порта (у серверов STUN есть два IP-адреса). RFC устанавливает, что выбор порта и IP является произвольным.

См. также

Ссылки

• STUNT — «STUN and TCP too», расширение STUN для включения функциональности TCP

Реализация

Публичные STUN-серверы

• stun.ekiga.net
• stun.sipnet.ru
• stun.ideasip.com (без поддержки XOR_MAPPED_ADDRESS)
• stun.softjoys.com (нет записи DNS SRV) (без поддержки XOR_MAPPED_ADDRESS)
• stun.voipbuster.com (нет записи DNS SRV) (без поддержки XOR_MAPPED_ADDRESS)
• stun.voxgratia.org (нет записи DNS SRV) (без поддержки XOR_MAPPED_ADDRESS)
• stun.sipgate.net:10000
• numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS только при наличии волшебных номеров в transaction ID, как в rfc3489bis)
• stun.ipshka.com (подробнее: http://www.ipshka.com/main/help/hlp_stun.php {{{1}}})
• stun.phonepower.com
• stun.1und1.de
• stun.bluesip.net
• stun.callwithus.com
• stun.counterpath.net
• stun.e-fon.ch
• stun.endigovoip.com
• stun.gmx.net
• stun.ideasip.com
• stun.noc.ams-ix.net
• stun.phoneserve.com
• stun.sipgate.net
• stun.voip.aebc.com
• stun.voipgate.com
• stun.voxgratia.org
• stun1.voiceeclipse.net
• provserver.televolution.net
• stun.internetcalls.com
• stun.sipdiscount.com
• stun.softjoys.com
• stun.t-online.de
• stun.voipbuster.com
• stun.voipcheap.com
• stun.voipplanet.nl
• stun.voipraider.com

wiki.sc

STUN — Википедия

Материал из Википедии — свободной энциклопедии

STUN (сокр. от англ. Session Traversal Utilities for NAT, Утилиты прохождения сессий для NAT, ранее англ. Simple Traversal of UDP through NATs, Простое прохождение UDP через серверы NAT) — это сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта. Эта информация используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT. Протокол определён в рекомендации RFC 5389 (предыдущая версия — RFC 3489).

Обзор протокола

Существуют протоколы, использующие пакеты UDP для передачи голоса или изображений по IP-сетям. Если обе общающиеся стороны находятся за NAT’ом, соединение не может быть установлено обычным способом. Именно здесь STUN и оказывается полезным.

STUN — это клиент-серверный протокол. VoIP-клиент может включать в себя реализацию клиента STUN, который отправляет запрос серверу STUN. Затем сервер STUN отправляет клиенту обратно информацию о том, каков внешний адрес маршрутизатора NAT, и какой порт открыт на NAT для приема входящих запросов обратно во внутреннюю сеть.

Ответ также позволяет клиенту STUN определить, какой тип трансляции адреса используется, поскольку различные типы маршрутизаторов NAT обрабатывают входящие UDP пакеты по-разному. STUN работает с тремя из четырёх основных типов: Full Cone NAT, Symmetric NAT, Address Restricted NAT и Port Restricted NAT. В случае ограничивающего NAT клиент должен отправить пакет на удаленный узел, прежде чем NAT начнет пропускать пакеты от удаленного узла к клиенту. STUN не будет работать с симметричным NAT’ом (также называемым «двусторонний NAT»), который часто встречается в сетях больших компаний. При симметричном NAT IP-адрес сервера STUN отличается от конечного адреса, и из-за этого адрес NAT, который видит STUN-сервер, отличается от конечного адреса, который будет использоваться для отправки пакетов клиенту.

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

Нужно отметить, что методы, описываемые в рекомендации RFC 3489, не обязательно требуют использования протокола STUN; они могут использовать в рамках любого протокола, основанного на UDP.

Соединение с STUN-сервером устанавливается через UDP-порт 3478, однако сервер предлагает клиентам выполнить проверку также и альтернативного IP-адреса и номера порта (у серверов STUN есть два IP-адреса). RFC устанавливает, что выбор порта и IP является произвольным.

Видео по теме

См. также

Ссылки

• STUNT — «STUN and TCP too», расширение STUN для включения функциональности TCP

Реализация

Публичные STUN-серверы

• stun.ekiga.net
• stun.sipnet.ru
• stun.ideasip.com (без поддержки XOR_MAPPED_ADDRESS)
• stun.softjoys.com (нет записи DNS SRV) (без поддержки XOR_MAPPED_ADDRESS)
• stun.voipbuster.com (нет записи DNS SRV) (без поддержки XOR_MAPPED_ADDRESS)
• stun.voxgratia.org (нет записи DNS SRV) (без поддержки XOR_MAPPED_ADDRESS)
• stun.sipgate.net:10000
• numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS только при наличии волшебных номеров в transaction ID, как в rfc3489bis)
• stun.ipshka.com (подробнее: http://www.ipshka.com/main/help/hlp_stun.php {{{1}}})
• stun.phonepower.com
• stun.1und1.de
• stun.bluesip.net
• stun.callwithus.com
• stun.counterpath.net
• stun.e-fon.ch
• stun.endigovoip.com
• stun.gmx.net
• stun.ideasip.com
• stun.noc.ams-ix.net
• stun.phoneserve.com
• stun.sipgate.net
• stun.voip.aebc.com
• stun.voipgate.com
• stun.voxgratia.org
• stun1.voiceeclipse.net
• provserver.televolution.net
• stun.internetcalls.com
• stun.sipdiscount.com
• stun.softjoys.com
• stun.t-online.de
• stun.voipbuster.com
• stun.voipcheap.com
• stun.voipplanet.nl
• stun.voipraider.com

wiki2.red