В реальной сетевой среде Интернета большинство компьютерных хостов защищены брандмауэрами или NAT, и только небольшое количество хостов может иметь прямой доступ к Интернету. Во многих случаях мы хотим, чтобы два хоста в сети могли общаться напрямую, то есть так называемая P2P-связь, без необходимости транзита с других общедоступных серверов. Поскольку хосты могут находиться за брандмауэром или NAT, перед P2P-связью нам необходимо выполнить обнаружение, чтобы подтвердить, могут ли они обмениваться P2P-связью и каким образом. Этот метод часто называют NAT Traversal. Наиболее распространенным обходом NAT является технология на основе UDP, такая как протокол STUN, определенный в RFC3489.

STUN, впервые определенный в RFC3489 как полное решение для обхода NAT, полное английское название — Simple Traversal of UDP Through NAT, то есть просто обход NAT с помощью UDP.

В новой редакции RFC5389 протокол STUN позиционируется как инструмент обхода NAT, а не как полноценное решение, полное английское название — Session Traversal Utilities for NAT, то есть утилита обхода NAT-сессии. За исключением изменения имени, самая большая разница между RFC5389 и RFC3489 заключается в том, что они поддерживают проникновение TCP.

TURN, впервые определенный в RFC5766, полное английское название — Traversal Using Relays around NAT: Relay Extensions to Session Traversal Utilities for NAT, то есть расширение использования relay для проникновения в NAT: STUN. Проще говоря, общим моментом между TURN и STURN является достижение эффекта проникновения через NAT путем изменения адреса частной сети на прикладном уровне.

1 STUN

Прежде чем понять STUN, нам нужно понять типы NAT.

Существует четыре реализации NAT для UDP:

1. Full Cone NAT

Полный конусный NAT, все запросы, отправленные с одного и того же IP-адреса и номера порта во внутренней сети, будут сопоставлены с одним и тем же IP-адресом и номером порта во внешней сети, и любой хост внешней сети может передать этот сопоставленный IP-адрес внешней сети и номер порта. Отправлять пакеты на этот хост в интрасети. .

2. Restricted Cone NAT

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

3. Port Restricted Cone NAT

NAT с ограниченным конусом портов аналогичен NAT с ограниченным конусом, за исключением того, что он включает номер порта. То есть, если узел внешней сети с IP-адресом X и портом P хочет отправлять пакеты на узел внутренней сети, узел внутренней сети должен предварительно отправлять пакеты данных на этот IP-адрес X и порт P.

4. Symmetric NAT

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

1.1 RFC3489/STUN

Shun (простая обход протокола DataGram DataGram через сетевые переводчики адресов), то есть просто прохождение NAT с UDP, является легким протоколом и полным решением на основе UDP для проникновения NAT. Это позволяет приложениям открывать NATS и брандмауэры и другие типы, которые существуют между ними и общедоступным Интернетом. Это также позволяет приложениям определять публичные IP-адреса и номера портов, которые NAT назначает им. Shun - это протокол клиента / сервера и протокол запроса / ответа. Номер порта по умолчанию составляет 3478.

1.1.1 Структура сообщений

Ø заголовок

Все сообщения STUN содержат 20-байтовый заголовок сообщения, включая 16-битный тип сообщения, 16-битную длину сообщения и 128-битный идентификатор транзакции.

байт

0 1 2 3

тип сообщения	длина сообщения
номер транзакции

Значения, разрешенные для типа сообщения, следующие:

0x0001: запрос на объединение

0x0101: Ответ на связывание

0x0111: ответ об ошибке пакета

0x0002: Запрос общего секрета

0x0102: общий частный ответ

0x0112: Ответ на общую частную ошибку

Длина сообщения в байтах от размера сообщения, исключая 20-байтовый заголовок.

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

Ø свойства сообщения

За заголовком сообщения следует 0 или более атрибутов, и каждый атрибут имеет кодировку TLV, включая 16-битный тип атрибута, 16-битную длину атрибута и значение атрибута переменной длины.

байт

0 1 2 3

тип недвижимости	длина атрибута
значение атрибута
...

Типы свойств определяются следующим образом:

MAPPED-ADDRESS

Атрибут MAPPED-ADDRESS представляет сопоставленный IP-адрес и порт. Он включает в себя 8-битное семейство адресов, 16-битный номер порта и IP-адрес фиксированной длины.

RESPONSE-ADDRESS

Атрибут RESPONSE-ADDRESS указывает адрес назначения ответа.

CHASNGE-REQUEST

Клиент использует 32-битный атрибут CHANGE-REQUEST, чтобы запросить у сервера использование другого адреса или номера порта для отправки ответа.

SOURCE-ADDRESS

Атрибут SOURCE-ADDRESS присутствует в пакетном ответе и указывает исходный IP-адрес и порт, с которого сервер отправил ответ.

CHANGED-ADDRESS

Если флаги «изменить IP» и «изменить порт» в атрибуте CHANGE-REQUEST запроса привязки установлены, атрибут CHANGED-ADDRESS указывает IP-адрес и номер порта, с которого был отправлен ответ.

USERNAME

Атрибут USERNAME используется для проверки целостности сообщений и используется для идентификации общих секретов при проверке целостности сообщений. USERNAME обычно появляется в общих личных ответах вместе с PASSWORD. Необязательно появляется в запросах на привязку при использовании проверки целостности сообщения.

PASSWORD

Атрибут PASSWORD используется в ответах с общим секретом вместе с USERNAME. Значение PASSWORD имеет переменную длину и используется как общий секрет. Его длина должна быть кратна 4 байтам, чтобы гарантировать, что атрибут выровнен с границей.

MESSAGE-INTEGRITY

Атрибут MESSAGE-INTEGRITY содержит HMAC-SHA1 сообщения STUN, который может появиться в запросе привязки или ответе привязки; атрибут MESSAGE-INTEGRITY ДОЛЖЕН быть последним атрибутом любого сообщения STUN. Его содержимое определяет значение ключа, вводимое HMAC.

ERROR-CODE

Атрибут ERROR-CODE появляется в пакетных ответах об ошибках или общих частных ответах об ошибках. Его числовые значения ответа варьируются от 100 до 699.

Следующие номера ответов, наряду с их заявлениями причин по умолчанию, в настоящее время определяются следующим образом:

400 (неверный запрос): запрос искажен. Клиент НЕ ДОЛЖЕН повторять запрос до изменения предыдущей попытки.

401 (неавторизованный): запрос пакета не содержит атрибута MESSAGE-INTERITY.

420 (неизвестный атрибут): сервер не распознает обязательный атрибут в запросе.

430 (Expired Eligibility): запрос пакета не содержал атрибута MESSAGE-INTEGRITY, но использовал просроченный

общая конфиденциальность. Клиент должен получить новый общий секрет и повторить попытку.

431 (проверка целостности не удалась): запрос на привязку содержит атрибут MESSAGE-INTEGRITY, но HMAC

Ошибка сертификата. Это может быть симптомом потенциальной атаки или ошибкой реализации клиента.

432 (отсутствует имя пользователя): запрос пакета содержит атрибут MESSAGE-INTEGRITY, но не

