STUN Server: wat is het, hoe werkt het en waar wordt het gebruikt

Wat is STUN Server

STUN Server (Session Traversal Utilities for NAT) — is een netwerkdienst die werkt volgens het protocol gedefinieerd in RFC 5389 en bijgewerkt in RFC 8489. De hoofdtaak van de STUN-server is om de client informatie te geven over zijn eigen openbare IP-adres en poort die zichtbaar zijn vanuit het externe netwerk, en om het type NAT-apparaat tussen de client en internet te bepalen.

De STUN-architectuur omvat twee componenten: een STUN-client ingebouwd in de applicatie (bijvoorbeeld een browser of native WebRTC-applicatie) en een STUN-server geplaatst in het openbare netwerk. De client stuurt een STUN Binding Request naar de server, die in het antwoord het IP-adres en de poort van de verzoekbron aangeeft — dat wil zeggen de openbare adressen van de client zoals gezien door de server. Door deze gegevens te vergelijken met lokale adressen, kan de client bepalen welk type NAT in zijn netwerk wordt gebruikt.

STUN-protocol

STUN werkt via UDP (standaard poort 3478) of TCP (poort 3478 of 5349 voor TLS). Een STUN-bericht bestaat uit een 20-byte header en een variabel aantal attributen. De header bevat het berichttype (Binding Request, Binding Response, Binding Error Response), de lengte en een unieke transactie-ID (96 bits) waarmee verzoeken en antwoorden kunnen worden gekoppeld. Elke Binding Response bevat het attribuut XOR-MAPPED-ADDRESS — het externe adres van de client, gecodeerd met masking ter bescherming tegen aanvallen gebaseerd op het onderscheppen van STUN-verkeer.

Hoe werkt een STUN-server

De STUN-server werkt volgens een eenvoudig verzoek-antwoordprotocol. De client achter NAT vormt een Binding Request en stuurt deze naar de STUN-server. De server ontvangt het pakket, haalt uit de UDP-header het bron-IP-adres en de afzenderpoort, en vormt vervolgens een Binding Response door dit adres in het attribuut XOR-MAPPED-ADDRESS te verpakken. Het antwoord wordt teruggestuurd naar het bronadres van het verzoek.

De client ontvangt het antwoord en extraheert XOR-MAPPED-ADDRESS, dat het externe IP-adres en de poort bevat die door het NAT-apparaat zijn toegewezen. Vervolgens vergelijkt de client dit adres met zijn lokale (RFC 1919 — privé) adres. Als de adressen overeenkomen — bevindt de client zich niet achter NAT. Als ze verschillen — bevindt de client zich achter NAT en wordt het externe adres gebruikt als kandidaat voor ICE (Interactive Connectivity Establishment) in WebRTC.

NAT-detectieproces (NAT Discovery)

De STUN-server maakt het mogelijk het NAT-type te bepalen via een reeks testverzoeken. De client stuurt verzoeken met verschillende vlaggen (CHANGE-REQUEST) en analyseert de antwoorden. De volledige detectiecyclus omvat het verzenden van verzoeken naar verschillende IP-adressen en poorten van de STUN-server. Als de server antwoordt op een verzoek met gewijzigde poort — NAT van het type Restricted Cone. Als hij niet antwoordt op een verzoek met gewijzigde poort en IP — NAT van het type Symmetric. Deze informatie is cruciaal voor het kiezen van de ICE-strategie in WebRTC.

STUN-server en NAT-types

De STUN-server kan vier hoofdtypen NAT bepalen, die elk de mogelijkheid om een P2P-verbinding tot stand te brengen anders beïnvloeden. Het NAT-type bepaalt of STUN een directe verbinding tussen twee clients kan garanderen. Van het NAT-type hangt af welke ICE-kandidaat — host, server reflexive of relay — voor de verbinding wordt gebruikt.

Symmetric NAT — het enige type waar STUN niet mee overweg kan. Bij Symmetric NAT krijgt elk nieuw verzoek naar een nieuwe doelhost een ander extern adres (IP en/of poort). Omdat de STUN-server het adres rapporteert voor de verbinding met de STUN-server zelf, is dit adres onbruikbaar voor verbinding met een andere client. In dergelijke gevallen wordt in WebRTC een TURN-server gebruikt voor het doorsturen van verkeer. Volgens onderzoek (Ford et al., RFC 3489, 2003) is ongeveer 8–10% van alle NAT-apparaten op internet symmetrisch.

