STUN Server: vad är det, hur fungerar det och var används det

Vad är STUN Server

STUN Server (Session Traversal Utilities for NAT) — är en nätverkstjänst som fungerar enligt protokollet definierat i RFC 5389 och uppdaterat i RFC 8489. Huvuduppgiften för STUN-servern är att ge klienten information om sin egen publika IP-adress och port som är synliga från det externa nätverket, samt att bestämma typen av NAT-enhet mellan klienten och internet.

STUN-arkitekturen består av två komponenter: en STUN-klient inbäddad i applikationen (t.ex. webbläsare eller inbyggd WebRTC-applikation) och en STUN-server placerad i det publika nätverket. Klienten skickar en STUN Binding Request till servern, som i svaret anger IP-adressen och porten för förfrågans källa — det vill säga klientens publika adresser som servern ser. Genom att jämföra dessa data med lokala adresser kan klienten bestämma vilken typ av NAT som används i dess nätverk.

STUN-protokollet

STUN fungerar över UDP (port 3478 som standard) eller TCP (port 3478 eller 5349 för TLS). Ett STUN-meddelande består av en 20-byte rubrik och ett variabelt antal attribut. Rubriken innehåller meddelandetypen (Binding Request, Binding Response, Binding Error Response), längd och en unik transaktionsidentifierare (96 bitar) som gör det möjligt att matcha förfrågningar och svar. Varje Binding Response innehåller attributet XOR-MAPPED-ADDRESS — klientens externa adress, kodad med maskering för att skydda mot attacker baserade på avlyssning av STUN-trafik.

Hur fungerar STUN-servern

STUN-servern fungerar enligt ett enkelt förfrågan-svar-protokoll. Klienten bakom NAT skapar en Binding Request och skickar den till STUN-servern. Servern tar emot paketet, extraherar från UDP-rubriken käll-IP-adressen och avsändarporten, och skapar sedan en Binding Response genom att packa denna adress i attributet XOR-MAPPED-ADDRESS. Svaret skickas tillbaka till förfrågans källadress.

Klienten tar emot svaret och extraherar XOR-MAPPED-ADDRESS, som innehåller den externa IP-adressen och porten som tilldelats av NAT-enheten. Sedan jämför klienten denna adress med sin lokala (RFC 1919 — privata) adress. Om adresserna matchar — befinner sig klienten inte bakom NAT. Om de skiljer sig — befinner sig klienten bakom NAT och den externa adressen används som kandidat för ICE (Interactive Connectivity Establishment) i WebRTC.

Process för NAT-upptäckt (NAT Discovery)

STUN-servern gör det möjligt att bestämma NAT-typen genom en serie testförfrågningar. Klienten skickar förfrågningar med olika flaggor (CHANGE-REQUEST) och analyserar svaren. Den fullständiga upptäcktscykeln innefattar att skicka förfrågningar till olika IP-adresser och portar på STUN-servern. Om servern svarar på en förfrågan med ändrad port — NAT av typen Restricted Cone. Om den inte svarar på en förfrågan med ändrad port och IP — NAT av typen Symmetric. Denna information är kritisk för val av ICE-strategi i WebRTC.

STUN-servern och NAT-typer

STUN-servern kan bestämma fyra huvudtyper av NAT, som var och en påverkar möjligheten att etablera P2P-förbindelse på olika sätt. NAT-typen avgör om STUN kan tillhandahålla en direkt anslutning mellan två klienter. Från NAT-typen beror det på vilken ICE-kandidat — host, server reflexive eller relay — som kommer att användas för anslutningen.

Symmetric NAT — den enda typen som STUN inte kan hantera. Vid Symmetric NAT får varje ny förfrågan till en ny målserver en annan extern adress (IP och/eller port). Eftersom STUN-servern rapporterar adressen för anslutningen till själva STUN-servern, är denna adress oanvändbar för anslutning till en annan klient. I sådana fall används i WebRTC en TURN-server för vidarebefordran av trafik. Enligt forskning (Ford et al., RFC 3489, 2003) är cirka 8–10% av alla NAT-enheter på internet symmetriska.