Свойство USERNAME. Оба должны присутствовать при проверке целостности.

433 (с использованием TLS): запрос общего секрета прошел TLS (безопасность транспортного уровня)

протокол транспортного уровня), но не получен по TLS.

500 (ошибка сервера): сервер обнаружил временную ошибку, и клиент должен повторить попытку.

600 (глобальный сбой): сервер отказался выполнить запрос, и клиент не должен повторять попытку.

UNKNOWN-ATTRIBUTES

Атрибут UNKNOWN-ATTRIBUTES присутствует только в пакетных ответах об ошибках или ответах об ошибках с общим секретом с номером ответа 420 в его атрибуте ERROR-CODE.

REFLECTED-FROM

Атрибут REFLECTED-FROM присутствует только в ответе на привязку, соответствующий запрос на привязку которого содержит атрибут RESPONSE-ADDRESS. Атрибут содержит исходный IP-адрес, с которого был сделан запрос, и его цель — обеспечить отслеживаемость, чтобы STUN нельзя было использовать в качестве отражателя DOS-атак.

Пространство атрибутов разделено на необязательную часть и обязательную часть.Атрибут, значение которого превышает 0x7fff, является необязательным, то есть клиент или сервер может обработать сообщение, даже если он не знает атрибута; атрибут, значение которого меньше или равный 0x7fff является обязательным для понимания, то есть если не понимать это свойство, иначе клиент или сервер не сможет обработать сообщение.

1.1.2 Принцип реализации

Рисунок 1: ОШЕЛОМЛЕНИЕ

Полный процесс взаимодействия протокола STUN описан выше.Давайте представим конкретные шаги реализации.

Как правило, клиенты настраивают доменное имя поставщика сервера STUN, которое преобразуется в IP-адрес и номер порта для процесса SRV. Имя сервера — «stun», для отправки запроса на привязку используется протокол UDP, а для отправки запроса общего секрета — протокол TCP. Номер порта по умолчанию для протокола STUN — 3478.

Чтобы обеспечить проверку целостности, STUN использует 128-битный общий секрет между клиентом и сервером в качестве ключа в запросах на привязку и ответах на привязку.

Во-первых, клиент получает IP-адрес и номер порта, с которым он установит TCP-соединение в процессе обнаружения. Клиент открывает соединение с этим адресом и портом, начинает согласование TLS и проверяет подлинность сервера. Клиент отправляет запрос общего секрета. Запрос не имеет атрибутов, только заголовки. Сервер генерирует ответ.

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

Сервер получает запрос общего секрета и проверяет запрос, поступающий от соединения TLS; если запрос не получен через TLS, он генерирует ответ об ошибке общего секрета и устанавливает атрибут ERROR-CODE на номер ответа 433; здесь два случая : если запрос получен через TCP, ответ об ошибке отправляется через то же соединение, через которое был получен запрос; если запрос получен через UDP, ответ об ошибке отправляется обратно на исходный IP-адрес и порт, с которого был отправлен запрос.

Сервер проверяет любой атрибут в запросе, и когда есть значение, меньшее или равное 0x7fff, которое он не понимает, он генерирует ответ с общей секретной ошибкой, устанавливает атрибут ERROR-CODE на номер ответа 420 и включает UNKNOWN Атрибут -ATTRIBUTE, листинг его не понимает Значение атрибута меньше или равно 0x7fff. Этот ответ об ошибке отправляется через соединение TLS.

Если запрос правильный, сервер создает ответ с общим секретом, содержащий тот же идентификатор транзакции, что и в запросе, и включая атрибуты USERNAME и PASSWORD. Имена пользователей действительны в течение 10 минут.

Ответ с общим секретом отправляется через то же соединение TLS, от которого был получен запрос, сервер сохраняет соединение открытым, и клиент может закрыть его.

Затем клиент отправляет запрос на привязку, а переносимые атрибуты включают:

Необязательные атрибуты: атрибут RESPONSE-ADDRESS и атрибут CHANGE-REQUEST;

Обязательные атрибуты: атрибут MESSAGE-INTEGRITY и атрибут USERNAME.

Клиенты отправляют пакетные запросы, обеспечивая надежность за счет повторных передач клиентов. Клиент начинает повторную передачу с интервалом 100 мс, каждый раз

Интервал ретрансляции увеличен вдвое, до 1,6 секунды. Повторные передачи продолжались с интервалом в 1,6 секунды до тех пор, пока не будет получен ответ или пока не будет отправлено в общей сложности 9 сообщений. Поэтому, если через 9500 мс ответ не получен, клиент считает, что передача не удалась.

Сервер проверяет атрибут MESSAGE-INTEGRITY запроса на привязку, если он не существует, генерирует ответ об ошибке привязки и устанавливает для атрибута ERROR-CODE номер ответа 401, если он существует, вычисляет значение HMACKey запроса .

Сервер проверяет атрибут USERNAME и генерирует ответ об ошибке привязки, если он не существует, и устанавливает атрибут ERROR-CODE на номер ответа 432; если он существует, но не распознает общий секрет USERNAME (например, он имеет истекло время ожидания), генерирует ответ об ошибке привязки и устанавливает значение ERROR- CODE в атрибуте CODE с номером ответа 430.

Если серверу известен общий секрет, но вычисленный HMAC отличается от запрошенного, он генерирует ответ об ошибке привязки и устанавливает атрибут ERROR-CODE на номер ответа 431.

Предполагая, что проверка целостности сообщения прошла успешно, сервер проверяет значение любого атрибута в запросе, и если он встречает значение, меньшее или равное 0x7fff, которое он не понимает, он генерирует ответ об ошибке привязки и устанавливает атрибут ERROR-CODE. на номер ответа 420, который содержит атрибут UNKNOWN -ATTRIBUTE и список атрибутов, меньших или равных 0x7fff, которые не поняты.

Если запрос правильный, сервер генерирует один пакетный ответ, содержащий тот же идентификатор транзакции, что и пакетный запрос. Сервер добавляет атрибут MAPPED-ADDRESS в ответ на привязку, а IP-адрес и номер порта этого атрибута являются исходным IP-адресом и номером порта запроса на привязку.

Исходный адрес и номер порта ответа на привязку зависят от значения атрибута CHANGE-REQUEST в запросе на привязку, а также от адреса и номера порта, полученных запросом на привязку. Обобщенно следующим образом:

логотип	адрес источника	исходный номер порта	CHANGED-ADDRESS
без	Da	Dp	Ca:Cp
изменить IP	Ca	Dp	Ca:Cp
изменить номер порта	Da	Cp	Ca:Cp
Изменить IP и изменить номер порта	Ca	Cp	Ca:Cp

Таблица 1: Влияние флагов на источник пакета и CHANGED-ADDRESS

Сервер добавляет в ответ на привязку атрибут SOURCE-ADDRESS, который содержит исходный адрес и номер порта для отправки ответа на привязку, и атрибут CHANGED-ADDRESS, который содержит исходный IP-адрес и номер порта.

Если запрос пакета содержит атрибуты USERNAME и MESSAGE-INTEGRITY, сервер добавляет к ответу пакета атрибут MESSAGE-INTEGRITY.

Если запрос привязки содержит атрибут RESPONSE-ADDRESS, сервер включает атрибут REFLECTED-FROM в ответ привязки: если запрос привязки аутентифицируется с использованием имени пользователя, полученного из запроса общего секрета, атрибут REFLECTED-FROM содержит исходный IP-адрес. на который пришел запрос Shared Secret и номер порта; если имя пользователя в запросе не выделено с помощью общего секрета, атрибут REFLECTED-FROM содержит исходный IP-адрес и номер порта объекта, получившего имя пользователя; если нет имя пользователя в запросе, и сервер готов обработать запрос, атрибут REFLECTED-FROM содержит исходный IP-адрес и номер порта, с которого был сделан запрос.

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

Клиент определяет, является ли тип ответа пакетным ответом об ошибке или пакетным ответом. Ответ об ошибке привязки обычно поступает по адресу источника и порту запроса, ответ привязки обычно принимается по адресу и порту атрибута RESPONSE-ADDRESS в запросе.Если такого атрибута нет, ответ привязки будет отправлено на исходный адрес и порт запроса № получено.

В случае ответа об ошибке привязки клиент проверяет номер ответа атрибута ERROR-CODE в ответе: неизвестные атрибуты между 400 и 499 обрабатываются как атрибут 400, неизвестные атрибуты между 500 и 599 обрабатываются как 500, а неизвестные от 600 до 699. Атрибуты обрабатываются как 600. Любой ответ между 100 и 399 прервет повторную передачу запроса, но другие будут проигнорированы; если тип атрибута ответа, полученного клиентом, больше 0x7fff, атрибут будет проигнорирован, если он меньше или равен 0x7fff, повторная передача запроса будет остановлена и проигнорирован весь ответ;

Если это пакетный ответ, клиент проверяет атрибут MESSAGE-INTEGRITY ответа: если он не существует, клиент добавляет атрибут MESSAGE-INTEGRITY к запросу и отбрасывает ответ; если он существует, клиент вычисляет HMAC. ответа. Если вычисленный HMAC отличается от того, что в ответе, отбрасываем ответ и предупреждаем клиента о возможной атаке, если вычисленный HMAC совпадает с таковым в ответе, процесс продолжается;

Повторная передача запроса будет прервана независимо от того, получен ответ Binding Response или Binding Error Response. Клиент продолжает прослушивать ответы на запрос привязки в течение 10 секунд после первого ответа, если он получит какой-либо ответ другого типа сообщения или другого атрибута MAPPED-ADDRESS в течение этого периода, он предупредит пользователя о возможной атаке; и, если клиент получает Если ответ на привязку получен более чем в два раза больше, чем количество отправленных им запросов на привязку, он предупредит пользователя о возможной атаке; если ответ на привязку аутентифицирован и вышеуказанная атака не приводит к падению клиента MAPPED-ADDRESS, клиент может использовать свойства MAPPED-ADDRESS и SOURCE-ADDRESS.

1.1.3 Пример функции STUN

После того, как клиент получает информацию о сервере STUN внеполосным методом, он открывает соединение с соответствующим адресом и портом и начинает согласование TLS с сервером STUN. После открытия соединения клиент отправляет запрос общего секрета по протоколу TCP, а сервер генерирует ответ общего секрета. STUN использует общий секрет между клиентом и сервером, который используется в качестве ключа в запросах на привязку и ответах на привязку. После этого клиент отправляет запрос на привязку на STUN-сервер по протоколу UDP.Когда сообщение с запросом на привязку поступает на сервер, оно может пройти через один или несколько NAT. В результате исходный IP-адрес сообщения с запросом на привязку, полученного сервером STUN, сопоставляется с IP-адресом NAT, ближайшим к серверу STUN.Сервер STUN копирует исходный IP-адрес и номер порта в сообщение ответа на привязку и отправляет обратно IP-адрес, которому принадлежит этот IP.Адрес и номер порта клиента.

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

В случае Full-Cone NAT IP-адрес и порт в ответном сообщении о привязке принадлежат общедоступной сети. Любой хост в общедоступной сети может использовать этот IP-адрес и номер порта для отправки пакетов данных этому приложению. Только приложение Вам нужно прослушать IP-адрес и порт, который только что отправил запрос на привязку.

Конечно, клиент может не находиться перед Full-Cone NAT, фактически он не знает, перед каким типом NAT он стоит. Для определения типа NAT клиент использует дополнительный запрос на привязку. Конкретный процесс очень гибкий, но обычно он работает следующим образом: клиент отправляет еще один запрос на привязку, на этот раз на другой IP-адрес, но используя тот же исходный IP-адрес и номер исходного порта, что и в прошлый раз, если IP-адрес и номер порта в возвращенном пакете отличаются от тех, что в первом возвращенном пакете, и клиент будет знать, что он находится перед симметричным NAT. Чтобы клиент подтвердил, что он находится перед полным конусом NAT, клиент может отправить запрос на привязку с флагом, который указывает серверу использовать другой IP-адрес и порт для отправки ответа на привязку. Другими словами, если клиент отправляет запрос на привязку с парой портов IP-адреса X/Y на пару портов IP-адресов A/B, сервер будет использовать исходный IP-адрес и пару портов адреса с номером исходного порта. C/D для отправки запроса на привязку в X /Y Отправить пакетный ответ. Если клиент получает этот ответ, он знает, что он находится в полноконусном режиме. перед НАТ.

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

1.2 RFC5389/STUN

Протокол STUN был переименован в Session Traversal Utilities for NAT в RFC5389, то есть в утилиту проникновения в сеанс NAT. Здесь утилита обхода сеанса NAT позиционируется как протокол для других протоколов для решения проблемы обхода NAT. Он может использоваться конечными устройствами для проверки IP-адреса и номера порта, назначенного этому концу с помощью NAT. В то же время он также используется для проверки подключения между двумя конечными точками, например протокол проверки активности, который поддерживает записи привязки NAT. STUN можно использовать со многими типами NAT, и они не обязаны обеспечивать особое поведение.

Сам STUN больше не является полным решением для обхода NAT, он эквивалентен инструменту в решении для обхода NAT. Это самое важное изменение по сравнению с версией RFC3489/STUN.

1.2.1 Использование STUN

В настоящее время определены три варианта использования STUN:

Установление интерактивного соединения (ICE) [MMUSIC-ICE], Установление интерактивного соединения

Инициированные клиентом соединения для SIP [SIP-OUTBOUND], инициированное клиентом соединение для SIP

Обнаружение поведения NAT [BEHAVE-NAT], Обнаружение поведения NAT

1.2.2 Структура сообщения

Ø заголовок

Заголовок STUN состоит из 20 байтов, за которыми следует ноль или более атрибутов. Заголовок STUN содержит тип сообщения STUN, волшебный файл cookie, идентификатор транзакции и длину сообщения.

0 1 2 3

00	Тип STUN-сообщения	длина сообщения
Волшебное слово
Идентификатор транзакции (96 бит)

Первые 2 старших бита каждого сообщения STUN должны быть равны 0. Это можно использовать для отличия пакетов STUN от других протоколов, если один и тот же порт используется, когда протокол STUN мультиплексируется с несколькими протоколами.

Тип сообщения определяет класс сообщения (например, запрос, успешный ответ, неудачный ответ, флаг). Хотя здесь есть четыре типа сообщений, их можно разделить на 2 типа транзакций: транзакции запроса/ответа, транзакции флагов.

Поле типа сообщения можно дополнительно разделить на следующую структуру:

M11

M10

Типы сообщений определяются следующим образом:

0b00, означает запрос

0b01, указывающий на флаг

0b10, что указывает на успешный ответ

0b11, для ответа на ошибку

Поле волшебного слова должно содержать фиксированное значение 0x2112A442. В RFC3489 это поле является частью идентификатора транзакции. Настройка магических слов позволяет серверу определить, понимает ли клиент определенные свойства, которые были добавлены в улучшенной версии. Кроме того, его также можно использовать для отличия пакетов от других протоколов при мультиплексировании STUN.

96-битный идентификатор транзакции используется для уникальной идентификации транзакций STUN. Для транзакций запрос/ответ идентификатор транзакции выбирается клиентом STUN, для транзакций флага он выбирается и отправляется прокси-сервером (прокси относится к клиенту или серверу, который поддерживает STUN). В первую очередь он обслуживает ответы, связанные с запросами, поэтому он также помогает предотвращать определенные типы атак. Сервер использует идентификатор транзакции для уникальной идентификации каждой транзакции для всех клиентов. Сам идентификатор транзакции должен быть уникальным и выбираться случайным образом от 0 до 2 в степени 96-1. При повторной отправке того же запроса также необходимо использовать новый идентификатор транзакции. Ответы об успехе или ошибке ДОЛЖНЫ содержать тот же идентификатор транзакции, что и соответствующий запрос.

Поле длины сообщения не включает 20-байтовый заголовок STUN. Все атрибуты STUN должны быть дополнены кратными 4 байтам. Последние 2 бита поля длины сообщения всегда равны 0, что обеспечивает еще один способ отличать пакеты STUN от пакетов других протоколов.

Ø свойства сообщения

После заголовка STUN нуль или более атрибутов. Каждый атрибут имеет кодировку TLV, 16-битный тип, 16-битную длину и значение переменной длины. Каждый атрибут STUN должен быть выровнен по 4-байтовой границе.

байт

0 1 2 3

тип недвижимости	длина атрибута
значение атрибута
...

Пространство собственности разделено на 2 диапазона. Значение типа атрибута в диапазоне от 0x0000 до 0x7fff является обязательным атрибутом понимания, что означает, что если агент STUN не может понять эти атрибуты, он обычно не будет обрабатывать сообщение, содержащее атрибут; значение типа атрибута в диапазон от 0x8000 до 0xffff является необязательным атрибутом понимания. Это означает, что эти атрибуты можно игнорировать, если агент STUN их не понимает.

Набор типов атрибутов STUN поддерживается IANA.

MAPPED-ADDRESS

Атрибут MAPPED-ADDRESS определяет обратный транспортный адрес клиента (сопоставленный адрес).Этот атрибут используется только для клиентов, чьи серверы обратно совместимы с RFC3489.

XOR-MAPPED-ADDRESS

Свойство XOR-MAPPED-ADDRESS такое же, как свойство MAPPED-ADDRESS, за исключением того, что сопоставленный адрес подвергается операции XOR. (Обратите внимание, что операция XOR является своей собственной обратной операцией, и тогда XOR может получить реальный MAPPED-ADDRESS)

USERNAME

Атрибут USERNAME используется для обеспечения целостности сообщения. Он использует комбинацию ИМЯ ПОЛЬЗОВАТЕЛЯ и ПАРОЛЬ для проверки целостности сообщения.

MESSAGE-INTEGRITY

Атрибут MESSAGE-INTEGRITY содержит HMAC-SHA1 сообщения STUN. Он может появиться в сообщении STUN любого типа. Поскольку используется алгоритм хэширования SHA1, HMAC будет иметь размер 20 байт. Текст, используемый в качестве входных данных для HMAC, представляет собой сообщение STUN, включая заголовок, включая атрибуты, предшествующие атрибуту MESSAGE-INTEGRITY. За исключением атрибута FINGERPRINT, прокси-сервер ДОЛЖЕН игнорировать любые атрибуты, которые появляются после атрибута MESSAGE-INTEGRITY.

Значение поля длины в заголовке STUN ДОЛЖНО быть включено до самого атрибута MESSAGE-INTEGRITY, но не включая любые атрибуты, следующие за ним.

FINGERPRINT

Атрибут FINGERPRINT может существовать во всех сообщениях STUN, предоставляя функцию, помогающую отличать пакеты STUN от пакетов других протоколов. Значение атрибута является результатом вычисления сообщения STUN вплоть до атрибута FINGERPRINT, но не включая его, с использованием CRC32 и операции XOR с 32-битным значением 0x5354554e.

ERROR-CODE

Атрибут ERROR-CODE используется в ответных сообщениях об ошибках. Он содержит номер ответа об ошибке в диапазоне от 300 до 699. Номера ответов об ошибках определяются следующим образом:

300: попытка замены, клиент ДОЛЖЕН использовать этот запрос для связи с альтернативным сервером. Этот ответ об ошибке отправляется только в том случае, если запрос включает атрибут USERNAME и действительный атрибут MESSAGE-INTEGRITY, в противном случае он не будет отправлен, а будет отправлен ответ об ошибке с кодом ошибки 400;

400: Bad Request, запрос деформирован, клиент не должен повторять запрос до изменения предыдущей попытки.

401: Неавторизованный запрос не содержит правильных квалификаций для продолжения. Клиент ДОЛЖЕН повторить запрос с соответствующей квалификацией.

420: Неизвестный атрибут, сервер получил STUN-пакет, содержащий обязательный атрибут понимания, но не понял его. Сервер ДОЛЖЕН поместить нераспознанный атрибут в атрибут UNKNOWN-ATTRIBUTE ответа об ошибке.

438: Expired Nonce, одноразовый номер, используемый клиентом, больше недействителен, и клиент должен использовать одноразовый номер, указанный в ответе, для повторной попытки.

500: Ошибка сервера, сервер обнаружил временную ошибку, клиент должен повторить попытку.

REALM

Атрибут REALM может появляться в запросах и ответах. Указать в запросе, что долгосрочная квалификация будет использоваться при сертификации. Присутствие в ответе об ошибке указывает, что сервер ожидает, что клиент будет использовать долгосрочные учетные данные для аутентификации.

NONCE

Атрибут NONCE может появляться в сообщениях запросов и ответов.

UNKNOWN-ATTRIBUTES

Атрибут UNKNOWN-ATTRIBUTES присутствует только в ответах об ошибках с кодом ошибки 420.

SOFTWARE

Атрибут SOFTWARE используется посредником для включения описания версии при отправке сообщений. Он используется как для клиента, так и для сервера. Его значение включает производителя и номер версии. Это свойство не влияет на работу протокола и используется только в целях диагностики и отладки. Атрибут SOFTWARE представляет собой серийный номер переменной длины в кодировке UTF-8, содержащий менее 128 символов.

ALTERNATE-SERVER

Атрибут ALTERNATE-SERVER идентифицирует альтернативный транспортный адрес, который указывает другой сервер STUN, который может попробовать клиент STUN. Формат атрибута такой же, как и в MAPPED-ADDRESS. Семейство IP-адресов должно совпадать с исходным IP-адресом запроса.

1.3 RFC5389 и RFC3489разница

Различия между RFC5389 и RFC3489 заключаются в следующем:

Удаление STUN — это концепция комплексного решения для обхода NAT, а теперь это инструмент для предоставления решений для обхода NAT. Таким образом, имя протокола становится утилитой проникновения в сеанс NAT;

Определяет цель STUN;

Удалено использование STUN для определения типа NAT и обнаружения времени жизни привязки, удалены атрибуты RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST, SOURCE-ADDRESS и REFLECTED-FROM;

Добавлено фиксированное 32-битное поле магического слова, а поле идентификатора транзакции уменьшено на 32 бита;

Добавлено свойство XOR-MAPPED-ADDRESS, которое включается в ответ привязки, если в запросе привязки появляется волшебное слово. В противном случае поведение в RFC3489 зарезервировано (другими словами, MAPPED-ADDRESS включается в пакетный ответ);

Вводит формальную структуру поля типа сообщения с парой однозначных битов для идентификации сообщения «Запрос», «Ответ», «Ошибка-ответ» или «Индикация». Поэтому поле типа сообщения разделено на категории и методы;

Четко указано, что старшие 2 бита STUN — это 0b00, которые можно легко отличить от пакетов RTP при использовании для ICE;

Добавьте атрибут отпечатка пальца, чтобы обеспечить однозначный способ обнаружения различий между STUN и другими протоколами, когда протокол STUN мультиплексирован;

Добавьте поддержку IPv6, клиенты IPv4 могут получить сопоставленный адрес IPv6 и наоборот;

Добавьте механизм долгосрочной аутентификации на основе учетных данных;

Добавлены атрибуты SOFTWARE, REALM, NONCE и ALTERNATE-SERVER;

Метод общего ключа удален, поэтому атрибут PASSWORD также удален;

Убрано использование прослушивания ответов STUN в течение 10 секунд для выявления атаки;

Изменены таймеры транзакций для повышения удобства работы с TCP;

Удалены примеры STUN, такие как централизованное разделение уровней управления и мультимедиа, вместо этого предоставлено больше информации при использовании протокола STUN;

Определяет тип механизма заполнения для изменения описания атрибута длины;

REALM, SERVER, формулировка причины и NONCE ограничены 127 символами, USERNAME ограничена 513 байтами;

Изменены процедуры DNS SRV для TCP и TLS, UDP остался прежним;

1.4 Внедрение новых функций

1.4.1 Механизм отпечатков пальцев

Механизм FINGERPRINT — это дополнительный механизм для распознавания пакетов STUN, когда другие протоколы мультиплексируют STUN с одним и тем же транспортным адресом.Этот механизм не поддерживает совместимость с RFC3489.

В некоторых приложениях, когда множество транспортных адресов на основе той же, будет мультиплексировать сообщение STUN Protocol, например, RTP. Стухие сообщения должны быть отделены от пакета приложения. В настоящее время для этой цели могут быть зафиксированы три вида заголовка заголовка заголовка. Тем не менее, в некоторых случаях три фиксированного поля все еще недостаточно для различения.

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

1.4.2 Откройте для себя серверный механизм через DNS

Клиенты STUN могут использовать DNS для обнаружения IP-адреса и порта сервера STUN. Клиент должен знать доменное имя сервера.

Когда клиент хочет узнать местоположение сервера в общедоступной сети, он использует связанную транзакцию запроса/ответа, а имя сервера в SRV (таблице записей ресурсов) — «stun». При использовании объединенных транзакций запроса/ответа в сеансе TLS имя сервера в SRV — «stuns». Пользователи STUN могут определить дополнительные имена служб записей ресурсов DNS.

Порт по умолчанию для запросов STUN — 3478, который используется для TCP и UDP. Порт по умолчанию для STUN через TLS — 5349. Сервер может запускать STUN через TLS, используя тот же порт, что и STUN через TCP, только программное обеспечение сервера поддерживает решение о том, является ли начальное сообщение сообщением TLS или STUN.

Если в SRV нет доступных записей, клиент выполняет поиск записи A или AAAA для доменного имени. Результатом будет таблица IP-адресов, каждый из которых может быть подключен по протоколу TCP или UDP с использованием номера порта по умолчанию. Обычно требуется TLS, и клиенты подключаются к одному из этих IP-адресов, используя номер порта STUN по умолчанию через TLS.

1.4.3 Механизм целостности аутентификации и сообщения

Механизм краткосрочных сертификатов

Механизм краткосрочных сертификатов предполагает, что перед транзакцией STUN клиент и сервер использовали другие протоколы для обмена сертификатами в виде имени пользователя и пароля. Этот сертификат ограничен по времени.

Например, при использовании ICE две конечные точки внеполосно обмениваются информацией, чтобы согласовать имя пользователя и пароль и использовать их во время мультимедийного сеанса.

Этот сертификат используется для проверки целостности сообщения в каждом запросе и нескольких ответах. По сравнению с механизмом долгосрочного сертификата здесь нет метода запроса и ответа, поэтому ограниченный по времени характер этого сертификата имеет то преимущество, что предотвращает повторное использование.

Механизм долгосрочных сертификатов

Механизм долгосрочного сертификата основан на долгосрочном сертификате, а имя пользователя и пароль используются совместно клиентом и сервером. Этот сертификат будет действителен с момента его предоставления пользователю до тех пор, пока пользователь не перестанет быть пользователем системы.

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

Сначала клиент отправляет запрос без предоставления сертификата и проверки целостности. Сервер отклоняет запрос и предоставляет пользователю область действия (чтобы указать пользователю или прокси-серверу выбрать имя пользователя и пароль) и одноразовый номер. Этот одноразовый номер обеспечивает защиту от повторного использования. Это файл cookie, выбранный сервером таким образом, чтобы время действия или личность клиента были действительными. Клиент повторяет запрос, на этот раз отвечая своим именем пользователя и областью, а также одноразовым номером, предоставленным сервером. Сервер подтверждает одноразовый номер и проверяет целостность сообщения. Если они совпадают, запрос аутентифицируется. Если одноразовый номер больше недействителен, то есть истек, сервер отклоняет запрос и предоставляет новый одноразовый номер.

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

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

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

1.4.4 Механизм резервного сервера

Сервер использует расширенное перенаправление для перенаправления клиента на другой сервер, отвечая сообщением об ошибке с номером ответа об ошибке 300 (попытка резервного копирования). Сервер содержит атрибут ALTERNATE-SERVER в ответе об ошибке.

После того, как клиент получит ответ об ошибке с номером ответа об ошибке 300, он ищет в этом ответе атрибут ALTERNATE-SERVER. Если он будет найден, клиент аннулирует текущую транзакцию и повторит попытку отправки запроса на сервер, указанный в этом свойстве. Если сообщение запроса было аутентифицировано, оно должно использовать тот же сертификат, который ранее был отправлен на сервер, выполняющий операцию перенаправления. Если клиент был перенаправлен на сервер при повторной попытке отправить запрос в течение последних 5 минут, он ДОЛЖЕН игнорировать перенаправление и аннулировать текущую транзакцию, чтобы предотвратить бесконечные циклы перенаправления.

1.5 RFC5389 и RFC3489совместимый

В RFC3489:

UDP — единственный поддерживаемый транспортный протокол

Поле волшебного слова в RFC5389 является частью идентификатора транзакции в RFC3489, а идентификатор транзакции имеет длину 128 бит.

Свойство XOR-MAPPED-ADDRESS отсутствует, метод привязки заключается в использовании вместо этого свойства MAPPED-ADDRESS.

Необходимо обеспечить понимание трех свойств, а именно: адрес ответа, адрес изменения, и эти свойства больше не поддерживаются в RFC5389.

1.5.1 Изменения в обработке на стороне клиента

Клиент, который хочет взаимодействовать с сервером RFC3489, должен отправить сообщение запроса, используя метод привязки, без какого-либо сообщения, на сервер, используя протокол UDP. В случае успеха вы получите ответ об успехе от сервера, содержащий атрибут MAPPED-ADDRESS вместо атрибута XOR-MAPPED-ADDRESS. Клиенты, пытающиеся взаимодействовать с серверами приложений на основе RFC3489, ДОЛЖНЫ быть готовы к получению любого атрибута. Кроме того, клиент ДОЛЖЕН игнорировать любые зарезервированные обязательные понятные атрибуты, присутствующие в ответе. RFC3489 указывает, что в ответе на привязку могут появляться зарезервированные атрибуты 0x0002, 0x0004, 0x0005 и 0x000B.

1.5.2 Изменения в обработке сервера

Серверы знают о сообщениях запроса привязки, отправленных клиентами в RFC3489, которые содержат неправильные волшебные слова. Когда сервер знает о клиенте в RFC3489, он ДОЛЖЕН скопировать значение поля магического слова в сообщении запроса привязки в поле магического слова в ответе привязки и вставить атрибут MAPPED-ADDRESS вместо атрибута XOR-MAPPED. - Атрибут АДРЕС.

В редких случаях клиенты могут включать один из атрибутов RESPONSE-ADDRESS или CHANGE-REQUEST. В этих случаях сервер обрабатывает атрибут как неизвестный принудительно понятный атрибут и отвечает сообщением об ошибке.

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

2 TURN

2.1 RFC5766/TURN

TURN, определенное в RFC5766, полное английское название Обход с использованием ретрансляторов вокруг Nat (TURN): Расширения ретрансляции для утилит обхода сеанса для Nat (Stun), даже расширения релаксации в расширении ретрансляции NAT: Stun. Проще говоря, общность TURN и Stun заключается в достижении проникновения через NAT путем изменения адреса частной сети на прикладном уровне.Это TURN для достижения проникновения через «посредника» через обе стороны.

Если хост находится за NAT, в некоторых случаях он не может напрямую соединиться с другими хостами точка-точка. В этих случаях необходимо использовать услугу ретрансляционного соединения, предоставляемую промежуточной сетью. Протокол TURN используется, чтобы позволить хосту управлять работой реле и использовать реле для обмена данными с узлом. TURN отличается от других протоколов управления ретрансляцией тем, что позволяет клиенту использовать адрес ретрансляции для соединения с несколькими одноранговыми узлами.

Протокол TURN разработан как часть ICE для обхода NAT, хотя его также можно использовать отдельно, когда ICE недоступен.

2.1.1 Обзор операций

Рисунок 2: ПОВОРОТ

В типичной сети клиент TURN подключается к частной сети и подключается к общедоступной сети через один или несколько NAT. В публичной сети есть сервер TURN. В Интернете есть один или несколько узлов, с которыми этот клиент TURN хочет связаться. Эти одноранговые узлы также могут находиться за одним или несколькими NAT. Клиент использует сервер в качестве ретранслятора для отправки пакетов и получения пакетов от этих одноранговых узлов.

Клиент устанавливает сеанс с сервером через комбинацию IP-адреса и порта. Клиент использует команду TURN для создания и управления РАСПРЕДЕЛЕНИЕМ на сервере. Как только распределение создано, клиент может отправить данные приложения на сервер с указанием того, какому узлу предназначены данные, и сервер передаст данные соответствующему узлу. Данные приложения, отправленные клиентом, содержатся в сообщении TURN, а сервер извлекает данные и отправляет их партнеру в виде пакетов UDP. В обратном направлении одноранговый узел отправляет данные приложения на транспортный адрес ретрансляции, предоставленный этим распределением, в виде пакетов UDP. Поскольку сообщения TURN всегда содержат указание на то, с какими одноранговыми узлами взаимодействует клиент, клиент может использовать одно выделение для связи с несколькими одноранговыми узлами.

2.1.2 терминология

Поверните клиента: Stun Client после RFC5766.

TURN-сервер: STUN-сервер, соответствующий RFC5766.

Peer: Хост, к которому хочет подключиться клиент TURN. Сервер TURN ретранслирует трафик для клиента TURN и его партнера, но партнер не использует протокол TURN для взаимодействия с сервером TURN, а получает данные, отправленные с сервера TURN, и отправляет данные серверу TURN.

Транспортный адрес: комбинация IP-адреса и номера порта.

Host Transport Address: Транспортный адрес клиента или однорангового узла.

Серверно-рефлексивный транспортный адрес: транспортный адрес на стороне общедоступной сети NAT, который выделяется NAT и эквивалентен конкретному транспортному адресу хоста.

Ретранслируемый транспортный адрес: транспортный адрес на сервере TURN, который используется клиентом и узлом для ретрансляции данных.

Транспортный адрес сервера TURN: адрес, передаваемый на сервере TURN, клиент отправляет сообщение на сервер STUN.

Адрес однорангового транспорта: транспортный адрес однорангового узла, видимый сервером.Если одноранговый узел находится за NAT, это транспортный адрес отражения однорангового сервера.

Распределение: Предоставьте клиенту транспортный адрес ретрансляции через запрос на выделение.В дополнение к статусу ретрансляции также есть таймеры разрешений и тайм-аутов.

5-кортеж: пять кортежей, включая IP-адрес и порт клиента, IP-адрес и порт сервера, а также комбинацию транспортных протоколов (включая UDP, TCP, TLS).

Канал: Связь между номером канала и транспортным адресом однорангового узла.После того, как номер канала привязан к транспортному адресу однорангового узла, клиент и сервер могут использовать сообщения данных канала с большими эффектами пропускной способности для обмена данными.

Разрешение: одноранговому узлу разрешено использовать свой IP-адрес и транспортный протокол для отправки данных на сервер TURN.Сервер только ретранслирует трафик от однорангового узла, который соответствует существующему разрешению, соответствующему клиенту.

Область: Строка на сервере, описывающая сервер или содержимое. Эта область сообщает клиенту, какие комбинации имени пользователя и пароля можно использовать для проверки подлинности запросов.

