STUN Server: Was es ist, wie es funktioniert und wo es verwendet wird

Was ist ein STUN Server

STUN Server (Session Traversal Utilities for NAT) ist ein Netzwerkdienst, der nach dem in RFC 5389 definierten und in RFC 8489 aktualisierten Protokoll arbeitet. Die Hauptaufgabe eines STUN-Servers besteht darin, einem Client Informationen über seine eigene öffentliche IP-Adresse und seinen Port zu liefern, wie sie vom externen Netzwerk aus gesehen werden, sowie den Typ des NAT-Geräts zwischen dem Client und dem Internet zu bestimmen.

Die STUN-Architektur umfasst zwei Komponenten: einen STUN-Client, der in die Anwendung eingebettet ist (z. B. einen Browser oder eine native WebRTC-Anwendung), und einen STUN-Server, der im öffentlichen Netzwerk bereitgestellt wird. Der Client sendet eine Binding Request an den Server, der in seiner Antwort die Quell-IP-Adresse und den Port der Anfrage angibt — also die öffentlichen Adressen des Clients, wie sie der Server sieht. Durch den Vergleich dieser Daten mit seinen lokalen Adressen kann der Client bestimmen, welcher NAT-Typ in seinem Netzwerk verwendet wird.

STUN-Protokoll

STUN arbeitet über UDP (Standard-Port 3478) oder TCP (Port 3478 oder 5349 für TLS). Eine STUN-Nachricht besteht aus einem 20-Byte-Header und einer variablen Anzahl von Attributen. Der Header enthält den Nachrichtentyp (Binding Request, Binding Response, Binding Error Response), die Länge und eine eindeutige Transaktions-ID (96 Bit), die die Zuordnung von Anfragen und Antworten ermöglicht. Jede Binding Response enthält das Attribut XOR-MAPPED-ADDRESS — die externe Adresse des Clients, die mit Maskierung kodiert ist, um vor Angriffen auf der Grundlage von STUN-Datenverkehrsabfang zu schützen.

Wie ein STUN-Server funktioniert

Ein STUN-Server arbeitet nach einem einfachen Anfrage-Antwort-Protokoll. Der Client hinter NAT erstellt eine Binding Request und sendet sie an den STUN-Server. Der Server empfängt das Paket, extrahiert die Quell-IP-Adresse und den Port des Absenders aus dem UDP-Header, erstellt dann eine Binding Response und verpackt diese Adresse im Attribut XOR-MAPPED-ADDRESS. Die Antwort wird an die Quelladresse der Anfrage zurückgesendet.

Der Client empfängt die Antwort und extrahiert die XOR-MAPPED-ADDRESS, die die vom NAT-Gerät zugewiesene externe IP-Adresse und den Port enthält. Anschließend vergleicht der Client diese Adresse mit seiner lokalen (RFC 1919 — privaten) Adresse. Wenn die Adressen übereinstimmen, befindet sich der Client nicht hinter NAT. Wenn sie abweichen, befindet sich der Client hinter NAT, und die externe Adresse wird als Kandidat für ICE (Interactive Connectivity Establishment) in WebRTC verwendet.

NAT-Entdeckungsprozess

Ein STUN-Server ermöglicht die Bestimmung des NAT-Typs durch eine Reihe von Testanfragen. Der Client sendet Anfragen mit verschiedenen Flags (CHANGE-REQUEST) und analysiert die Antworten. Der vollständige Erkennungszyklus umfasst das Senden von Anfragen an verschiedene IP-Adressen und Ports des STUN-Servers. Wenn der Server auf eine Anfrage mit einem geänderten Port antwortet, handelt es sich um NAT vom Typ Restricted Cone. Wenn er nicht auf eine Anfrage mit geändertem Port und IP antwortet, handelt es sich um NAT vom Typ Symmetric. Diese Information ist entscheidend für die Wahl der ICE-Strategie in WebRTC.

STUN-Server und NAT-Typen

Ein STUN-Server kann vier Haupttypen von NAT erkennen, die jeweils unterschiedliche Auswirkungen auf die Möglichkeit haben, eine P2P-Verbindung herzustellen. Der NAT-Typ bestimmt, ob STUN eine direkte Verbindung zwischen zwei Clients ermöglichen kann. Er bestimmt auch, welcher ICE-Kandidat — host, server reflexive oder relay — für die Verbindung verwendet wird.

Symmetric NAT ist der einzige Typ, mit dem STUN nicht umgehen kann. Bei Symmetric NAT erhält jede neue Anfrage an einen neuen Zielhost eine andere externe Adresse (IP und/oder Port). Da der STUN-Server die Adresse für die Verbindung zum STUN-Server selbst meldet, ist diese Adresse für die Verbindung zu einem anderen Client ungeeignet. In solchen Fällen verwendet WebRTC einen TURN-Server zur Weiterleitung des Datenverkehrs. Laut Untersuchungen (Ford et al., RFC 3489, 2003) sind etwa 8–10 % aller NAT-Geräte im Internet symmetrisch.

