STUN Server : qu’est-ce que c’est, comment ça marche et où c’est utilisé

Qu’est-ce qu’un serveur STUN

STUN Server (Session Traversal Utilities for NAT) est un service réseau fonctionnant selon le protocole défini dans la RFC 5389 et mis à jour dans la RFC 8489. La tâche principale d’un serveur STUN est de fournir au client des informations sur sa propre adresse IP publique et son port tels qu’ils sont vus depuis le réseau externe, ainsi que de déterminer le type de périphérique NAT entre le client et Internet.

L’architecture STUN comprend deux composants : un client STUN intégré dans l’application (par exemple, un navigateur ou une application native WebRTC) et un serveur STUN déployé dans le réseau public. Le client envoie une Binding Request au serveur, qui dans sa réponse indique l’adresse IP source et le port de la requête — c’est-à-dire les adresses publiques du client telles que vues par le serveur. En comparant ces données avec ses adresses locales, le client peut déterminer quel type de NAT est utilisé dans son réseau.

Protocole STUN

STUN fonctionne sur UDP (port 3478 par défaut) ou TCP (port 3478 ou 5349 pour TLS). Un message STUN se compose d’un en-tête de 20 octets et d’un nombre variable d’attributs. L’en-tête contient le type de message (Binding Request, Binding Response, Binding Error Response), la longueur et un identifiant de transaction unique (96 bits) permettant de faire correspondre les demandes et les réponses. Chaque Binding Response contient l’attribut XOR-MAPPED-ADDRESS — l’adresse externe du client, encodée avec un masquage pour se protéger contre les attaques basées sur l’interception du trafic STUN.

Comment fonctionne un serveur STUN

Un serveur STUN fonctionne selon un protocole simple de demande-réponse. Le client derrière le NAT crée une Binding Request et l’envoie au serveur STUN. Le serveur reçoit le paquet, extrait l’adresse IP source et le port de l’expéditeur de l’en-tête UDP, puis crée une Binding Response, en empaquetant cette adresse dans l’attribut XOR-MAPPED-ADDRESS. La réponse est renvoyée à l’adresse source de la demande.

Le client reçoit la réponse et extrait le XOR-MAPPED-ADDRESS, qui contient l’adresse IP externe et le port attribués par le périphérique NAT. Ensuite, le client compare cette adresse avec son adresse locale (RFC 1919 — privée). Si les adresses correspondent, le client n’est pas derrière un NAT. Si elles diffèrent, le client est derrière un NAT, et l’adresse externe est utilisée comme candidat pour ICE (Interactive Connectivity Establishment) dans WebRTC.

Processus de découverte du NAT

Un serveur STUN permet de déterminer le type de NAT via une séquence de requêtes de test. Le client envoie des requêtes avec différents indicateurs (CHANGE-REQUEST) et analyse les réponses. Le cycle complet de découverte comprend l’envoi de requêtes à différentes adresses IP et ports du serveur STUN. Si le serveur répond à une requête avec un port modifié, le NAT est de type Restricted Cone. S’il ne répond pas à une requête avec un port et une IP modifiés, le NAT est de type Symmetric. Cette information est cruciale pour choisir la stratégie ICE dans WebRTC.

Serveur STUN et types de NAT

Un serveur STUN peut détecter quatre types principaux de NAT, chacun affectant différemment la capacité à établir une connexion P2P. Le type de NAT détermine si STUN peut permettre une connexion directe entre deux clients. Il détermine également quel candidat ICE — host, server reflexive ou relay — sera utilisé pour la connexion.

Symmetric NAT est le seul type avec lequel STUN ne peut pas fonctionner. Avec Symmetric NAT, chaque nouvelle requête vers un nouvel hôte de destination reçoit une adresse externe différente (IP et/ou port). Étant donné que le serveur STUN signale l’adresse pour la connexion au serveur STUN lui-même, cette adresse ne convient pas pour se connecter à un autre client. Dans de tels cas, WebRTC utilise un serveur TURN pour relayer le trafic. Selon les recherches (Ford et al., RFC 3489, 2003), environ 8à 10 % de tous les périphériques NAT sur Internet sont symétriques.