Nonce: строка, случайно выбранная сервером и включенная в дайджест сообщения. Чтобы предотвратить ретрансляционные атаки, сервер должен регулярно менять этот одноразовый номер.

2.1.3 Новый метод STUN

Номера для новых методов STUN приведены ниже:

0x003 Allocate

0x004 Refresh

0x006 Send

0x007 Data

0x008 CreatePermission

0x009 ChannelBind

2.1.4 Новый атрибут STUN

0x000c CHANNEL-NUMBER

0x000D LIFETIME

0x0010 Reserved (was BANDWIDTH)

0x0012 XOR-PEER-ADDRESS

0x0013 DATA

0x0016 XOR-RELAYED-ADDRESS

0x0018 EVEN-PORT

0x0019 REQUESTED-TRANSPORT

0x001A НЕ-ФРАГМЕНТ

0x0021 Reserved (was TIMER-VAL)

0x0022 RESERVATION-TOKEN

Длина некоторых атрибутов в вышеперечисленных атрибутах не кратна 4 байтам, используется правило STUN, для восполнения используются 1~3 байта заполнения.

CHANNEL-NUMBER

Свойство CHANNEL-NUMBER содержит номер канала. Атрибут имеет длину 4 байта и содержит 16-битное целое число без знака и 2-байтовое поле RFFU (зарезервировано для будущего использования), которое должно быть установлено в 0 и игнорироваться при получении.

байт

0 1 2 3

Channel Number

RFFU=0

LIFETIME

Атрибут LIFETIME указывает продолжительность, в течение которой сервер поддерживает выделение без получения обновления. Атрибут имеет длину 4 байта и содержит 32-битное целое число без знака, указывающее, сколько секунд осталось до истечения срока действия.

XOR-PEER-ADDRESS

XOR-PEER-ADDRESS определяет адрес и порт однорангового узла, видимые с сервера TURN, например, если одноранговый узел находится за NAT, транспортный адрес однорангового узла, рефлексивный к серверу.

DATA

Атрибут DATA присутствует во всех сообщениях с индикацией отправки и данных. Значение свойства имеет переменную длину и включает данные приложения. Если длина атрибута не кратна 4 байтам, он должен быть дополнен.

XOR-RELAYED-ADDRESS

XOR-RELAYED-ADDRESS присутствует во всех ответах Allocate. Он указывает адрес и порт, которые сервер назначает клиенту.

байт

0 1 2 3

00000000	адрес семьи	Номер порта
IP-адрес (32-битный или 128-битный)

EVEN-PORT

Этот атрибут позволяет клиенту запрашивать четное количество портов на транспортном адресе ретрансляции, а сервер дополнительно резервирует следующий за ним номер порта. Значение атрибута имеет длину 1 байт и имеет следующую структуру:

байт

RFFU

Значение включает 1-битное поле флага:

R: если 1, серверу предлагается зарезервировать следующий более высокий номер порта (на основе того же IP-адреса) для последующих выделений. Если 0, резервирование не запрашивается. Остальные 7-битные значения атрибута ДОЛЖНЫ быть установлены в 0 и игнорируются при приеме. Поскольку атрибут не кратен 4 байтам, необходимо выполнить заполнение.

REQUESTED-TRANSPORT

Через этот атрибут клиент запрашивает конкретный транспортный протокол для назначенного транспортного адреса. Значение атрибута имеет длину 4 байта.

байт

0 1 2 3

Protocol

RFFU

Поле протокола определяет требования к протоколу. Номер протокола следующего поля заголовка может быть взят из поля протокола заголовка IPv4 или значения заголовка IPv6. 17 только разрешить, т.е. UDP. Поле передачи RFFU должно быть установлено на 0 и игнорироваться при приеме. Зарезервировано для использования в будущем.

Не-Фрагмент

Клиент использует этот атрибут, чтобы запросить у сервера установку бита DF (не фрагментировать) в заголовке IP при ретрансляции данных приложения узлу. Атрибут не имеет значения, поэтому поле длины атрибута равно 0.

RESERVATION-TOKEN

Атрибут RESERVATION-TOKEN содержит маркер для уникальной идентификации ретрансляционного транспортного адреса, зарезервированного сервером. Сервер включает этот атрибут в ответ об успешном завершении, чтобы сообщить клиенту о маркере, а клиент включает этот атрибут в последующие запросы на выделение, чтобы запросить у сервера использование транспортного адреса ретрансляции для этого выделения. Значение атрибута имеет длину 8 байт.

2.1.5 Новый номер ответа на ошибку STUN

403 (Запрещено): запрос действителен, но не может быть выполнен из-за административных или аналогичных правил.

437 (несоответствие распределения): сервер получил запрос на выделение в соответствующем месте, но выделения не существует, или в полученном запросе не указано какое-либо выделение, но выделение существует.

441 (НЕПРАВИЛЬНЫЕ УЧЕТНЫЕ ДАННЫЕ): сертификат в запросе не соответствует тем сертификатам, которые использовались для создания распределения.

442 (неподдерживаемый протокол передачи): Сервер запроса на распределение требует использования сервера транспортного протокола и терминала, но сервер не поддерживает транспортный протокол.

486 (достигнута квота распределения): в настоящее время ресурсы распределения не могут быть созданы с тем же именем пользователя.

508 (недостаточно емкости): серверу не удалось выполнить запрос, поскольку некоторые ограничения производительности достигли верхнего предела. В ответе «Распределение» это может быть связано с тем, что в настоящее время у сервера больше нет ресурсов адреса ретрансляции, больше нет запрошенных возможностей или эквивалент определенного зарезервированного токена недоступен.

2.1.6 Подробный пример процесса взаимодействия протоколов

Взяв рисунок 2 в качестве примера для пояснения, в каждое сообщение включаются несколько атрибутов, и отображаются их значения. Для удобочитаемости значения отображаются в удобочитаемом формате.

Клиент отправляет запрос Allocate на транспортный адрес сервера, используя 10.1.1.2:49271 в качестве транспортного адреса. Клиент случайным образом выбирает 96-битный идентификатор транзакции. Сообщение с запросом на выделение включает атрибут SOFTWARE для предоставления информации о версии программного обеспечения клиента; включает атрибут LIFETIME, указывающий, что клиент ожидает, что время жизни выделения составит 1 час вместо 10 минут по умолчанию; включает атрибут REQUESTED-TRANSPORT для указания сервер и одноранговый узел Для передачи между ними используется протокол UDP, атрибут DONT-FRAGMENT включен, поскольку клиент желает использовать атрибут DON'T-FRAGMENT в последующих индикациях отправки.

Сервер ожидает, что любой запрос будет аутентифицирован, поэтому сервер отклоняет первоначальный запрос на выделение и отвечает ответом об ошибке выделения с номером ответа об ошибке 401 (неавторизованный); ответ включает атрибут REALM, указывающий на аутентифицированную область; также включает атрибут NONCE и атрибут ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ.

Клиент получил ответ об ошибке выделения с номером ответа об ошибке 401 и повторит попытку отправки запроса выделения, который будет включать атрибут проверки подлинности. Клиент повторно выбирает новый идентификатор транзакции в новом запросе. Клиент включает атрибут USERNAME, используя значение области, полученное от сервера, чтобы решить, какое значение использовать; запрос также включает атрибуты REALM и NONCE, которые копируются из полученного ответа об ошибке. Наконец, клиент включает свойство MESSAGE-INTEGRITY.