Verwendung des STUN-Servers in WebRTC

Ein STUN-Server wird über die RTCPeerConnection-Konfiguration in WebRTC integriert. Ein Browser oder eine native Anwendung verwendet STUN, um ICE-Kandidaten zu sammeln, die dann über den Signaling Server ausgetauscht werden. In der WebRTC-Konfiguration wird der STUN-Server im Array iceServers mit dem Präfix stun: für UDP oder stuns: für TLS-Verbindungen angegeben.

Betrachten wir ein Beispiel für die Einrichtung eines STUN-Servers in JavaScript beim Erstellen einer RTCPeerConnection für eine WebRTC-Anwendung.

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);

In diesem Beispiel werden die öffentlichen STUN-Server von Google verwendet (stun.l.google.com:19302). Beim Erstellen eines Angebots oder einer Antwort sendet der Browser automatisch eine STUN Binding Request an die angegebenen Server, erhält die externe Adresse (Server-Reflexive-Kandidat) und fügt sie zur Liste der ICE-Kandidaten hinzu. Nachdem alle Kandidaten gesammelt wurden, werden sie über den Signaling Server an den entfernten Peer gesendet, um eine direkte P2P-Verbindung herzustellen.

ICE-Kandidatentypen und STUN

Im ICE-Prozess gibt es drei Kandidatentypen: host (lokale Adresse), srflx (server reflexive — von STUN erhalten) und relay (über TURN weitergeleitet). Der STUN-Server ermöglicht die Erstellung von srflx-Kandidaten, die eine höhere Priorität als Relay-Kandidaten haben, da eine STUN-basierte Verbindung direkt ist und keine Weiterleitung erfordert. Der ICE-Prozess überprüft alle Kandidatenkombinationen (lokal und von STUN erhalten) beider Peers, beginnend mit den höchsten Prioritäten.

Einschränkungen des STUN-Protokolls

Ein STUN-Server hat grundlegende Einschränkungen in Bezug auf die Protokollarchitektur. Die Haupteinschränkung ist die Unfähigkeit, mit Symmetric NAT zu arbeiten, bei dem jede neue Anfrage an einen externen Host einen eindeutigen externen Port erhält. In diesem Fall kann die vom STUN-Server erhaltene Adresse nicht für die Verbindung zu einem anderen Peer verwendet werden, da die NAT nur eine Bindung für die Kommunikation mit dem STUN-Server selbst erstellt hat.

Die zweite Einschränkung besteht darin, dass STUN keine Datenweiterleitung bereitstellt. Wenn eine direkte P2P-Verbindung nicht möglich ist (beide Peers hinter Symmetric NAT), bietet STUN keinen alternativen Pfad für die Datenübertragung. In diesem Fall wird ein TURN-Server benötigt, der als Medienverkehrsrelais zwischen den Peers fungiert, Daten von einem Teilnehmer empfängt und sie über seine öffentliche IP-Adresse an einen anderen sendet.

• Symmetric NAT — STUN funktioniert nicht mit symmetrischem NAT, da die externe Adresse für jeden Zielhost eindeutig ist und nicht für P2P wiederverwendet werden kann.
• Firewall Deep Packet Inspection — einige Firewalls blockieren STUN-Datenverkehr, indem sie Protokollsignaturen in UDP-Paketen auf Port 3478 erkennen.
• IPv6 — in IPv6-Netzwerken wird NAT normalerweise nicht verwendet, daher ist STUN nicht erforderlich, aber WebRTC auf IPv6 kann Host-Kandidaten ohne STUN oder TURN verwenden.
• Abhängigkeit von der Verfügbarkeit — der STUN-Server muss dem Client während der Verbindungsaufbauphase zugänglich sein, andernfalls werden keine srflx-Kandidaten gesammelt.
• Sicherheit — das STUN-Protokoll ist anfällig für Verstärkungsangriffe, wenn der Server falsch konfiguriert ist und auf Anfragen mit gefälschter Quelladresse antwortet.

Trotz der Einschränkungen bleibt ein STUN-Server eine kritische Komponente der WebRTC-Infrastruktur. In den meisten Fällen (80–90 %) kann mit STUN eine direkte P2P-Verbindung hergestellt werden, wodurch die Kosten für die TURN-Weiterleitung vermieden und die Latenz bei der Übertragung von Mediendaten reduziert werden. Für öffentliche WebRTC-Anwendungen wird empfohlen, eine Kombination aus STUN- und TURN-Servern mit automatischem Fallback zu verwenden.