STUN Server: что это, как работает и где используется

Что такое STUN Server

STUN Server (Session Traversal Utilities for NAT) — это сетевой сервис, работающий по протоколу, определённому в RFC 5389 и обновлённому в RFC 8489. Основная задача STUN сервера — предоставить клиенту информацию о его собственном публичном IP-адресе и порте, которые видны из внешней сети, а также определить тип NAT-устройства между клиентом и интернетом.

Архитектура STUN включает два компонента: STUN клиент, встроенный в приложение (например, браузер или нативное приложение WebRTC), и STUN сервер, размещённый в общедоступной сети. Клиент отправляет STUN Binding Request на сервер, который в ответе указывает IP-адрес и порт источника запроса — то есть публичные адреса клиента, которые видит сервер. Сравнивая эти данные с локальными адресами, клиент может определить, какой тип NAT используется в его сети.

Протокол STUN

STUN работает поверх UDP (порт 3478 по умолчанию) или TCP (порт 3478 или 5349 для TLS). Сообщение STUN состоит из 20-байтового заголовка и переменного количества атрибутов. Заголовок содержит тип сообщения (Binding Request, Binding Response, Binding Error Response), длину и уникальный идентификатор транзакции (96 бит), позволяющий сопоставлять запросы и ответы. Каждый Binding Response содержит атрибут XOR-MAPPED-ADDRESS — внешний адрес клиента, закодированный с маскированием для защиты от атак на основе перехвата STUN-трафика.

Как работает STUN сервер

STUN сервер работает по простому протоколу запрос-ответ. Клиент, находящийся за NAT, формирует Binding Request и отправляет его на STUN сервер. Сервер получает пакет, извлекает из UDP-заголовка IP-адрес источника и порт отправителя, затем формирует Binding Response, упаковывая этот адрес в атрибут XOR-MAPPED-ADDRESS. Ответ отправляется обратно на адрес источника запроса.

Клиент получает ответ и извлекает XOR-MAPPED-ADDRESS, который содержит внешний IP-адрес и порт, назначенные NAT-устройством. Затем клиент сравнивает этот адрес со своим локальным (RFC 1919 — приватным) адресом. Если адреса совпадают — клиент не находится за NAT. Если различаются — клиент за NAT, и внешний адрес используется как кандидат для ICE (Interactive Connectivity Establishment) в WebRTC.

Процесс обнаружения NAT (NAT Discovery)

STUN сервер позволяет определить тип NAT через последовательность тестовых запросов. Клиент отправляет запросы с разными флагами (CHANGE-REQUEST) и анализирует ответы. Полный цикл обнаружения включает отправку запросов на разные IP-адреса и порты STUN сервера. Если сервер отвечает на запрос с изменённым портом — NAT типа Restricted Cone. Если не отвечает на запрос с изменённым портом и IP — NAT типа Symmetric NAT. Эта информация критична для выбора стратегии ICE в WebRTC.

STUN сервер и типы NAT

STUN сервер способен определить четыре основных типа NAT, каждый из которых по-разному влияет на возможность установки P2P-соединения. Тип NAT определяет, может ли STUN обеспечить установку прямого соединения между двумя клиентами. От типа NAT зависит, какой ICE кандидат — host, server reflexive или relay — будет использован для соединения.

Symmetric NAT — единственный тип, с которым STUN не справляется. При Symmetric NAT каждый новый запрос к новому хосту назначения получает другой внешний адрес (IP и/или порт). Поскольку STUN сервер сообщает адрес для соединения с самим STUN сервером, этот адрес непригоден для соединения с другим клиентом. В таких случаях в WebRTC используется TURN сервер для ретрансляции трафика. По данным исследований (Ford et al., RFC 3489, 2003), около 8–10% всех NAT-устройств в интернете являются симметричными.

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

STUN сервер интегрируется в WebRTC через конфигурацию RTCPeerConnection. Браузер или нативное приложение использует STUN для сбора ICE кандидатов, которые затем обмениваются через Signaling Server. В конфигурации WebRTC STUN сервер указывается в массиве iceServers с префиксом stun: для UDP или stuns: для TLS-соединения.

Рассмотрим пример настройки STUN сервера в JavaScript при создании RTCPeerConnection для WebRTC-приложения.

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("ICE candidate:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

В этом примере используются публичные STUN серверы Google (stun.l.google.com:19302). При создании offer или answer браузер автоматически отправляет STUN Binding Request на указанные серверы, получает внешний адрес (server reflexive candidate) и добавляет его в список ICE кандидатов. После сбора всех кандидатов они отправляются удалённому пиру через Signaling Server для попытки установки прямого P2P-соединения.

ICE Candidate Types и STUN

В процессе ICE существует три типа кандидатов: host (локальный адрес), srflx (server reflexive — получен от STUN) и relay (ретранслированный через TURN). STUN сервер обеспечивает появление srflx-кандидатов, которые имеют более высокий приоритет, чем relay, так как соединение через STUN является прямым и не требует ретрансляции. ICE-процесс проверяет все комбинации кандидатов (локальные и полученные от STUN) обоих пиров, начиная с наивысших приоритетов.

Ограничения STUN протокола

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

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

• Symmetric NAT — STUN не работает при симметричном NAT, так как внешний адрес уникален для каждого хоста назначения и не может быть переиспользован для P2P.
• Firewall Deep Packet Inspection — некоторые файрволы блокируют STUN-трафик, определяя его по сигнатурам протокола в UDP-пакетах на порту 3478.
• IPv6 — в IPv6-сетях NAT обычно не используется, поэтому STUN не требуется, но WebRTC на IPv6 может обходиться host-кандидатами без необходимости STUN или TURN.
• Зависимость от доступности — STUN сервер должен быть доступен клиенту на этапе установки соединения, иначе srflx-кандидаты не будут собраны.
• Безопасность — STUN протокол уязвим к атаке усиления (amplification attack), если сервер неправильно сконфигурирован и отвечает на запросы с подменённым адресом источника.

Несмотря на ограничения, STUN сервер остаётся критическим компонентом WebRTC-инфраструктуры. В большинстве случаев (80–90%) прямое P2P-соединение удаётся установить с помощью STUN, что позволяет избежать затрат на TURN-ретрансляцию и снижает задержку передачи медиаданных. Для публичных WebRTC-приложений рекомендуется использовать комбинацию STUN и TURN серверов с автоматическим fallback.