STUN Server: що це, як працює та де використовується

Що таке STUN сервер

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

Архітектура STUN включає два компоненти: клієнт STUN, вбудований в додаток (наприклад, браузер або нативний додаток WebRTC), і 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

STUN сервер дозволяє визначити тип NAT через послідовність тестових запитів. Клієнт надсилає запити з різними прапорціями (CHANGE-REQUEST) та аналізує відповіді. Повний цикл виявлення включає надсилання запитів на різні IP-адреси та порти STUN сервера. Якщо сервер відповідає на запит зі зміненим портом — NAT типу Restricted Cone. Якщо не відповідає на запит зі зміненим портом та IP — NAT типу Symmetric. Ця інформація критична для вибору стратегії ICE в WebRTC.

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

STUN сервер здатен виявити чотири основні типи NAT, кожен з яких по-різному впливає на можливість встановлення P2P-з’єднання. Тип NAT визначає, чи може STUN забезпечити пряме з’єднання між двома клієнтами. Він також визначає, який 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 кандидат:", 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 кандидат) та додає її до списку ICE кандидатів. Після збору всіх кандидатів вони надсилаються віддаленому піру через Signaling Server для спроби встановлення прямого P2P-з’єднання.

Типи ICE кандидатів та 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.