Utilisation du serveur STUN dans WebRTC

Un serveur STUN est intégré dans WebRTC via la configuration RTCPeerConnection. Un navigateur ou une application native utilise STUN pour collecter les candidats ICE, qui sont ensuite échangés via le serveur de signalisation. Dans la configuration WebRTC, le serveur STUN est spécifié dans le tableau iceServers avec le préfixe stun: pour UDP ou stuns: pour les connexions TLS.

Considérons un exemple de configuration d’un serveur STUN en JavaScript lors de la création d’une RTCPeerConnection pour une application 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);

Cet exemple utilise les serveurs STUN publics de Google (stun.l.google.com:19302). Lors de la création d’une offre ou d’une réponse, le navigateur envoie automatiquement une Binding Request STUN aux serveurs spécifiés, reçoit l’adresse externe (candidat server reflexive) et l’ajoute à la liste des candidats ICE. Après la collecte de tous les candidats, ils sont envoyés au pair distant via le serveur de signalisation pour tenter d’établir une connexion P2P directe.

Types de candidats ICE et STUN

Dans le processus ICE, il existe trois types de candidats : host (adresse locale), srflx (server reflexive — obtenu depuis STUN) et relay (relayé via TURN). Le serveur STUN permet la création de candidats srflx, qui ont une priorité plus élevée que les candidats relay car une connexion basée sur STUN est directe et ne nécessite pas de relais. Le processus ICE vérifie toutes les combinaisons de candidats (locaux et obtenus depuis STUN) des deux pairs, en commençant par les priorités les plus élevées.

Limitations du protocole STUN

Un serveur STUN a des limitations fondamentales liées à l’architecture du protocole. La limitation principale est l’incapacité à fonctionner avec Symmetric NAT, où chaque nouvelle requête vers un hôte externe reçoit un port externe unique. Dans ce cas, l’adresse obtenue du serveur STUN ne peut pas être utilisée pour se connecter à un autre pair car le NAT a créé une liaison uniquement pour la communication avec le serveur STUN lui-même.

La deuxième limitation est que STUN ne fournit pas de relais de données. Si la connexion P2P directe est impossible (les deux pairs derrière Symmetric NAT), STUN n’offre pas de chemin alternatif pour la transmission des données. Dans ce cas, un serveur TURN est nécessaire, qui agit comme un relais de trafic multimédia entre les pairs, recevant les données d’un participant et les envoyant à un autre via son adresse IP publique.

• Symmetric NAT — STUN ne fonctionne pas avec un NAT symétrique car l’adresse externe est unique pour chaque hôte de destination et ne peut pas être réutilisée pour le P2P.
• Pare-feu avec inspection approfondie des paquets — certains pare-feu bloquent le trafic STUN en détectant les signatures du protocole dans les paquets UDP sur le port 3478.
• IPv6 — dans les réseaux IPv6, le NAT n’est généralement pas utilisé, donc STUN n’est pas nécessaire, mais WebRTC sur IPv6 peut utiliser des candidats host sans avoir besoin de STUN ou TURN.
• Dépendance à la disponibilité — le serveur STUN doit être accessible au client pendant la phase d’établissement de la connexion, sinon les candidats srflx ne seront pas collectés.
• Sécurité — le protocole STUN est vulnérable aux attaques par amplification si le serveur est mal configuré et répond aux requêtes avec une adresse source falsifiée.

Malgré les limitations, un serveur STUN reste un composant essentiel de l’infrastructure WebRTC. Dans la plupart des cas (80 à 90 %), une connexion P2P directe peut être établie avec STUN, ce qui évite les coûts du relais TURN et réduit la latence de transmission des données multimédias. Pour les applications WebRTC publiques, il est recommandé d’utiliser une combinaison de serveurs STUN et TURN avec un fallback automatique.