Gebruik van STUN-server in WebRTC

De STUN-server wordt geïntegreerd in WebRTC via de configuratie van RTCPeerConnection. De browser of native applicatie gebruikt STUN voor het verzamelen van ICE-kandidaten, die vervolgens worden uitgewisseld via de Signaling Server. In de WebRTC-configuratie wordt de STUN-server opgegeven in de array iceServers met het voorvoegsel stun: voor UDP of stuns: voor TLS-verbinding.

Laten we een voorbeeld bekijken van het configureren van een STUN-server in JavaScript bij het maken van een RTCPeerConnection voor een WebRTC-applicatie.

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

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

In dit voorbeeld worden de openbare STUN-servers van Google (stun.l.google.com:19302) gebruikt. Bij het maken van een offer of answer stuurt de browser automatisch een STUN Binding Request naar de opgegeven servers, ontvangt het externe adres (server reflexive candidate) en voegt het toe aan de lijst met ICE-kandidaten. Nadat alle kandidaten zijn verzameld, worden ze naar de externe partner gestuurd via de Signaling Server om te proberen een directe P2P-verbinding tot stand te brengen.

ICE-kandidaattypen en STUN

In het ICE-proces bestaan drie typen kandidaten: host (lokaal adres), srflx (server reflexive — verkregen van STUN) en relay (doorgestuurd via TURN). De STUN-server zorgt voor het verschijnen van srflx-kandidaten, die een hogere prioriteit hebben dan relay, omdat de verbinding via STUN direct is en geen doorsturing vereist. Het ICE-proces controleert alle combinaties van kandidaten (lokaal en verkregen van STUN) van beide partijen, te beginnen met de hoogste prioriteiten.

Beperkingen van het STUN-protocol

De STUN-server heeft fundamentele beperkingen gerelateerd aan de architectuur van het protocol. De belangrijkste beperking is het niet kunnen werken met Symmetric NAT, waarbij elk nieuw verzoek naar een externe host een unieke externe poort krijgt. In dit geval kan het adres dat van de STUN-server is verkregen niet worden gebruikt voor verbinding met een andere partner, omdat NAT alleen een binding heeft gemaakt voor communicatie met de STUN-server zelf.

De tweede beperking houdt verband met het feit dat STUN geen datadoorstuuring biedt. Als een directe P2P-verbinding onmogelijk is (beide partijen bevinden zich achter Symmetric NAT), biedt STUN geen alternatief pad voor gegevensoverdracht. In dit geval is een TURN-server vereist, die fungeert als doorstuurschakeling voor mediaverkeer tussen partijen, door gegevens van de ene deelnemer te ontvangen en naar de andere te sturen via zijn openbare IP-adres.

• Symmetric NAT — STUN werkt niet met symmetrische NAT, omdat het externe adres uniek is voor elke doelhost en niet opnieuw kan worden gebruikt voor P2P.
• Firewall Deep Packet Inspection — sommige firewalls blokkeren STUN-verkeer door het te detecteren aan de hand van protocolsignaturen in UDP-pakketten op poort 3478.
• IPv6 — in IPv6-netwerken wordt NAT meestal niet gebruikt, dus is STUN niet nodig, maar WebRTC over IPv6 kan rondkomen met host-kandidaten zonder STUN of TURN.
• Afhankelijkheid van beschikbaarheid — de STUN-server moet toegankelijk zijn voor de client in de fase van verbindingsopbouw, anders worden srflx-kandidaten niet verzameld.
• Beveiliging — het STUN-protocol is kwetsbaar voor versterkingsaanvallen (amplification attack) als de server verkeerd is geconfigureerd en reageert op verzoeken met een vervalst bronadres.

Ondanks de beperkingen blijft de STUN-server een kritiek onderdeel van de WebRTC-infrastructuur. In de meeste gevallen (80–90%) kan een directe P2P-verbinding worden opgezet met behulp van STUN, waardoor TURN-doorstuurkosten worden vermeden en de vertraging bij het verzenden van mediagegevens wordt verminderd. Voor openbare WebRTC-applicaties wordt aanbevolen een combinatie van STUN- en TURN-servers te gebruiken met automatische fallback om verbinding in alle netwerkomstandigheden te garanderen.