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-ом за гаранцију везе у сваким мрежним условима.