STUN

редактировать

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

STUN - это инструмент, используемый другими протоколами, такими как Interactive Connectivity Establishment (ICE), Session Initiation Protocol (SIP) и WebRTC. Он предоставляет хостам инструмент для обнаружения наличия преобразователя сетевых адресов и для обнаружения сопоставленного, обычно общедоступного, адреса Интернет-протокола (IP) и номера порта, которые NAT выделил для <10 приложений.>Протокол пользовательских дейтаграмм (UDP) передается на удаленные узлы. Протоколу требуется помощь стороннего сетевого сервера (сервера STUN), расположенного на противоположной (общедоступной) стороне NAT, обычно это общедоступный Интернет.

Первоначально STUN был аббревиатурой от Simple Traversal of Протокол пользовательских дейтаграмм (UDP) через преобразователи сетевых адресов, но это название было изменено в спецификации обновленного набора методов, опубликованных как RFC 5389, с сохранением того же акронима.

Содержание

  • 1 Дизайн
  • 2 Ограничения
  • 3 Оригинальный алгоритм определения характеристик NAT
  • 4 См. Также
  • 5 Ссылки
  • 6 Внешние ссылки

Дизайн

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

Основной протокол работает по существу следующим образом: клиент, обычно работающий в частной сети, отправляет запрос привязки на сервер STUN в общедоступном Интернете. Сервер STUN отвечает успешным ответом, который содержит IP-адрес и номер порта клиента, как это наблюдается с точки зрения сервера. Результат запутывается с помощью сопоставления исключающее или (XOR), чтобы избежать трансляции содержимого пакета шлюзами прикладного уровня (ALG), которые выполняют глубокую проверку пакетов в попытке выполнить альтернативный обход NAT. методы.

Сообщения STUN отправляются в пакетах User Datagram Protocol (UDP). Поскольку UDP не предоставляет надежных транспортных гарантий, надежность достигается за счет управляемой приложением повторной передачи запросов STUN. Серверы STUN не реализуют какой-либо механизм надежности для своих ответов. Когда надежность является обязательной, можно использовать протокол управления передачей (TCP), но это вызывает дополнительные сетевые издержки. В чувствительных к безопасности приложениях STUN может передаваться и зашифровываться с помощью Transport Layer Security (TLS).

Приложение может автоматически определять подходящий STUN-сервер для связи с конкретным одноранговым узлом, запрашивая систему доменных имен (DNS) для блокировки (для UDP) или блокировки (для TCP / TLS).) сервер (SRV ) запись ресурса, например, _stun._udp.example.com. Стандартный номер порта прослушивания для сервера STUN - 3478 для UDP и TCP и 5349 для TLS. В качестве альтернативы TLS также может быть запущен на TCP-порту, если реализация сервера может демультиплексировать пакеты TLS и STUN. В случае, если сервер STUN не найден с помощью поиска DNS, стандарт рекомендует запрашивать у целевого доменного имени адресные записи (A или AAAA), которые будут использоваться с номерами портов по умолчанию.

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

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

Если оба взаимодействующих узла находятся в разных частных сетях, каждый за NAT, одноранговые узлы должны координировать свои действия, чтобы определить лучший путь связи между ними. Некоторое поведение NAT может ограничивать одноранговое соединение, даже если известна общедоступная привязка. Протокол Interactive Connectivity Establishment (ICE) предоставляет структурированный механизм для определения оптимального пути связи между двумя одноранговыми узлами. Расширения протокола инициации сеанса (SIP) определены для включения использования ICE при установке вызова между двумя хостами.

Ограничения

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

STUN не является автономным решением для обхода NAT, применимым во всех сценариях развертывания NAT, и не работает правильно со всеми из них. Это инструмент среди других методов, и это инструмент для других протоколов при работе с обходом NAT, в первую очередь обход с использованием реле NAT (TURN) и установление интерактивного соединения (ICE).

STUN работает с тремя типами NAT: NAT с полным конусом, NAT с ограниченным конусом и NAT с ограничением по портам. В случаях ограниченного конуса или ограниченного порта конусного NAT, клиент должен отправить пакет конечной точке, прежде чем NAT разрешит пакеты от конечной точки до клиента. STUN не работает с симметричным NAT (также известным как двунаправленный NAT), который часто встречается в сетях крупных компаний. Поскольку IP-адрес сервера STUN отличается от адреса конечной точки, в случае симметричного NAT отображение NAT будет другим для сервера STUN, чем для конечной точки. TURN обеспечивает лучшие результаты с симметричным NAT.

Исходный алгоритм определения характеристик NAT

Исходный алгоритм определения характеристик NAT в RFC 3489.

Исходная спецификация STUN в RFC 3489 определяет алгоритм для характеристики поведения NAT в соответствии с поведение при отображении адресов и портов. Этот алгоритм не является надежно успешным и применим только к подмножеству развернутых устройств NAT.

Алгоритм состоит из серии тестов, которые должно выполнить приложение. Когда путь через схему заканчивается красным прямоугольником, связь по протоколу UDP невозможна, а когда путь заканчивается желтым или зеленым прямоугольником, связь возможна.

Методы RFC 3489 оказались слишком ненадежными, чтобы справиться с множеством различных реализаций NAT и сценариев приложений, встречающихся в производственных сетях. Протокол и метод STUN были обновлены в RFC 5389, сохранив многие из исходных спецификаций как подмножество методов, но удалив другие.

См. Также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-06-06 05:09:27
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте