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. Тази информация е критична за избора на 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 кандидат:", 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 кандидати и 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 за гаранциране на връзка при всички мрежови условия.