Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Желілік протокол және байланысты функциялар
Network protocol and related functions
STUN (Session Traversal Utilities for NAT; бастапқыда Желілік адрес аударғыштар арқылы пайдаланушы деректер протоколының (UDP) қарапайым өтуі) – нақты уақыт дауыстық, бейне, хабарлама және басқа да интерактивті байланыс қолданбаларында желілік адрес аударғыш (NAT) шлюздерін өтү үшін стандартталған әдістер жиынтығы, соның ішінде желілік протокол. STUN – бұл басқа протоколдар, мысалы, Интерактивті байланыс орнату (ICE), Сессияны бастау протоколы (SIP) және WebRTC қолданатын құрал. Ол хосттарға желілік адрес аударғышының бар-жоғын анықтауға және NAT-тың қашықтағы хосттарға арналған қолданбаның пайдаланушы деректер протоколы (UDP) ағыны үшін бөлген, әдетте ашық, Интернет протоколы (IP) адресі мен порт нөмірін табуға мүмкіндік береді. Протоколға NAT-тың қарама-қарсы (ашық) жағында орналасқан үшінші тарап желілік серверінің (STUN серверінің) көмегі қажет, әдетте ол – жалпыға ортақ Интернет. 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) анықтау және олар арқылы өту үшін байланыс протоколдарының құралы. Ол жеңіл клиент-сервер протоколы ретінде іске асырылады, оған тек қарапайым сұраныс және жауап компоненттері қажет, ал үшінші тарап сервері ортақ, оңай қолжетімді желіде, әдетте Интернетте орналасады. Клиенттік бөлік пайдаланушының байланыс бағдарламасында, мысалы, Интернет-протокол арқылы дауыс беру (VoIP) телефоны немесе жылдам хабар алмасу клиенті ретінде іске асырылады. Негізгі протокол мынадайша жұмыс істейді: Клиент, әдетте жеке желіде жұмыс істейді, қоғамдық Интернеттегі STUN серверіне байланыс сұрау жібереді. STUN сервері клиенттің IP-адресі мен порт нөмірін қамтитын сәтті жауаппен жауап береді, бұл сервердің көзқарасынан байқалады. Нәтиже эксклюзивті немесе (XOR) операциясы арқылы жасырылады, бұл қосымша қабат шлюздерінің (ALG) пакет мазмұнын аударуын болдырмау үшін жасалады, олар NAT-тің баламалы әдістерімен өтуге тырысып, пакеттерді тереңінен тексеруді жүргізеді. STUN хабарламалары пайдаланушылық деректерді жіберу протоколының (UDP) пакеттерінде жіберіледі. UDP сенімді тасымалдауды қамтамасыз етпегендіктен, сенімділік STUN сұраныстарын қосымша бақыланатын қайта жіберу арқылы қамтамасыз етіледі. STUN серверлері жауап беруде сенімділік механизмін қолдамайды. Егер сенімділік міндетті болса, беруді басқару протоколы (TCP) пайдаланылуы мүмкін, бірақ бұл қосымша желілік жүктемеге әкеледі. Қауіпсіздікке сезімтал қолданбаларда STUN тасымалдау қабатының қауіпсіздігі (TLS) арқылы тасымалдануы және шифрлануы мүмкін. Қолданба белгілі бір әріптеспен байланыс үшін қолайлы STUN серверін автоматты түрде анықтау үшін домендік атаулар жүйесіне (DNS) UDP үшін (stun) немесе TCP/TLS үшін (stuns) сервердің (SRV) ресурстық жазбасын сұрау арқылы анықтай алады, мысалы, stun.udp.example.com. STUN серверінің стандартты тыңдау порты UDP және TCP үшін 3478, ал TLS үшін 5349 болып табылады. Егер сервердің іске асырылуы TLS және STUN пакеттерін мультиплекстеуге қабілетті болса, TLS TCP портында да жұмыс істей алады. Егер DNS сұрауы арқылы STUN сервері табылмаса, стандарт адрестік жазбалар (A немесе AAAA) үшін мақсатты домендік атауды сұрауды ұсынады, олар әдепкі порт нөмірлерімен пайдаланылады. TLS протоколымен шифрлаудан басқа, STUN арнайы STUN пакеттері арқылы аутентификация және хабарламаның тұтастығын тексеру механизмдерін де қамтиды. Клиент өзінің сыртқы адресін бағалағаннан кейін, оны жеке адрестің орнына сыртқы NAT адресін бөлісу арқылы әріптестермен байланыс үшін кандидат ретінде пайдалана алады, себебі жеке адрес қоғамдық желідегі әріптестер үшін қолжетімді емес. Егер екі байланыс жасайтын тарап әртүрлі жеке желілерде орналасқан болса, әрқайсысы NAT артында, олар арасындағы ең жақсы байланыс жолын анықтау үшін үйлестіруі керек. Кейбір NAT мінез-құлқы қоғамдық байланыс орнатылған кезде де тараптардың байланысын шектеуі мүмкін. Аралық байланыс орнату (ICE) протоколы екі тарап арасындағы ең жақсы байланыс жолын анықтау үшін құрылымдық механизмді ұсынады. Сессияны бастау протоколының (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 (TURN) және интерактивті байланыс орнату (ICE). STUN NAT-тің үш түрімен жұмыс істейді: толық конус NAT, шектелген конус NAT және порт бойынша шектелген конус NAT. Шектелген конус немесе порт бойынша шектелген конус NAT болған жағдайда, клиент соңғы нүктеге пакет жібергеннен кейін ғана NAT соңғы нүктеден клиентке пакеттерді жіберуге рұқсат береді. STUN симметриялық NAT (екі тарапты NAT деп те аталады)пен жұмыс істемейді, ол көбінесе ірі компаниялардың желілерінде кездеседі. STUN серверінің IP-даресі соңғы нүктеден өзгеше болғандықтан, симметриялық NAT жағдайында STUN сервері үшін NAT бейнесі соңғы нүктеге қарағанда басқаша болады. 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.