Stun server что это

Что такое 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 подменяет еще и номер порта, и помещает его в таблицу соответствий номеров портов и внутренних адресов.

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

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

© 2005-2021 Федеральная инжиниринговая сеть МТ-ТЕХНО

Источник

Как отлаживать WebRTC

В Voximplant мы используем WebRTC с момента ее появления: сначала как альтернативу Flash для голосовых и видеозвонков, а затем как полную замену. Технология прошла долгий и болезненный путь развития, только недавно ее стали поддерживать все основные браузеры, есть сложности с передачей экрана, нескольких видеопотоков, а иногда браузер падает просто если выключить и включить видеопоток. Накопленный опыт позволяет переводить для Хабра интересные статьи, и сегодня мы передаем слово Ли Сильвестру из Xirsys, который расскажет про отладку (видео)звонков в Chrome, Firefox, Safari и Edge. Отлаживать WebRTC непросто, у нас даже есть специальные инструкции по снятию логов в популярных браузерах. А что есть у Ли – вы узнаете под катом (спойлер: много всего, включая WireShark).

Темная сторона WebRTC

Работая в Xirsys, я видел несколько действительно крутых приложений, которые использовали WebRTC. Но пока небольшая группа разработчиков создает высокотехнологичные штуки, большая часть программистов не могут даже начать использовать WebRTC. Почему? А все просто. Оно сложное.

Многим из нас знакомо типичное веб-приложение. У такого приложения есть клиент, который отправляет запросы и сервер, который на эти запросы отвечает. Простой, линейный и легко предсказуемый процесс. Если что-то пойдет не так, мы обычно знаем где смотреть логи и что могло случиться. А вот с WebRTC все не так просто.

Асинхронность

Если вы когда-нибудь писали многопоточное приложение, то наверняка знаете о той головной боли, которую доставляет подобная разработка. Рейсы, битая память, — но чаще всего просто баги, которые трудно искать.

WebRTC асинхронно по своей природе. И это совсем не простенькая асинхронность AJAX. Если проводить аналогию, то это несколько одновременно запущенных AJAX запросов, которые пытаются согласовать данные на двух компьютерах. То еще развлечение.

Минное поле обхода NAT

Создание веб-приложений сводится к разработке чего-то, что запускается на сервере и отвечает на запросы. Самое страшное что может случиться — это не открытый в IPTables порт. Лечится за 2 минуты. Чего не скажешь о WebRTC.

Веб-серверы, даже не их софт, а железо — это устройства с публичными IP-адресами. Они сделаны, чтобы быть доступными откуда угодно. А WebRTC сделано, чтобы отправлять и принимать данные с компьютеров пользователей. Которые обычно имеют IP-адреса 192.168.что-нибудь и не горят желанием отвечать на сетевые запросы.

Авторы WebRTC об этом знают, поэтому движок будет перебирать разные способы подключения, в попытке установить связь между двумя не очень предназначенными для такого компьютерами.

Где начинать отладку

В этой статье я рассказываю про основной инструментарий для решения самых популярных проблем. Но перед этим давайте посмотрим, как WebRTC обычно устанавливает подключение.

Как WebRTC устанавливает подключение

Все подключения WebRTC требуют «небольшой помощи» со стороны сигнального протокола. «Небольшая помощь» — это ваш собственный сервер и протокол, с помощью которого звонящий сможет пообщаться с тем, кому звонит, прежде чем установить Peer-to-peer подключение.

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

Обычно используется протокол COMET (или SIP — примечание переводчика) и веб-сокеты. WebRTC ничем не ограничивает разработчиков, так что можно использовать что нравится, хоть передавать данные через Notepad и копипасту (делали на одном из воркшопов, работает — снова переводчик). Подключенное к обоим компьютерами сигналирование позволяет начать подключение уже по WebRTC.

Offer и answer

WebRTC подключения используют «offer» и «answer»:

ICE-кандидаты

Но одних возможностей по работе с медиаданными мало. Ведь договаривающиеся стороны еще ничего не сказали о состоянии сети.

Узнать, какие видеокодеки поддерживает браузер и есть ли на ноутбуке камера, можно почти мгновенно. Узнать свой внешний IP-адрес и логику работы NAT занимает время, и обмен информацией о состоянии сети происходит по мере получения этой информации.

Благодаря технологии Trickle ICE (поддерживается не всеми браузерами — примечание переводчика) подключение между двумя WebRTC-устройствами может установиться в любой момент – как только будет найден подходящий «кандидат».

Разработчик должен подписаться на событие onicecandidate (все строчные!) и передавать другой стороне получаемые SDP-пакеты, где их нужно передаваться WebRTC с помощью метода addIceCandidate (а вот здесь, сюрприз, заглавная буква). Работает в обе стороны.

Подключение

Для установки подключения WebRTC использует такие штуки как STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relay around NAT). Звучит страшно, но на самом деле всего лишь два сетевых протокола.

STUN-сервер

Первый из двух протоколов чуть сложнее эхо-сервера. Когда участники подключения хотят описать как к ним подключаться, им нужен их публичный IP-адрес. И скорее всего это не будет IP-адрес компьютера, пользовательским устройствам редко выделяют публичные адреса. Целую технологию NAT придумали, чтобы не выделять. Чтобы все-таки узнать свой публичный адрес, браузер делает запрос к STUN серверу. Проходя через NAT, сетевой пакет меняет свой обратный адрес на публичный. Получив пакет с запросом, STUN-сервер копирует обратный адрес пакета в его payload и отправляет пакет обратно. Проходя через NAT в обратную сторону, пакет теряет публичный IP-адрес, но копия этого адреса остается в payload, где ее может прочитать WebRTC.

TURN-сервер

TURN-сервер использует расширение STUN-протокола. Те же пакеты, заголовки, плюс новая штука: command. Сервер является прокси: оба клиента подключаются к нему через UDP-порт allocation и передают через сервер свои данные.

TURN-серверы устроены таким образом, что инициатор подключения имеет больше возможностей, чем другая сторона. Это приводит к интересному эффекту, когда звонок через TURN сервер будет успешным или неуспешным в зависимости от того, кто кому звонит (все вспоминаем скайп — примечание переводчика).

Отладка

Итак, вы дочитали до этого параграфа. Мы с переводчиком рады и помним, что статья об отладке WebRTC. Но все написанное выше — необходимый минимум, без которого можно даже не начинать. А вот если начать, и вы не располагаете нечеловеческим везением, то оно будет ломаться.

Оно будет ломаться множеством разных способов. Первый из них: отсутствие подключения. Вы передали обоим WebRTC настройки STUN и TURN-серверов, помогли им обменяться offer, answer и ICE кандидатами, а видео или голоса нет. С чего начать? С локального воспроизведения проблемы.

Локальная отладка WebRTC

Как я уже писал выше, основная работа WebRTC происходит на стороне браузера. STUN и TURN-серверы невероятно просты, так что большинство проблем случаются в вашем JavaScript-коде, который выполняется в двух браузерах. Sad but true. С другой стороны, если самое интересное происходит локально в браузерах, то у вас есть широкие возможности по отладке!

Первое что надо проверить — это ваше сигналирование. Именно ваш код передает между браузерами конфигурацию аудио с видео (offer, answer) и информацию о сетевых настройках (ice кандидаты). Вам нужно проверить, какие пакеты были отправлены, какие получены и переданы WebRTC:

Session Description Protocol

Пакеты Offer, Answer и ICE-кандидатов создаются WebRTC в текстовом формате SDP. На первый взгляд содержимое пакетов выглядит страшновато, но с небольшой подготовкой можно извлечь из них много пользы во время отладки. Wikipedia неплохо описывает SDP, но для вас я нашел описание получше.

Самое важное поле в SDP пакетах ICE кандидатов это typ. Для WebRTC поле может иметь одно из трех значений:

typ host

Тип host задает ICE-кандидат на подключение по локальной сети (WebRTC перебирает несколько кандидатов в надежде установить подключение, заранее неизвестно, какой получится — примечание переводчика). Такое подключение не требует ни STUN, ни TURN-сервера, так как в локальной сети устройства часто могут устанавливать сетевые подключения напрямую. При отладке с локальной сети вам достаточно проверить и отладить передачу host-пакетов и убедиться, что устройства могут отсылать друг другу UDP-пакеты. Хотя бывают исключения, на практике я видел конфигурации сети, при которых браузеру требовался TURN-сервер, чтобы подключиться… к себе.

typ srflx

