STUN ( утилиты прохождения сеанса для NAT ; первоначально простой обход протокола пользовательских датаграмм (UDP) через трансляторы сетевых адресов ) — стандартизированный набор методов, включающий сетевой протокол, для обхода шлюзов трансляторов сетевых адресов (NAT) в приложениях для передачи голоса, видео, сообщений и других интерактивных коммуникаций в реальном времени.
STUN — это инструмент, используемый другими протоколами, такими как Interactive Connectivity Establishment (ICE), Session Initiation Protocol (SIP) и WebRTC . Он предоставляет хостам инструмент для обнаружения наличия транслятора сетевых адресов и обнаружения сопоставленного, обычно публичного, адреса протокола Интернета (IP) и номера порта, которые NAT выделил для потоков User Datagram Protocol (UDP) приложения на удаленные хосты. Протокол требует помощи от стороннего сетевого сервера (сервера STUN), расположенного на противоположной (публичной) стороне NAT, обычно публичной сети Интернет .
STUN был впервые анонсирован в RFC 3489; [1] название было изменено в спецификации обновленного набора методов, опубликованной как RFC 5389, с сохранением той же аббревиатуры. [2]
STUN был впервые анонсирован в RFC 3489. [1] Первоначальная спецификация определяла алгоритм для характеристики поведения NAT в соответствии с поведением сопоставления адресов и портов. Этот алгоритм не является надежно успешным и применим только к подмножеству развернутых устройств NAT. Алгоритм состоит из серии тестов, которые должно выполнить приложение. Когда путь через диаграмму заканчивается в красном поле, связь UDP невозможна, а когда путь заканчивается в желтом или зеленом поле, связь возможна. Методы RFC 3489 оказались слишком ненадежными, чтобы справиться с множеством различных реализаций NAT и сценариев приложений, встречающихся в производственных сетях. Протокол и метод STUN были обновлены в RFC 5389, сохранив многие из исходных спецификаций как подмножество методов, но удалив другие.
Название было изменено в спецификации обновленного набора методов, опубликованной как RFC 5389, с сохранением той же аббревиатуры. [2]
STUN — это инструмент для протоколов связи, позволяющий обнаруживать и обходить трансляторы сетевых адресов, расположенные на пути между двумя конечными точками связи. Он реализован как легкий клиент-серверный протокол, требующий только простых компонентов запроса и ответа со сторонним сервером, расположенным в общей, легкодоступной сети, обычно в Интернете . Клиентская сторона реализована в коммуникационном приложении пользователя, таком как телефон с протоколом Voice over Internet Protocol (VoIP) или клиент обмена мгновенными сообщениями.
Базовый протокол работает по сути следующим образом: клиент, обычно работающий внутри частной сети , отправляет запрос на привязку на сервер STUN в общедоступном Интернете. Сервер STUN отвечает ответом об успешном выполнении , который содержит IP-адрес и номер порта клиента, как это видно с точки зрения сервера. Результат запутывается посредством исключительного или (XOR) сопоставления, чтобы избежать трансляции содержимого пакета шлюзами прикладного уровня (ALG), которые выполняют глубокую проверку пакетов в попытке выполнить альтернативные методы обхода NAT.
Сообщения STUN отправляются в пакетах User Datagram Protocol (UDP). Поскольку UDP не обеспечивает надежной транспортировки, надежность достигается путем контролируемых приложением повторных передач запросов STUN. Серверы STUN не реализуют никаких механизмов надежности для своих ответов. [2] Когда надежность обязательна, может использоваться протокол управления передачей (TCP), но это приводит к дополнительным сетевым издержкам. В приложениях, чувствительных к безопасности, STUN может транспортироваться и шифроваться с помощью Transport Layer Security (TLS).
Приложение может автоматически определить подходящий сервер STUN для связи с определенным одноранговым узлом, запросив у системы доменных имен (DNS) запись ресурса сервера stun (для UDP) или stuns (для TCP/TLS) ( SRV ), например, _stun._udp.example.com. Стандартный номер порта прослушивания для сервера STUN — 3478 для UDP и TCP и 5349 для TLS. В качестве альтернативы TLS также может быть запущен на порту TCP, если реализация сервера может демультиплексировать пакеты TLS и STUN. В случае, если сервер STUN не найден с помощью поиска DNS, стандарт рекомендует, чтобы имя домена назначения было запрошено для адресных записей (A или AAAA), которые будут использоваться с номерами портов по умолчанию. [2]
Помимо использования шифрования протокола TLS, STUN также имеет встроенные механизмы аутентификации и обеспечения целостности сообщений с помощью специализированных типов пакетов STUN.
Когда клиент оценил свой внешний адрес, он может использовать его в качестве кандидата для связи с одноранговыми узлами, поделившись внешним адресом NAT, а не частным адресом, который недоступен для одноранговых узлов в публичной сети.
Если оба взаимодействующих одноранговых узла находятся в разных частных сетях, каждый за NAT, одноранговые узлы должны координировать свои действия, чтобы определить наилучший путь связи между ними. Некоторое поведение NAT может ограничивать одноранговое подключение, даже если известна публичная привязка. Протокол Interactive Connectivity Establishment (ICE) предоставляет структурированный механизм для определения оптимального пути связи между двумя одноранговыми узлами. Определены расширения протокола SIP, позволяющие использовать ICE при установлении вызова между двумя хостами.
Трансляция сетевых адресов реализуется с помощью ряда различных схем сопоставления адресов и портов, ни одна из которых не стандартизирована.
STUN не является самодостаточным решением для обхода NAT, применимым во всех сценариях развертывания NAT , и не работает правильно со всеми из них. Это инструмент среди других методов, и это инструмент для других протоколов в работе с обходом NAT, в частности, Traversal Using Relay NAT (TURN) и Interactive Connectivity Establishment (ICE).
STUN работает с тремя типами NAT: NAT с полным конусом , NAT с ограниченным конусом и NAT с ограниченным портом . В случаях NAT с ограниченным конусом или NAT с ограниченным портом клиент должен отправить пакет в конечную точку, прежде чем NAT разрешит пакеты от конечной точки к клиенту. STUN не работает с симметричным NAT (также известным как двунаправленный NAT), который часто встречается в сетях крупных компаний. Поскольку IP-адрес сервера STUN отличается от IP-адреса конечной точки, в случае симметричного NAT сопоставление NAT будет отличаться для сервера STUN, чем для конечной точки. TURN обеспечивает лучшие результаты с симметричным NAT.