Что такое 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 установил соответствие локальный хост : порт внешний порт), поэтому входящие извне пакеты попадут в локалку и слышимость будет обоюдная.

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

Stun сервер для windows

Version 1.2. This is the source code to STUNTMAN — an open source STUN server and client code by john selbie. Compliant with the latest RFCs including 5389, 5769, and 5780. Also includes backwards compatibility for RFC 3489. Compiles on Linux, MacOS, BSD, Solaris, and Win32 with Cygwin. Windows binaries avaialble from www.stunprotocol.org.

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio

Latest commit

Git stats

Files

Failed to load latest commit information.

README

About

Version 1.2. This is the source code to STUNTMAN — an open source STUN server and client code by john selbie. Compliant with the latest RFCs including 5389, 5769, and 5780. Also includes backwards compatibility for RFC 3489. Compiles on Linux, MacOS, BSD, Solaris, and Win32 with Cygwin. Windows binaries avaialble from www.stunprotocol.org.

Resources

License

Releases

Packages 0

Contributors 6

Languages

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

WireGuard, настройка нескольких клиентов за NAT и причем здесь STUN?

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

Сначала, о преимуществах WireGuard и обратной стороне медали, о сложностях, которые возникают вместе с преимуществами. WireGuard достаточно молодая реализация туннеля между двумя точками, как протокол передачи используется UDP. Именно поэтому и еще потому, что сама реализация в Linux выполнена в виде модуля ядра, тесты показывают порядочное преимущество в скорости, по отношению к конкурентам. Пиринговой сетью это считать нельзя, хотя конечные узлы и называются Peer. Суть пиринговой сети не только в том, что бы можно было соединить два произвольных узла. Конечно же на данном инструментарии, можно построить весьма замысловатую сетевую инфраструктуру, но у меня такой цели не стоит. Мы рассмотрим подключение к серверному узлу и выход посредством него в интернет.

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

Клиенты STUN, существуют на всех популярных операционных системах, кроме iOS. Под эту операционную систему, STUN клиент мне найти не удалось. Пример я приведу для macOS. Для начала, необходимо установить сам STUN клиент.

В интернете существует масса STUN серверов и не сложно в поиске найти любой сервер для теста. Я буду использовать stun.ekiga.net. Для теста необходимо будет использовать локальный порт, тот который мы будем использовать для настройки:

При удачном тесте мы получим, примерно такой вывод:

Mapped address это именно тот IP, который необходимо будет использовать при настройке сервера. На самом деле, это тот IP адрес, который в моем случае выдаст любой сервис по определению внешнего IP. Поэтому можно воспользоваться вашим любимым сервисом по определению IP, но конечно, стоит учитывать, что этот тест будет косвенным и гарантии никакой нет, что все будет работать так как задумывалось.

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

На Linux, это можно сделать из командной строки, на macOS — через UI официального клиента.

В данном случае по месту вызова приватный ключ будет создан в файле privatekey, публичный в в publickey соответственно.

Первым рассмотрим клиентский конфиг:

Теперь пришло время серверного конфига:

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

Для настройки я пользовался следующими ресурсами: официальным сайтом, ArchWiki и вот этим туториалом.

В конце, я хотел бы также прояснить пару возможных вопросов:

1. Можно ли на сервере сделать несколько секций одинаковых Peer, которые будут отличаться только EndPoint?

Да можно, и это даже может быть полезно в том случае, когда вы пользуетесь сервисом из разных мест, к примеру, на работе и дома. Но проблемы могут возникнуть если такие Peer, выйдут в онлайн одновременно, в этом случае будет конфликт IP адресов.

2. Какой внешний IP и порт будет определяться по STUN протоколу для нескольких клиентов за NAT?

Один и тот же для всех клиентов, он будет одинаковый. Будет ли это проблемой? Это все зависит от настроек вашего провайдера/роутера, но принципиально проблемы возникать не должны, так как роутер должен широковещательно ретранслировать UDP пакеты внутри сети по маске локальной сети, соответственно те принимающие стороны, которые смогут расшифровать пакеты, должны их успешно принимать. Мы проводили тесты, на нашем оборудовании, тесты прошли успешно.

Целью статьи не было написать полный туториал как настроить WireGuard, это не сложно сделать воспользовавшись официальной документацией. Мы хотели показать, как WireGuard может работать за NAT.

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

UPD:
Как справедливо заметил хабражитель aborouhin, достаточно только одно белого IP для того что бы канал передачи данных работал без проблем. Соотвественно EndPoint для Peer в серверном конфиге можно не указывать и это облегчает настройку. А описаный мануал, может быть полезен, если оба узла находятся за NAT.

Обзор протоколов STUN, TURN и ICE, их принципы работы с NAT и использование для VoIP