После того, как сервер получает аутентифицированный запрос Allocate, он проверяет правильность каждого атрибута, затем генерирует выделение и отвечает клиенту успешным ответом Allocate. Сервер несет атрибут LIFETIME в этом успешном ответе, в этом случае сервер сокращает 1-часовое время жизни клиентского запроса до 20 минут, потому что этот конкретный сервер не может допускать время жизни более 20 минут; ответ включает в себя XOR-RELAYED- Атрибут ADDRESS — это транспортный адрес ретрансляции выделения; ответ также включает атрибут XOR-MAPPED-ADDRESS, который является серверно-рефлексивным адресом клиента; ответ также включает атрибут SOFTWARE; наконец, атрибут MESSAGE -INTEGRITY для обоснования ответ, обеспечивающий его целостность;

Затем клиент создает разрешение, чтобы подготовиться к отправке некоторых данных приложения узлу А. Это делается с помощью запроса CreatePermission. Запрос несет атрибут XOR-PEER-ADDRESS и содержит IP-адрес запроса, здесь адрес узла A; следует отметить, что номер порта адреса в атрибуте установлен в 0 в запросе CreatePermission , и клиент использует серверно-рефлексивный адрес однорангового узла A вместо его адреса хоста (частный сетевой адрес); клиент несет те же значения имени пользователя, области и одноразового номера, что и в предыдущем запросе Allocate, поэтому запрос распознается сервером. В этот момент запроса клиент не имеет атрибута ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ.

Сервер получает запрос CreatePermission, генерирует соответствующее разрешение и отвечает успешным ответом CreatePermission. В ответ включаются только свойства Transaction-ID и MESSAGE-INTEGRITY.

Теперь клиент использует индикацию отправки для отправки данных приложения узлу А. Серверно-рефлексивный транспортный адрес однорангового узла содержится в атрибуте XOR-PEER-ADDRESS, а данные приложения содержатся в атрибуте DATA. Клиент выполнил функцию обнаружения MTU пути на прикладном уровне, поэтому атрибут DON'T-FRAGMENT используется для информирования сервера о том, что бит DF должен быть установлен при отправке данных узлу через UDP. Индикации не могут быть аутентифицированы с использованием механизма долгосрочных сертификатов, поэтому в этом сообщении отсутствует атрибут MESSAGE-INTEGRITY.

После получения индикации отправки сервер извлекает данные приложения, инкапсулирует их в формате UDP и отправляет их узлу А; исходный транспортный адрес пакета UDP является транспортным адресом ретрансляции, а бит DF устанавливается.

Узел A отвечает серверу собственным UDP-пакетом, содержащим данные приложения. Адрес назначения — это релейный транспортный адрес сервера. Когда сервер получит его, он сгенерирует сообщение с указанием данных для клиента, содержащее атрибут XOR-PEER-ADDRESS. Данные приложения содержатся в атрибуте DATA.

Если клиент хочет связать канал с узлом B сейчас, он укажет номер свободного канала (0x4000 в этом примере) в атрибуте CHANNEL-NUMBER и транспортный адрес узла B в середине атрибута XOR-PEER-ADDRESS. Как и раньше, клиент снова использует имя пользователя, область и одноразовый номер из предыдущего запроса.

Когда сервер получает запрос, сервер привязывает номер канала однорангового узла, устанавливает разрешение для IP-адреса однорангового узла B, а затем возвращает клиенту сообщение об успешном ответе ChannelBind.

Теперь клиент отправляет на сервер сообщение ChannelData, содержащее данные, отправленные узлу B. Это сообщение не является сообщением STUN и поэтому не имеет идентификатора транзакции. В нем три поля: номер канала, данные и длина данных; после получения сервер проверяет номер канала и находит, что он в данный момент привязан, и отправляет данные пиру Б в режиме UDP.

Затем одноранговый узел B отправляет пакет данных UDP в ответ на транспортный адрес ретрансляции сервера. Получив его, сервер отвечает на клиентское сообщение ChannelData, содержащее данные в UDP-пакете. Сервер знает, какому клиенту отправить сообщение ChannelData, поскольку адрес назначения в полученном пакете UDP (то есть транспортный адрес ретрансляции сервера) и знает, какой номер канала использовать, поскольку канал уже связан с соответствующим каналом. транспортный адрес привязан.

Иногда 20-минутное время жизни истекло, и клиенту необходимо обновить выделение. Это делается путем отправки запроса на обновление. Запрос содержит последнее использованное имя пользователя, область и одноразовый номер, а также атрибут ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ. Когда сервер получает запрос на обновление, он замечает, что срок действия значения одноразового номера истек, и отвечает клиенту ответом об ошибке обновления с номером ответа об ошибке 438 (истекший одноразовый номер) и предоставляет новое значение одноразового номера. Предохранитель повторит запрос с новым значением одноразового номера. Если вторая попытка будет принята, сервер ответит успешным ответом. Следует отметить, что в настоящее время клиент не несет в запросе атрибут LIFETIME, поэтому сервер использует 10-минутное время жизни по умолчанию при обновлении выделения клиента.

3 Резюме

В реальной сетевой среде Интернета большинство компьютерных хостов защищены брандмауэрами или NAT, и только небольшое количество хостов может иметь прямой доступ к Интернету. Во многих случаях мы хотим, чтобы два хоста в сети могли общаться напрямую (так называемая P2P-связь) без необходимости транзита с других общедоступных серверов. Поскольку хосты могут находиться за брандмауэром или NAT, перед P2P-связью нам необходимо выполнить обнаружение, чтобы подтвердить, могут ли они обмениваться P2P-связью и каким образом. Этот метод часто называют NAT Traversal.

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

Протокол STUN был пересмотрен в RFC5389 и предназначен для предоставления инструментов для обхода NAT, то есть утилита обхода сеанса NAT — это протокол, используемый другими протоколами для решения проблемы обхода NAT. Он может использоваться конечными устройствами для проверки IP-адреса и номера порта, назначенного этому концу с помощью NAT. В то же время он также используется для проверки подключения между двумя конечными точками, например протокол проверки активности, который поддерживает записи привязки NAT. STUN сам по себе не является полным решением для обхода NAT. Это эквивалентно инструменту в решении обхода NAT. Это самое важное изменение по сравнению с предыдущей версией. STUN, ранее определенный в RFC3489, представляет собой полное решение для обхода NAT. Кроме того, самым большим отличием является поддержка проникновения TCP.

Протокол STUN снова расширен в RFC5766, то есть релейный обход NAT: расширение STUN. Общим моментом между TURN и STUN является достижение эффекта проникновения NAT путем изменения адреса частной сети на прикладном уровне. через исходный протокол STUN, который нельзя использовать между двумя сторонами Хост не может обеспечить функциональные ограничения при прямом соединении точка-точка.

Технология бесконечна, и технология обхода NAT все еще постоянно обновляется.Здесь сделано только краткое введение в протокол STUN/TURN.Подробности см. в RFC3489/5389/5766.