STUN Server: co to je, jak to funguje a kde se používá

Co je STUN Server

STUN Server (Session Traversal Utilities for NAT) — je síťová služba pracující podle protokolu definovaného v RFC 5389 a aktualizovaného v RFC 8489. Hlavním úkolem STUN serveru je poskytnout klientovi informace o jeho vlastní veřejné IP adrese a portu viditelných z externí sítě, stejně jako určit typ NAT zařízení mezi klientem a internetem.

Architektura STUN zahrnuje dvě součásti: STUN klienta integrovaného v aplikaci (například prohlížeč nebo nativní WebRTC aplikace) a STUN server umístěný ve veřejné síti. Klient odešle STUN Binding Request na server, který v odpovědi uvádí IP adresu a port zdroje požadavku — tedy veřejné adresy klienta, které server vidí. Porovnáním těchto údajů s lokálními adresami může klient určit, jaký typ NAT se používá v jeho síti.

Protokol STUN

STUN pracuje přes UDP (port 3478 standardně) nebo TCP (port 3478 nebo 5349 pro TLS). STUN zpráva se skládá z 20bajtové hlavičky a proměnného počtu atributů. Hlavička obsahuje typ zprávy (Binding Request, Binding Response, Binding Error Response), délku a jedinečný identifikátor transakce (96 bitů), který umožňuje párování požadavků a odpovědí. Každá Binding Response obsahuje atribut XOR-MAPPED-ADDRESS — externí adresu klienta, zakódovanou maskováním pro ochranu proti útokům založeným na zachycování STUN provozu.

Jak funguje STUN server

STUN server pracuje podle jednoduchého protokolu požadavek-odpověď. Klient nacházející se za NAT vytvoří Binding Request a odešle jej na STUN server. Server přijme paket, extrahuje z UDP hlavičky zdrojovou IP adresu a port odesílatele, poté vytvoří Binding Response, zabalením této adresy do atributu XOR-MAPPED-ADDRESS. Odpověď je odeslána zpět na zdrojovou adresu požadavku.

Klient obdrží odpověď a extrahuje XOR-MAPPED-ADDRESS, který obsahuje externí IP adresu a port přidělené NAT zařízením. Poté klient porovná tuto adresu se svou lokální (RFC 1919 — privátní) adresou. Pokud se adresy shodují — klient není za NAT. Pokud se liší — klient je za NAT a externí adresa je použita jako kandidát pro ICE (Interactive Connectivity Establishment) ve WebRTC.

Proces detekce NAT (NAT Discovery)

STUN server umožňuje určení typu NAT pomocí sekvence testovacích požadavků. Klient odesílá požadavky s různými příznaky (CHANGE-REQUEST) a analyzuje odpovědi. Plný detekční cyklus zahrnuje odesílání požadavků na různé IP adresy a porty STUN serveru. Pokud server odpoví na požadavek se změněným portem — NAT typu Restricted Cone. Pokud neodpoví na požadavek se změněným portem a IP — NAT typu Symmetric. Tato informace je klíčová pro výběr strategie ICE ve WebRTC.

STUN server a typy NAT

STUN server je schopen určit čtyři hlavní typy NAT, z nichž každý jinak ovlivňuje možnost vytvoření P2P spojení. Typ NAT určuje, zda STUN může zajistit přímé spojení mezi dvěma klienty. Na typu NAT závisí, který ICE kandidát — host, server reflexive nebo relay — bude použit pro spojení.

Symmetric NAT — jediný typ, se kterým si STUN neporadí. Při Symmetric NAT každý nový požadavek na nový cílový host získá jinou externí adresu (IP a/nebo port). Protože STUN server hlásí adresu pro spojení se samotným STUN serverem, tato adresa je nepoužitelná pro spojení s jiným klientem. V takových případech se ve WebRTC používá TURN server pro přenos provozu. Podle výzkumů (Ford et al., RFC 3489, 2003) je přibližně 8–10 % všech NAT zařízení na internetu symetrických.

