STUN Server: ce este, cum funcționează și unde se utilizează

Ce este STUN Server

STUN Server (Session Traversal Utilities for NAT) — este un serviciu de rețea care funcționează conform protocolului definit în RFC 5389 și actualizat în RFC 8489. Sarcina principală a serverului STUN este de a oferi clientului informații despre propria adresă IP publică și portul vizibile din rețeaua externă, precum și de a determina tipul dispozitivului NAT între client și internet.

Arhitectura STUN include două componente: clientul STUN încorporat în aplicație (de exemplu, browserul sau aplicația nativă WebRTC) și serverul STUN amplasat în rețeaua publică. Clientul trimite o cerere STUN Binding Request pe server, care în răspuns indică adresa IP și portul sursei cererii — adică adresele publice ale clientului văzute de server. Comparând aceste date cu adresele locale, clientul poate determina ce tip de NAT este utilizat în rețeaua sa.

Protocolul STUN

STUN funcționează prin UDP (portul 3478 implicit) sau TCP (portul 3478 sau 5349 pentru TLS). Mesajul STUN constă dintr-un antet de 20 de octeți și un număr variabil de atribute. Antetul conține tipul mesajului (Binding Request, Binding Response, Binding Error Response), lungimea și un identificator unic de tranzacție (96 de biți) care permite asocierea cererilor și răspunsurilor. Fiecare Binding Response conține atributul XOR-MAPPED-ADDRESS — adresa externă a clientului, codată prin mascare pentru protecția împotriva atacurilor bazate pe interceptarea traficului STUN.

Cum funcționează serverul STUN

Serverul STUN funcționează după un simplu protocol cerere-răspuns. Clientul aflat în spatele NAT formează un Binding Request și îl trimite serverului STUN. Serverul primește pachetul, extrage din antetul UDP adresa IP sursă și portul expeditorului, apoi formează un Binding Response, împachetând această adresă în atributul XOR-MAPPED-ADDRESS. Răspunsul este trimis înapoi la adresa sursei cererii.

Clientul primește răspunsul și extrage XOR-MAPPED-ADDRESS, care conține adresa IP externă și portul atribuite de dispozitivul NAT. Apoi clientul compară această adresă cu adresa sa locală (RFC 1919 — privată). Dacă adresele coincid — clientul nu se află în spatele NAT. Dacă diferă — clientul este în spatele NAT, iar adresa externă este utilizată ca candidat pentru ICE (Interactive Connectivity Establishment) în WebRTC.

Procesul de detectare a NAT (NAT Discovery)

Serverul STUN permite determinarea tipului NAT printr-o secvență de cereri de test. Clientul trimite cereri cu diferite flaguri (CHANGE-REQUEST) și analizează răspunsurile. Ciclul complet de detectare include trimiterea de cereri la diferite adrese IP și porturi ale serverului STUN. Dacă serverul răspunde la o cerere cu portul modificat — NAT de tip Restricted Cone. Dacă nu răspunde la o cerere cu portul și IP-ul modificate — NAT de tip Symmetric. Această informație este critică pentru alegerea strategiei ICE în WebRTC.

Serverul STUN și tipurile de NAT

Serverul STUN este capabil să determine patru tipuri principale de NAT, fiecare influențând diferit posibilitatea stabilirii conexiunii P2P. Tipul NAT determină dacă STUN poate asigura conexiunea directă între doi clienți. De tipul NAT depinde care candidat ICE — host, server reflexive sau relay — va fi utilizat pentru conexiune.

Symmetric NAT — singurul tip cu care STUN nu se descurcă. În Symmetric NAT, fiecare cerere nouă către o gazdă destinație nouă primește o adresă externă diferită (IP și/sau port). Deoarece serverul STUN raportează adresa pentru conexiunea cu serverul STUN însuși, această adresă este inutilizabilă pentru conexiunea cu un alt client. În astfel de cazuri, în WebRTC este utilizat serverul TURN pentru retransmisia traficului. Conform cercetărilor (Ford et al., RFC 3489, 2003), aproximativ 8–10% din toate dispozitivele NAT din internet sunt simetrice.