Комбинация букв «srflx» расшифровывается как «Server Reflexive» и маркирует кандидатов на подключение с использованием внешнего IP-адреса, где для подключения достаточно STUN-сервера (при этом используется технология NAT penetration, которая успешна примерно в 80% случаев — примечание переводчика).

typ relay

«Relay» маркирует подключение через TURN-сервер, которое почти всегда успешно. Важно помнить, что WebRTC не обязано создать ровно три разных пакета с полем «typ»; как именно выбираются кандидаты – зависит от имплементации WebRTC в конкретной версии браузера.

Тестирование подключения к устройству

Google предлагает специальное веб-приложение для тестирования WebRTC-подключений на вашем устройстве. Откройте страницу, нажмите кнопку «start» и JavaScript код попробует установить подключение к серверу Google, используя сигналирование, STUN и TURN-серверы Google.

WebRTC Internals

Вы осмотрели все пакеты, проверили код, все выглядит правильно, но не работает? Для таких случаев Google снабдила свой браузер Chrome специальным разделом, который показывает внутренности WebRTC во время установки подключения и немного красивых графиков в случае успешного подключения. Чтобы воспользоваться, откройте в браузере специальную техническую ссылку:

Если у вас уже открыто приложение, использующее WebRTC, то вы сразу увидите кучу технических данных. В противном случае просто откройте еще одну вкладку и в ней что-нибудь, что использует WebRTC. Вкладка отображает все вызовы к объекту RTCPeerConnection и позволяет увидеть в реальном времени как устанавливается подключением.

Настройка ICE

Сверху страницы отображается ICE-строка, которая была использована при инициализации подключения. Если при ее формировании была допущена ошибка, это сразу же будет видно (под «ICE-строкой» автор имеет в виду конфигурацию объекта RTCPeerConnection со списком STUN и TURN-серверов (объект ‘iceServers’) – примечание переводчика). Возможно, там нет списка серверов? Вы должны сконфигурировать объект RTCPeerConnection до того, как сделали первый вызов createOffer или createAnswer.

События RTCPeerConnection

Следующий раздел internals показывает вызовы методов RTCPeerConnection и полученные от объекта события в хронологическом порядке. Ошибки заботливо подсвечиваются красным. Обратите внимание, что подсвеченное красным addIceCandidateFailed часто не является признаком ошибки и подключение может нормально установиться. В случае успешного подключения последним в списке будет событие iceconnectionstatechange с значением complete.

Раздел ‘stats’

Следующий раздел актуален, когда подключение успешно установлено. Он содержит статистику передаваемых данных и сетевые задержки. Два наиболее интересных параметра: ssrc и bweforvideo.

Функция getStats

Часто вы не сможете получить доступ к странице internals. Например, когда проблема случается у вашего пользователя. В таком случае вы можете получить те же данные, что показывает страница internals, вызывая метод getStats у объекта RTCPeerConnection. Этот метод устанавливает функцию обратного вызова, которая будет вызываться WebRTC каждый раз, когда происходит что-нибудь интересное. Вызываемая функция получает объект с теми полями, которые отображает страница internals:

Еще один полезный инструмент – это событие oniceconnectionstatechange объекта RTCPeerConnection. Обработчик события будет получать информацию о прогрессе подключения. Возможные варианты:

Черный прямоугольник вместо видео

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

Как потыкать палочкой снаружи

Кроме самого объекта RTCPeerConnection и отображаемых браузером internals вы можете использовать инструменты анализа сетевых пакетов, такие как Wireshark. Эти инструменты умеют отображать пакеты используемых WebRTC-протоколов. Например, Wireshark покажет вам содержимое STUN-пакетов в главном окне, и их можно отфильтровать, набрав в поле фильтра ключевое слово «stun»:

На что смотреть в ответах серверов? Если вы видите только ответы с типом Binding, это значит поддержку только STUN (рассказ о внешнем IP), и WebRTC сможет предложить только srflx-кандидатов. Если же в ответах есть специфичные для TURN пакеты Allocation и CreatePermission, то у WebRTC будет возможность попробовать подключиться через прокси-сервер. Анализатор пакетов помечает успешные и неуспешные Allocation. Если нет ни одного успешного, то скорее всего переданы неверные параметры доступа к TURN-серверам (которые почти всегда защищают логином и паролем — примечание переводчика).

Если в логе есть пакет CreatePermission Success Response, то можно предположить, что с конфигурацией STUN и TURN все хорошо. А если еще и ChannelBind пакет присутствует, то значит удалось установить подключение к TURN-серверу на высокой скорости.