Введение При работе с IP-телефонией постоянно приходится сталкиваться с разного рода задачами связанными с сетью, т.к. эти области неразрывно связаны. В данной обзорной статье рассматриваются протоколы STUN и ICE, их методы работы с NAT и практическое применение в работе с VoIP. Протокол STUN Название протокола – аббревиатура, можно расшифровать как Simple Traversal of UDP tрrough […]

Введение

При работе с IP-телефонией постоянно приходится сталкиваться с разного рода задачами связанными с сетью, т.к. эти области неразрывно связаны. В данной обзорной статье рассматриваются протоколы STUN и ICE, их методы работы с NAT и практическое применение в работе с VoIP.

Протокол STUN

Название протокола – аббревиатура, можно расшифровать как Simple Traversal of UDP tрrough NAT или же по-русски «Простое прохождение UDP через NAT». Почему он нам интересен? Причина проста: как правило, многие устройства, работающие по SIP’у, будь то голосовые шлюзы, ip-телефоны, софтфоны или же сами сервера с телефонии, по большей степени скрыты за NAT’ом. Это обусловлено по большей степени принципами безопасности и грамотной логикой построения сетей. Но периодически из-за этого возникают различные неприятные ситуации с прохождением, например, голосового потока. Для решения подобных проблем и был разработан этот STUN. Его основное назначение – дать возможность различным девайсам (за NAT’ом) узнать их public IP-адрес и найти пробросы портов. Как правило, STUN использует 3478 порт, которому обращается клиент (протокол является клиент-серверным).

Как это работает:

Устройством отправляется запрос к public IP STUN-сервера через маршрутизатор (шлюз), он, в свою очередь, перенаправляет его на STUN-сервер с внешним IP на порт 3478, ну а сервер отвечает устройству через маршрутизатор, сообщая, что запрос был сделан с внешнего IP маршрутизатора с определенного порта. Схема для наглядности:

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

Протокол TURN

Теперь немного о протоколе TURN. Расшифровка названия — Traversal Using Relays around NAT. Предназначается для работы с симметричным NAT’ом. Использует сервер для передачи данных от клиента (как и STUN является клиент-серверным протоколом) любому количеству устройств (пиров).

Принцип работы – грубо говоря, разбиение симметричного NAT на два не симметричных. А теперь немного подробнее:

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

Изобразим этот процесс схематично для большей наглядности:

Протокол ICE

Interactive Connection Establishment (интерактивное установление соединение) — это еще одно дополнение (суб-протокол) к протоколам STUN и TURN. Основное назначение:

1. Собрать данные об интерфейсах
2. Проверить удаленные сервера STUN
3. Проверить удаленные сервера TURN
4. Проверить возможность установления соединения

Принцип работы довольно прост и тривиален: протокол последовательно собирает данные о возможности создания локального соединения между устройствами (пирами) по TCP или UDP. Если такой возможности нет, он проверяет возможность использования STUN во внешней сети, если и такой возможности не обнаруживается, ICE проверяет возможность использовать TURN во внешней сети (в том числе и проверяет доступность подключения к нескольким ближайшим TURN-серверам). После окончания сбора информации о структуре окружающей клиента сети, им (клиентом, создающим сессию) отправляется сообщение на TURN-сервер, содержащее полученную архитектуру ближайшей сети, а так же кидает запрос на создание сессии для пира, хранящий пачку IP-адресов, которые знает клиент. Пир соответственно отвечает множественными STUN-сообщениями по каждому из IP. Рано или поздно, хотя бы одно из сообщений прилетит инициатору сессии, проскочив сквозь NAT. Как только клиент ответит на все такие сообщения, у пира появится карта сети по которой будет выбираться самый легкий для прохождения маршрут (этот процесс называется процедура номинирования пар) и выполняться проверка доступности между пиром и клиентом (могут ли они достучаться друг до друга). Приоритезация такая: без STUN – самый высокий приоритет, с использованием STUN – пониже, с TURN’ом – самый низкий. Ну и в конечном итоге, устанавливается соединение.

Стоит отметить, что протокол ICE не очень подходит для ряда решений:

1. Если у нас большой прак оборудования
2. Если мы ведем запись на проксирующем сервере
3. Если у нас сложная структура сети с пересекающимися подсетями
4. Если очень критично время установки соединения

Вывод

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

zziuni / stuns

# source : http://code.google.com/p/natvpn/source/browse/trunk/stun_server_list

# A list of available STUN server.

stun.l.google.com:19302

stun1.l.google.com:19302

stun2.l.google.com:19302

stun3.l.google.com:19302

stun4.l.google.com:19302

stun01.sipphone.com

stun.ekiga.net

stun.fwdnet.net

stun.ideasip.com

stun.iptel.org

stun.rixtelecom.se

stun.schlund.de

stunserver.org

stun.softjoys.com

stun.voiparound.com

