STUN

Перейти к навигацииПерейти к поиску

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

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

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

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

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

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

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

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

См. также

Реализация

Публичные 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)
  • 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