Проблемы сотовой связи

В моей практике множество WebRTC-решений, устанавливающих подключение по WiFi, не могут подключиться по 3G/4G. Запущенное на мобильном устройстве приложение тяжелее отлаживать: у нас нет такого простого анализатора пакетов как Wireshark, а Safari не умеет показывать WebRTC internals. Логика подсказывает, что если приложение нормально работает по WiFi, то проблема не в самом приложении, а в сотовой связи. Как отладить? Взять ноутбук и подключить к нему 3G донгл. Так у вас появляются анализатор пакетов и удобные логи, с помощью которых можно за разумное время найти корень всех бед.

Источник

Малоизвестные подробности работы NAT

Используя терминологию Cisco, в контексте NAT есть четыре основных определения для IP-адресов. Рассмотрим их на примере, показанном на рисунке ниже. На обоих маршрутизаторах делается NAT (network address translation).

Эта или подобная схема иногда применяется для обеспечения доступа снаружи к хостам, находящимся в локальной сети (например, к веб-серверу или FTP-серверу). Она может также применяться для балансировки нагрузки путем динамического распределения пакетов, приходящих на публичный адрес маршрутизатора, между несколькими серверами, находящимися в локальной сети, и еще в некоторых случаях.

Исторически сложилось так, что именно его, как правило, имеют в виду, когда употребляют термин «NAT», и о нём мы и будем говорить в дальнейшем, ввиду его распространённости.

В конфигурации маршрутизатора указано, что он должен выполнять NAT для всех пакетов, с адресами источника 192.168.0.0/24, пришедших через интерфейс Ethernet0 и отправляемых далее через интерфейс Serial0, а также для ответных пакетов, пришедших через Serial0, для которых есть соответствующая запись в таблице трансляций:

interface Ethernet0
ip address 192.168.0.1 255.255.255.0
ip nat inside

ip nat inside source list MyNetwork interface Serial0 overload
ip access-list extended MyNetwork
permit ip 192.168.0.0 0.0.0.255 any

В результате этого в таблице NAT появится примерно такая запись:

UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53

Здравый смысл подсказывает, что вроде бы не должен. С другой стороны, налицо факт: в нашей таблице NAT черным по белому записано, что пакет с адресом назначения 11.22.33.44 и портом назначения 1053 нужно принять и транслировать в локальную сеть для хоста 192.168.0.141 (который его примет и молча уничтожит, поскольку на этом компьютере не запущено сетевого приложения, которому был бы предназначен этот пакет.)

По этой же причине может не работать DCC chat в клиентах IRC, передача файлов в ICQ и тому подобные вещи, для которых требуется обеспечение беспрепятственного прохождения пакетов непосредственно между пользовательскими компьютерами.

Протокол STUN

Для иллюстрации работы STUN рассмотрим следующий рисунок(взят из статьи «Anatomy: A Look Inside Network Address Translators» в «The IP Journal» Vol.7 Num. 2 за сентябрь 2004 г.).

Клиент STUN встроен в некоторые приложения IP-телефонии, например, X-Pro и X-Lite от компании CounterPath, и в некоторые другие. Консольный клиент STUN под ОС Windows может быть загружен отсюда: http://prdownloads.sourceforge.net/stun/client.exe?download.

Запустив его и указав в качестве параметра командной строки один из публичных STUN-серверов, вы узнаете тип вашего NAT:

STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9

Приведённый выше результат получен на компьютере, находящемся за маршрутизатором ZyXEL Prestige 645R.

Результат для маршрутизатора Cisco 1721 с IOS версии 12.2 в свою очередь выглядит так:

STUN client version 0.94
.
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b

Такой же результат получен для маршрутизатора, построенного на основе FreeBSD, на которой NAT выполнялась демоном natd.

А вот как выглядит результат для PIX (прим. HunSolo)

STUN client version 0.94
.
Primary: Port Restricted Nat, rundom port, no hairpin
Return value is 0xb

Осталось объяснить, что такое «random port», «preserves ports» и «no hairpin» в приведенных выше результатах.

Посмотрим еще раз на строчку из таблицы NAT в нашем примере:

UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53

Random port означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника. Поскольку номер порта источника в исходящих пакетах формируется хостами локальной сети также случайным образом, преимущества такой замены сомнительны, из недостатков же можно назвать хотя бы потенциальную проблему с протоколом RPC, да и не только.