stun.voipbuster.com

stun.voipstunt.com

stun.voxgratia.org

stun.xten.com

This comment has been minimized.

Copy link Quote reply

DamonOehlman commented Jan 27, 2014

Thanks heaps for this 🙂

I actually ended up using this list as the source list for a node module (browserify friendly):

From my testing though (I make sure each of the servers is currently responding within 5s) as part of the module unit tests, I ended up removing the following as they either were no longer found in DNS or were just too slow to respond:

This comment has been minimized.

Copy link Quote reply

torus0519 commented Mar 1, 2014

Just want to add STUN Servers Located in Japan.
I had tested myself as well.

Actually, I am thinking about hosting STUN on one of my servers.
I don’t believe it requires a high-end server for it, «stability» is a challenge that I know 😉

This comment has been minimized.

Copy link Quote reply

kehers commented Jun 5, 2014

This comment has been minimized.

Copy link Quote reply

allenforrest commented Jul 16, 2014

This comment has been minimized.

Copy link Quote reply

cmbaughman commented Jan 27, 2015

There is also stun.services.mozilla.com

This comment has been minimized.

Copy link Quote reply

pavel-shvetsov commented Feb 20, 2015

Hello!
I’ll just leave it here.

List of 267 public STUN servers from EmerCoin project:

• http://emc.cc.st/public-stun.txt. Tested 2014-08-23.

This comment has been minimized.

Copy link Quote reply

maxihatop commented Jun 25, 2015

This comment has been minimized.

Copy link Quote reply

gcamp806 commented Jun 25, 2015

Also, stun.sipgate.net is currently working

This comment has been minimized.

Copy link Quote reply

nikhilkilivayil commented Oct 4, 2015

Can I use this STUN servers free of cost?

This comment has been minimized.

Copy link Quote reply

AnuMartin1 commented Oct 9, 2015

ആശനെ ചൂമ്മാ കിട്ടും ആയിരിക്കും ഇല്ലേ .

This comment has been minimized.

Copy link Quote reply

zhijianli88 commented Nov 9, 2015

hi, is there any stun server in China

This comment has been minimized.

Copy link Quote reply

valeriansaliou commented Nov 13, 2015

Public STUN server we do provide since 2 yrs: stun.jappix.com:3478 (UDP + TCP)

This comment has been minimized.

Copy link Quote reply

aofall commented Nov 21, 2015

stun*.l.google.com use other port now

stun.l.google.com:19305
stun1.l.google.com:19305
stun2.l.google.com:19305
stun3.l.google.com:19305
stun4.l.google.com:19305

This comment has been minimized.

Copy link Quote reply

dineshvg commented Dec 2, 2015

Is there any stun server from Germany/Austria ?

This comment has been minimized.

Copy link Quote reply

alejandroacostaalamo commented Dec 8, 2015

Interesting that the only one with IPv6 support is numb.viagenie.ca. not even google’s servers

This comment has been minimized.

Copy link Quote reply

staticglobal commented Dec 29, 2015

With IPv6, NAT has been all but eradicated. eliminating the need for all these NAT-workaround technologies 🙂

This comment has been minimized.

Copy link Quote reply

nixn commented Mar 19, 2016

This comment has been minimized.

Copy link Quote reply

BCS2005 commented Apr 7, 2016

This comment has been minimized.

Copy link Quote reply

mahmoudSarhan commented Jun 14, 2016 •

is there any server that support tcp ?

This comment has been minimized.

Copy link Quote reply

grockland commented Jul 18, 2016

Any recommendations for a reliable, commercial service?

This comment has been minimized.

Copy link Quote reply

deadjdona commented Aug 4, 2016

QuckBlox try it.

This comment has been minimized.

Copy link Quote reply

jeevan449 commented Aug 5, 2016

This comment has been minimized.

Copy link Quote reply

Thoughtscript commented Aug 9, 2016

Hey hey! Have a node STUN implementation at Varstate.com — still needs some testing but please feel free to use. URL information is available there. If you have any problems please feel free to reach out to me at the listed contact points! Cheers!

This comment has been minimized.

Copy link Quote reply

Thoughtscript commented Aug 10, 2016

This comment has been minimized.

Copy link Quote reply

Globik commented Aug 16, 2016

@Thoughscript is there is a stun server written in vanilla javascript?

This comment has been minimized.

Copy link Quote reply

ruoho commented Dec 21, 2016

This comment has been minimized.

Copy link Quote reply

cozzbie commented Dec 21, 2016

This is stunning!

This comment has been minimized.

Copy link Quote reply

toLucky81 commented Jan 4, 2017

Until it took a TURN

This comment has been minimized.

Copy link Quote reply

Thoughtscript commented Jan 5, 2017

@Globik sorry for the delay!! Yep the stun server is pure vanilla ES6 javascript in Node

