Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Сетевой протокол и связанные с ним функции
Network protocol and related functions
STUN (Session Traversal Utilities for NAT; первоначально Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators) — это стандартизированный набор методов, включающий сетевой протокол, для преодоления сетевых трансляторов адресов (NAT) в приложениях для передачи голоса, видео, обмена сообщениями и других интерактивных коммуникаций в реальном времени. STUN является инструментом, используемым другими протоколами, такими как Interactive Connectivity Establishment (ICE), Session Initiation Protocol (SIP) и WebRTC. Он позволяет хостам обнаруживать наличие сетевого транслятора адресов (NAT), а также определять сопоставленный, как правило публичный, IP-адрес и номер порта, выделенные NAT для UDP-потоков приложения удаленным хостам. Для работы протоколу требуется помощь стороннего сетевого сервера (STUN-сервера), расположенного на противоположной (публичной) стороне NAT, обычно в общедоступном Интернете. STUN был впервые описан в RFC 3489; название было изменено в спецификации обновленного набора методов, опубликованной в RFC 5389, при этом аббревиатура осталась прежней.
STUN (Session Traversal Utilities for NAT; originally Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators) is a standardized set of methods, including a network protocol, for traversal of network address translator (NAT) gateways in applications of real time voice, video, messaging, and other interactive communications. STUN is a tool used by other protocols, such as Interactive Connectivity Establishment (ICE), the Session Initiation Protocol (SIP), and WebRTC. It provides a tool for hosts to discover the presence of a network address translator, and to discover the mapped, usually public, Internet Protocol (IP) address and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) flows to remote hosts. The protocol requires assistance from a third party network server (STUN server) located on the opposing (public) side of the NAT, usually the public Internet. STUN was first announced in RFC 3489; the title was changed in a specification of an updated set of methods published as RFC 5389, retaining the same acronym.
История
STUN был впервые представлен в RFC 3489. Изначальная спецификация определяла алгоритм для классификации поведения NAT на основе принципов отображения адресов и портов. Этот алгоритм оказался недостаточно надежным и применим лишь к части развернутых устройств NAT. Алгоритм состоит из серии тестов, выполняемых приложением. Если путь на диаграмме завершается красным квадратом, UDP-связь невозможна, а если путь завершается желтым или зеленым квадратом – связь возможна. Методы, описанные в RFC 3489, оказались слишком ненадежными для работы с разнообразием реализаций NAT и сценариев использования, встречающихся в реальных сетях. Протокол и метод STUN были обновлены в RFC 5389, сохранив многие из первоначальных спецификаций в качестве подмножества методов, но исключив некоторые из них. В спецификации обновленного набора методов, опубликованной как RFC 5389, название было изменено, при этом аббревиатура осталась прежней.
STUN was first announced in RFC 3489. The original specification specified an algorithm to characterize NAT behavior according to the address and port mapping behavior. This algorithm is not reliably successful and only applicable to a subset of NAT devices deployed. The algorithm consists of a series of tests to be performed by an application. When the path through the diagram ends in a red box, UDP communication is not possible and when the path ends in a yellow or green box, communication is possible. The methods of RFC 3489 proved too unreliable to cope with the plethora of different NAT implementations and application scenarios encountered in production networks. The STUN protocol and method were updated in RFC 5389, retaining many of the original specifications as a subset of methods, but removing others. The title was changed in a specification of an updated set of methods published as RFC 5389, retaining the same acronym.
Дизайн
STUN — это инструмент для протоколов связи, предназначенный для обнаружения и преодоления сетевых трансляторов адресов (NAT), расположенных на пути между двумя конечными точками связи. Он реализован как легковесный протокол клиент-сервер, требующий только простых компонентов запроса и ответа с сервером третьей стороны, находящимся в общей, легкодоступной сети, как правило, в Интернете. Клиентская часть реализуется в приложении связи пользователя, например, в телефоне Voice over Internet Protocol (VoIP) или клиенте мгновенных сообщений. Базовый протокол работает следующим образом: клиент, обычно работающий в частной сети, отправляет запрос на привязку (binding request) на сервер STUN в общедоступном Интернете. Сервер STUN отвечает подтверждением, содержащим IP-адрес и номер порта клиента, как они видны со стороны сервера. Результат обфусцируется с помощью операции исключающего ИЛИ (XOR), чтобы избежать преобразования содержимого пакета шлюзами прикладного уровня (ALG), выполняющими глубокую инспекцию пакетов (deep packet inspection) в попытке использовать альтернативные методы обхода NAT. Сообщения STUN отправляются в пакетах протокола User Datagram Protocol (UDP). Поскольку UDP не обеспечивает надежную доставку, надежность достигается за счет повторных передач запросов STUN, управляемых приложением. Серверы STUN не реализуют механизмы обеспечения надежности для своих ответов. Если надежность обязательна, может использоваться протокол Transmission Control Protocol (TCP), но это приводит к дополнительным сетевым накладным расходам. В приложениях, критичных к безопасности, STUN может передаваться и шифроваться с помощью Transport Layer Security (TLS). Приложение может автоматически определить подходящий сервер STUN для связи с конкретным участником, запросив в системе доменных имен (DNS) запись ресурса сервера (SRV) stun (для UDP) или stuns (для TCP/TLS), например, stun.udp.example.com. Стандартный порт прослушивания для сервера STUN — 3478 для UDP и TCP, и 5349 для TLS. В качестве альтернативы, TLS также может работать на порту TCP, если реализация сервера способна разделять пакеты TLS и STUN. Если при поиске в DNS сервер STUN не найден, стандарт рекомендует запросить адресные записи (A или AAAA) для доменного имени назначения, которые будут использоваться с портами по умолчанию. Помимо использования шифрования протокола с помощью TLS, STUN также имеет встроенные механизмы аутентификации и обеспечения целостности сообщений посредством специализированных типов пакетов STUN. После определения своего внешнего адреса клиент может использовать его в качестве кандидата для связи с другими участниками, передавая внешний адрес NAT, а не частный адрес, который недоступен для участников в общедоступной сети. Если оба взаимодействующих участника находятся в разных частных сетях, каждый из которых находится за NAT, им необходимо координировать свои действия для определения наилучшего пути связи между ними. Некоторые особенности работы NAT могут ограничивать связь между участниками, даже если общедоступная привязка известна. Протокол Interactive Connectivity Establishment (ICE) предоставляет структурированный механизм для определения оптимального пути связи между двумя участниками. Расширения протокола Session Initiation Protocol (SIP) определены для обеспечения использования ICE при установке вызова между двумя хостами.
STUN is a tool for communications protocols to detect and traverse network address translators that are located in the path between two endpoints of communication. It is implemented as a light weight client–server protocol, requiring only simple query and response components with a third party server located on the common, easily accessible network, typically the Internet. The client side is implemented in the user's communications application, such as a Voice over Internet Protocol (VoIP) phone or an instant messaging client. The basic protocol operates essentially as follows: The client, typically operating inside a private network, sends a binding request to a STUN server on the public Internet. The STUN server responds with a success response that contains the IP address and port number of the client, as observed from the server's perspective. The result is obfuscated through exclusive or (XOR) mapping to avoid translation of the packet content by application layer gateways (ALGs) that perform deep packet inspection in an attempt to perform alternate NAT traversal methods. STUN messages are sent in User Datagram Protocol (UDP) packets. Since UDP does not provide reliable transport, reliability is achieved by application controlled retransmissions of the STUN requests. STUN servers do not implement any reliability mechanism for their responses. When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security sensitive applications, STUN may be transported and encrypted by Transport Layer Security (TLS). An application may automatically determine a suitable STUN server for communications with a particular peer by querying the Domain Name System (DNS) for the stun (for UDP) or stuns (for TCP/TLS) server (SRV) resource record, e. g., stun. udp. example. com. The standard listening port number for a STUN server is 3478 for UDP and TCP, and 5349 for TLS. Alternatively, TLS may also be run on the TCP port if the server implementation can de multiplex TLS and STUN packets. In case no STUN server is found using DNS lookups, the standard recommends that the destination domain name should be queried for address records (A or AAAA), which would be used with the default port numbers. In addition to using protocol encryption with TLS, STUN also has built in authentication and message integrity mechanisms via specialized STUN packet types. When a client has evaluated its external address, it can use this as a candidate for communicating with peers by sharing the external NAT address rather than the private address, which is not reachable from peers on the public network. If both communicating peers are located in different private networks, each behind a NAT, the peers must coordinate to determine the best communication path between them. Some NAT behavior may restrict peer connectivity even when the public binding is known. The Interactive Connectivity Establishment (ICE) protocol provides a structured mechanism to determine the optimal communication path between two peers. Session Initiation Protocol (SIP) extensions are defined to enable the use of ICE when setting up a call between two hosts.
Ограничения
Перевод сетевых адресов осуществляется с помощью различных схем сопоставления адресов и портов, ни одна из которых не стандартизована. STUN не является самостоятельным решением для преодоления NAT, применимым во всех сценариях развертывания NAT, и не работает корректно со всеми типами NAT. Это один из инструментов, используемых другими протоколами для преодоления NAT, в частности, Traversal Using Relay NAT (TURN) и Interactive Connectivity Establishment (ICE). STUN работает с тремя типами NAT: NAT с полным конусом, NAT с ограниченным конусом и NAT с ограниченным портом конуса. В случаях NAT с ограниченным или ограниченным портом конуса, клиент должен отправить пакет на конечную точку, прежде чем NAT разрешит прохождение пакетов от конечной точки к клиенту. STUN не работает с симметричным NAT (также известным как двунаправленным NAT), который часто встречается в сетях крупных организаций. Поскольку IP-адрес сервера STUN отличается от адреса конечной точки, в случае симметричного NAT отображение NAT для сервера STUN будет отличаться от отображения для конечной точки. TURN обеспечивает лучшие результаты при работе с симметричным NAT.
Network address translation is implemented via a number of different address and port mapping schemes, none of which is standardized. STUN is not a self contained NAT traversal solution applicable in all NAT deployment scenarios and does not work correctly with all of them. It is a tool among other methods and it is a tool for other protocols in dealing with NAT traversal, most notably Traversal Using Relay NAT (TURN) and Interactive Connectivity Establishment (ICE). STUN works with three types of NAT: full cone NAT, restricted cone NAT, and port restricted cone NAT. In the cases of restricted cone or port restricted cone NATs, the client must send out a packet to the endpoint before the NAT will allow packets from the endpoint through to the client. STUN does not work with symmetric NAT (also known as bi directional NAT) which is often found in the networks of large companies. Since the IP address of the STUN server is different from that of the endpoint, in the symmetric NAT case, the NAT mapping will be different for the STUN server than for an endpoint. TURN offers better results with symmetric NAT.