Utilizarea serverului STUN în WebRTC

Serverul STUN este integrat în WebRTC prin configurarea RTCPeerConnection. Browserul sau aplicația nativă utilizează STUN pentru colectarea candidaților ICE, care apoi sunt schimbați prin Signaling Server. În configurarea WebRTC, serverul STUN este specificat în matricea iceServers cu prefixul stun: pentru UDP sau stuns: pentru conexiunea TLS.

Să examinăm un exemplu de configurare a serverului STUN în JavaScript la crearea RTCPeerConnection pentru o aplicație 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("Candidat ICE:", event.candidate.candidate);
    }
};

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

În acest exemplu sunt utilizate serverele STUN publice Google (stun.l.google.com:19302). La crearea offer sau answer, browserul trimite automat STUN Binding Request pe serverele specificate, primește adresa externă (server reflexive candidate) și o adaugă în lista candidaților ICE. După colectarea tuturor candidaților, aceștia sunt trimiși partenerului la distanță prin Signaling Server pentru încercarea de stabilire a conexiunii directe P2P.

Tipurile de candidați ICE și STUN

În procesul ICE există trei tipuri de candidați: host (adresa locală), srflx (server reflexive — obținut de la STUN) și relay (retransmis prin TURN). Serverul STUN asigură apariția candidaților srflx, care au prioritate mai mare decât relay, deoarece conexiunea prin STUN este directă și nu necesită retransmisie. Procesul ICE verifică toate combinațiile de candidați (locale și obținute de la STUN) ai ambilor parteneri, începând cu prioritățile cele mai mari.

Limitările protocolului STUN

Serverul STUN are limitări fundamentale legate de arhitectura protocolului. Limitarea principală este imposibilitatea de a funcționa cu Symmetric NAT, când fiecare cerere nouă către o gazdă externă primește un port extern unic. În acest caz, adresa obținută de la serverul STUN nu poate fi utilizată pentru conexiunea cu un alt partener, deoarece NAT a creat o legătură doar pentru comunicarea cu însuși serverul STUN.

A doua limitare este legată de faptul că STUN nu asigură retransmisia datelor. Dacă conexiunea directă P2P este imposibilă (ambii parteneri se află în spatele Symmetric NAT), STUN nu oferă o cale alternativă pentru transmiterea datelor. în acest caz este necesar serverul TURN, care acționează ca retransmițător al traficului media între parteneri, primind date de la un participant și trimițându-le celuilalt prin adresa sa IP publică.

• Symmetric NAT — STUN nu funcționează cu NAT simetric, deoarece adresa externă este unică pentru fiecare gazdă destinație și nu poate fi reutilizată pentru P2P.
• Firewall Deep Packet Inspection — unele firewalluri blochează traficul STUN, detectându-l după semnăturile protocolului în pachetele UDP pe portul 3478.
• IPv6 — în rețelele IPv6, NAT de obicei nu este utilizat, prin urmare STUN nu este necesar, dar WebRTC pe IPv6 se poate descurca cu candidați host fără nevoia de STUN sau TURN.
• Dependența de disponibilitate — serverul STUN trebuie să fie accesibil clientului în etapa de stabilire a conexiunii, altfel candidații srflx nu vor fi colectați.
• Securitate — protocolul STUN este vulnerabil la atacul de amplificare (amplification attack) dacă serverul este configurat incorect și răspunde la cereri cu adresa sursă falsificată.

În ciuda limitărilor, serverul STUN rămâne o componentă critică a infrastructurii WebRTC. în majoritatea cazurilor (80–90%) conexiunea directă P2P poate fi stabilită cu ajutorul STUN, ceea ce permite evitarea costurilor de retransmisie TURN și reduce întârzierea transmiterii datelor media. Pentru aplicațiile WebRTC publice, se recomandă utilizarea unei combinații de servere STUN și TURN cu fallback automat pentru garantarea conexiunii în orice condiții de rețea.