This comment has been minimized.

Copy link Quote reply

18dew commented Feb 13, 2017

Any STUN servers in India

This comment has been minimized.

Copy link Quote reply

alefink commented Feb 17, 2017

Someone could report stun ip: stun.l.google.com: 19302

This comment has been minimized.

Copy link Quote reply

khatribharat commented Mar 17, 2017

@aofall stun*.l.google.com still use 19302

This comment has been minimized.

Copy link Quote reply

khatribharat commented Aug 10, 2017

This comment has been minimized.

Copy link Quote reply

saphsoph88 commented Aug 29, 2017

Does any one have any idea what to do if google stun is not available ?! Can we refer to any support or something !

This comment has been minimized.

Copy link Quote reply

buckle2000 commented Oct 2, 2017

This comment has been minimized.

Copy link Quote reply

mondain commented Oct 4, 2017

Any public STUN servers in the middle east? Oman, UAE??

This comment has been minimized.

Copy link Quote reply

choxx commented Mar 28, 2018

<
«urls»: [
«turn:13.250.13.83:3478?transport=udp»
],
«username»: «YzYNCouZM1mhqhmseWk6»,
«credential»: «YzYNCouZM1mhqhmseWk6»
>
For Asia region

This comment has been minimized.

Copy link Quote reply

faztp12 commented Jan 6, 2020

This comment has been minimized.

Copy link Quote reply

mattjereb commented Mar 27, 2020

Any public STUN servers in Australia? All of them are over 100-200ms away!

This comment has been minimized.

Copy link Quote reply

ahmnouira commented Apr 18, 2020

Any public STUN server in North of Africa.

This comment has been minimized.

Copy link Quote reply

dcloutie commented Apr 19, 2020

Any public STUN server in Canada.

This comment has been minimized.

Copy link Quote reply

Quix0r commented Jun 3, 2020

I wonder how I can test my own server. f.haeder.net has UDP and TCP port (ejabberd provides it) and configured in DNS for the domain.

This comment has been minimized.

Copy link Quote reply

magicdrums commented Jul 20, 2020

Any Public STUN Server in South America?

This comment has been minimized.

Copy link Quote reply

danfoxley commented Aug 26, 2020

How does stun.l.google.com cough up IPs? I see only one IP at a time when doing a DNS A record lookup. How do we know the full list of IP addresses behind this DNS A record? This IP is not returning a Binding Request: 74.125.192.127

This comment has been minimized.

Copy link Quote reply

christophermina commented Aug 30, 2020

Google seems to be broadcasting this IP for stun (74.125.192.127) but it’s no good and does not properly handle STUN requests. It seems to be ISP dependent, meaning certain ISPs are caching that DNS resolution, but I’ve seen the number of Customers across multiple ISPs who are having STUN issues growing this week, and all affected users are resolving stun.l.google.com to the 74.xxx address.

We have implemented a fallback to Freeswitch Stun in case response from Google STUN is not returned. Standard WebRTC protocol in browsers expect on or more STUN server paths and will resolve DNS for both, and will initiate the STUN request to both in parallel for any applicable candidates. This has resolved the issue for us, but would be great if Google can stop broadcasting that IP.

This comment has been minimized.

Copy link Quote reply

sburlappp commented Sep 1, 2020

Google apparently provides a pool, but you’ll need to reference each individually:

stun.l.google.com has address 74.125.192.127
stun1.l.google.com has address 172.217.192.127
stun2.l.google.com has address 142.250.15.127
stun3.l.google.com has address 108.177.15.127
stun4.l.google.com has address 108.177.119.127

Note: I can successfully ping them all right now.

This comment has been minimized.

Copy link Quote reply

ShuyingMaggieMi commented Sep 3, 2020 •

Hi bud, how you test these server address? Just paste them in the web browser address?@sburlappp

This comment has been minimized.

Copy link Quote reply

sburlappp commented Sep 3, 2020

You can test a STUN server using the tools on this webpage:

This comment has been minimized.

Copy link Quote reply

jessaleks commented Nov 1, 2020

Ok so I don’t understand — what are the benefits of using a STUN server vs connecting P2P?

This comment has been minimized.

Copy link Quote reply

magicdrums commented Nov 1, 2020

Ok so I don’t understand — what are the benefits of using a STUN server vs connecting P2P?

in P2P no necessary use STUN Server, but behind Firewall this connection is stable with this type server, for me STUN Server works is great solution for virtualization behind Firewall Perimetral

This comment has been minimized.

Copy link Quote reply

ChrisZhangJin commented Nov 16, 2020

is this list still available yet??

This comment has been minimized.

Copy link Quote reply

codebuilderspk commented Dec 21, 2020

is this list still available yet??

This comment has been minimized.

Copy link Quote reply

caveman444 commented Jan 17, 2021

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.