Hairpin же означает следующее. Допустим, при наличии в таблице NAT приведенной выше строчки другой хост нашей локальной сети (например, 192.168.0.241) отправляет UDP-пакет с адресом назначения 11.22.33.44, портом назначения 1053 и портом источника 53. Что произойдет в результате?

NAT и шлюзы приложений

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

Проблема здесь возникает, когда клиент пытается использовать активный режим FTP. Сессия протекает при этом следующим образом. В некоторый момент по управляющему соединению серверу передается команда FTP-клиента: PORT 192,16,0,101,4,211.

Дальнейший диалог выглядит примерно так:

Наибольший интерес здесь представляет первая команда от клиента, которая информирует сервер о том, что хост с адресом 192.168.0.101 открыл для приема соединения данных порт номер (4*256) + 211 = 1235. В ответ на это сервер должен установить соединение данных со своего порта номер 20 на указанный порт хоста 192.168.0.101. Поскольку этот адрес является приватным, такое соединение не может быть установлено. В результате наблюдается знакомый многим системным администраторам эффект, когда клиент вроде бы успешно подключается к FTP-серверу, но не может скачивать с него файлы или даже просматривать содержимое текущего каталога (это происходит потому, что передача листинга файлов с сервера на клиент также осуществляется по соединению данных).

ля борьбы с описанной проблемой может использоваться переключение сервера в так называемый пассивный режим. Поскольку в этом режиме инициатором соединения данных выступает клиент, проблема исчезает. Именно поэтому в Microsoft Internet Explorer, как и консольный FTP-клиент, встроенный в Windows, используют по умолчанию пассивный режим (они автоматически вставляют перед командами RETR и NLST команду PASV, переключающую сервер в пассивный режим).

Второй случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу, который также находится за NAT. В этом случае, очевидно, не поможет и пассивный режим, так как в команде PORT независимо от того, клиент или сервер ее отдает, всегда будет указан приватный IP-адрес, и соединение данных никогда не будет установлено.

Так, в приведенном выше примере, если предположить, что публичный IP-адрес маршрутизатора с NAT 1.2.3.4 и что он сохраняет номер порта источника неизменным, команда PORT 192,16,0,101,4,211 была бы изменена маршрутизатором на PORT 1,2,3,4,4,211. Благодаря этому в обоих указанных выше случаях соединение данных будет успешно установлено.

Функция ALG в маршрутизаторах Cisco позволяет осуществлять трансляцию адресов уровня приложений не только для протокола FTP, но также и для протоколов SIP, H.323, Skinny и некоторых других (благодаря этому можно, например, размещать в локальной сети серверы DNS). Для большего удобства функция ALG в маршрутизаторах Cisco включена по умолчанию.

Аналогичную ALG функциональность в маршрутизаторах на основе ОС Linux обеспечивают дополнительные загружаемые модули и патчи к ядру (такие, как ip_masq_ftp, ip_masq_irc и т. п.).

Заключение

Понимание принципов работы различных реализаций NAT может оказаться полезным при поиске причины неудовлетворительной работы некоторых приложений, использующих транспортный протокол UDP. Так, например, сочетание ALG и Symmetric или Port Restricted NAT и IP-телефонов, использующих протокол установки соедиенения SIP, может порой давать самые причудливые результаты (спорадические отказы в регистрации на сервере, односторонняя слышимость между абонентами и т. п.), причем это зависит не только от настроек IP-телефона, но и от настроек сервера. Другой пример: компания Microsoft сообщает в своей статье KB817778, что их реализация туннеля IPv6 over UDP не будет работать через Symmetric NAT (адрес статьи в Интернете: http://support.microsoft.com/kb/817778/EN-US). Таких примеров можно найти ещё много, и во всех случаях понимание различий в реализациях NAT если и не поможет немедленно устранить проблему, то хотя бы укажет на возможные пути решения (например, заменить firmware маршрутизатора на такое, где NAT реализован в виде Full Cone, если, конечно, оно существует, или заменить сам маршрутизатор).

Ссылки по теме

	Задать вопрос
программы
обучение
экзамены
компьютеры
	ICQ-консультанты
	Skype-консультанты
Общая справка
Как оформить заказ
Тарифы доставки
Способы оплаты
Прайс-лист
Карта сайта