Použití STUN serveru ve WebRTC

STUN server je integrován do WebRTC prostřednictvím konfigurace RTCPeerConnection. Prohlížeč nebo nativní aplikace používá STUN pro shromažďování ICE kandidátů, které jsou poté vyměňovány prostřednictvím Signaling Serveru. V konfiguraci WebRTC je STUN server zadán v poli iceServers s prefixem stun: pro UDP nebo stuns: pro TLS spojení.

Podívejme se na příklad konfigurace STUN serveru v JavaScriptu při vytváření RTCPeerConnection pro WebRTC aplikaci.

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 kandidát:", event.candidate.candidate);
    }
};

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

V tomto příkladu jsou použity veřejné STUN servery Google (stun.l.google.com:19302). Při vytváření offer nebo answer prohlížeč automaticky odešle STUN Binding Request na zadané servery, získá externí adresu (server reflexive candidate) a přidá ji do seznamu ICE kandidátů. Po shromáždění všech kandidátů jsou odesláni vzdálenému partnerovi prostřednictvím Signaling Serveru pro pokus o vytvoření přímého P2P spojení.

Typy ICE kandidátů a STUN

V procesu ICE existují tři typy kandidátů: host (lokální adresa), srflx (server reflexive — získaný od STUN) a relay (přenesený přes TURN). STUN server zajišťuje výskyt srflx kandidátů, které mají vyšší prioritu než relay, protože spojení přes STUN je přímé a nevyžaduje přenos. Proces ICE kontroluje všechny kombinace kandidátů (lokálních a získaných od STUN) obou stran, počínaje nejvyššími prioritami.

Omezení protokolu STUN

STUN server má základní omezení související s architekturou protokolu. Hlavním omezením je nemožnost práce se Symmetric NAT, kdy každý nový požadavek na externí host získá jedinečný externí port. V tomto případě nelze adresu získanou od STUN serveru použít pro spojení s jiným partnerem, protože NAT vytvořil vazbu pouze pro komunikaci se samotným STUN serverem.

Druhé omezení souvisí s tím, že STUN neposkytuje přenos dat. Pokud je přímé P2P spojení nemožné (oba partneři jsou za Symmetric NAT), STUN nenabízí alternativní cestu pro přenos dat. V tomto případě je vyžadován TURN server, který funguje jako přenašeč mediálního provozu mezi partnery, přijímá data od jednoho účastníka a odesílá je druhému prostřednictvím své veřejné IP adresy.

• Symmetric NAT — STUN nefunguje se symetrickým NAT, protože externí adresa je jedinečná pro každý cílový host a nelze ji znovu použít pro P2P.
• Firewall Deep Packet Inspection — některé firewally blokují STUN provoz na základě detekce signatur protokolu v UDP paketech na portu 3478.
• IPv6 — v sítích IPv6 se NAT obvykle nepoužívá, proto STUN není nutný, ale WebRTC na IPv6 si vystačí s host kandidáty bez potřeby STUN nebo TURN.
• Závislost na dostupnosti — STUN server musí být pro klienta dostupný ve fázi vytváření spojení, jinak nebudou srflx kandidáti shromážděni.
• Bezpečnost — protokol STUN je zranitelný vůči zesilovacímu útoku (amplification attack), pokud je server nesprávně nakonfigurován a odpovídá na požadavky s padělanou zdrojovou adresou.

Navzdory omezením zůstává STUN server kritickou součástí infrastruktury WebRTC. Ve většině případů (80–90 %) lze přímé P2P spojení vytvořit pomocí STUN, což umožňuje vyhnout se nákladům na TURN přenos a snižuje zpoždění přenosu mediálních dat. Pro veřejné WebRTC aplikace se doporučuje používání kombinace STUN a TURN serverů s automatickým fallbackem pro záruku spojení ve všech síťových podmínkách.