Användning av STUN-servern i WebRTC

STUN-servern integreras i WebRTC via konfigurationen av RTCPeerConnection. Webbläsaren eller den inbyggda applikationen använder STUN för att samla in ICE-kandidater, som sedan utbyts via Signaling Server. I WebRTC-konfigurationen anges STUN-servern i arrayen iceServers med prefixet stun: för UDP eller stuns: för TLS-anslutning.

Låt oss titta på ett exempel på konfiguration av STUN-server i JavaScript när vi skapar en RTCPeerConnection för en WebRTC-applikation.

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

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

I detta exempel används Googles publika STUN-servrar (stun.l.google.com:19302). När offer eller answer skapas skickar webbläsaren automatiskt en STUN Binding Request till de angivna servrarna, tar emot den externa adressen (server reflexive candidate) och lägger till den i listan över ICE-kandidater. Efter att alla kandidater samlats in skickas de till den fjärran partnern via Signaling Server för att försöka etablera en direkt P2P-förbindelse.

ICE-kandidattyper och STUN

I ICE-processen finns tre typer av kandidater: host (lokal adress), srflx (server reflexive — erhållen från STUN) och relay (vidarebefordrad via TURN). STUN-servern säkerställer uppkomsten av srflx-kandidater, som har högre prioritet än relay, eftersom anslutning via STUN är direkt och inte kräver vidarebefordran. ICE-processen kontrollerar alla kombinationer av kandidater (lokala och erhållna från STUN) från båda parter, med början från de högsta prioriteterna.

Begränsningar av STUN-protokollet

STUN-servern har grundläggande begränsningar relaterade till protokollets arkitektur. Den främsta begränsningen är oförmågan att fungera med Symmetric NAT, där varje ny förfrågan till en extern värd får en unik extern port. I detta fall kan adressen som erhållits från STUN-servern inte användas för anslutning till en annan partner, eftersom NAT har skapat en bindning endast för kommunikation med själva STUN-servern.

Den andra begränsningen är att STUN inte tillhandahåller vidarebefordran av data. Om en direkt P2P-förbindelse är omöjlig (båda parter befinner sig bakom Symmetric NAT), erbjuder STUN ingen alternativ väg för dataöverföring. I detta fall krävs en TURN-server, som fungerar som en vidarebefordrare av medietrafik mellan parterna, genom att ta emot data från en deltagare och skicka dem till den andre via sin publika IP-adress.

• Symmetric NAT — STUN fungerar inte med symmetrisk NAT, eftersom den externa adressen är unik för varje målserver och inte kan återanvändas för P2P.
• Firewall Deep Packet Inspection — vissa brandväggar blockerar STUN-trafik genom att upptäcka den baserat på protokollsignaturer i UDP-paket på port 3478.
• IPv6 — i IPv6-nätverk används NAT vanligtvis inte, så STUN behövs inte, men WebRTC på IPv6 kan klara sig med host-kandidater utan behov av STUN eller TURN.
• Beroende av tillgänglighet — STUN-servern måste vara tillgänglig för klienten i fasen för att etablera anslutning, annars kommer srflx-kandidater inte att samlas in.
• Säkerhet — STUN-protokollet är sårbart för förstärkningsattacker (amplification attack) om servern är felaktigt konfigurerad och svarar på förfrågningar med förfalskad källadress.

Trots begränsningarna förblir STUN-servern en kritisk komponent i WebRTC-infrastrukturen. I de flesta fall (80–90%) kan en direkt P2P-förbindelse etableras med hjälp av STUN, vilket gör det möjligt att undvika kostnader för TURN-vidarebefordran och minska fördröjningen vid överföring av mediadata. För offentliga WebRTC-applikationer rekommenderas att använda en kombination av STUN- och TURN-servrar med automatisk fallback för att garantera anslutning under alla nätverksförhållanden.