STUN Server: co to jest, jak działa i gdzie jest używany

Co to jest STUN Server

STUN Server (Session Traversal Utilities for NAT) — to usługa sieciowa działająca według protokołu określonego w RFC 5389 i zaktualizowanego w RFC 8489. Głównym zadaniem serwera STUN jest dostarczenie klientowi informacji o jego własnym publicznym adresie IP i porcie, które są widoczne z zewnętrznej sieci, a także określenie typu urządzenia NAT między klientem a internetem.

Architektura STUN obejmuje dwa komponenty: klienta STUN wbudowanego w aplikację (na przykład przeglądarkę lub natywną aplikację WebRTC) oraz serwer STUN umieszczony w publicznie dostępnej sieci. Klient wysyła żądanie STUN Binding Request na serwer, który w odpowiedzi podaje adres IP i port źródła żądania — czyli publiczne adresy klienta widziane przez serwer. Porównując te dane z lokalnymi adresami, klient może określić, jaki typ NAT jest używany w jego sieci.

Protokół STUN

STUN działa przez UDP (port 3478 domyślnie) lub TCP (port 3478 lub 5349 dla TLS). Wiadomość STUN składa się z 20-bajtowego nagłówka i zmiennej liczby atrybutów. Nagłówek zawiera typ wiadomości (Binding Request, Binding Response, Binding Error Response), długość i unikalny identyfikator transakcji (96 bitów), umożliwiający dopasowywanie żądań i odpowiedzi. Każda Binding Response zawiera atrybut XOR-MAPPED-ADDRESS — zewnętrzny adres klienta, zakodowany z maskowaniem w celu ochrony przed atakami opartymi na przechwytywaniu ruchu STUN.

Jak działa serwer STUN

Serwer STUN działa według prostego protokołu żądanie-odpowiedź. Klient znajdujący się za NAT tworzy Binding Request i wysyła go na serwer STUN. Serwer odbiera pakiet, wyodrębnia z nagłówka UDP adres IP źródła i port nadawcy, a następnie tworzy Binding Response, pakując ten adres w atrybut XOR-MAPPED-ADDRESS. Odpowiedź jest wysyłana z powrotem na adres źródła żądania.

Klient otrzymuje odpowiedź i wyodrębnia XOR-MAPPED-ADDRESS, który zawiera zewnętrzny adres IP i port przypisane przez urządzenie NAT. Następnie klient porównuje ten adres ze swoim lokalnym (RFC 1919 — prywatnym) adresem. Jeśli adresy są zgodne — klient nie znajduje się za NAT. Jeśli się różnią — klient jest za NAT, a zewnętrzny adres jest używany jako kandydat dla ICE (Interactive Connectivity Establishment) w WebRTC.

Proces wykrywania NAT (NAT Discovery)

Serwer STUN umożliwia określenie typu NAT poprzez sekwencję testowych żądań. Klient wysyła żądania z różnymi flagami (CHANGE-REQUEST) i analizuje odpowiedzi. Pełny cykl wykrywania obejmuje wysyłanie żądań na różne adresy IP i porty serwera STUN. Jeśli serwer odpowiada na żądanie ze zmienionym portem — NAT typu Restricted Cone. Jeśli nie odpowiada na żądanie ze zmienionym portem i IP — NAT typu Symmetric NAT. Ta informacja jest kluczowa dla wyboru strategii ICE w WebRTC.

Serwer STUN a typy NAT

Serwer STUN jest w stanie określić cztery główne typy NAT, z których każdy wpływa inaczej na możliwość ustanowienia połączenia P2P. Typ NAT określa, czy STUN może zapewnić bezpośrednie połączenie między dwoma klientami. Od typu NAT zależy, który kandydat ICE — host, server reflexive czy relay — zostanie użyty do połączenia.

Symmetric NAT — jedyny typ, z którym STUN sobie nie radzi. W Symmetric NAT każde nowe żądanie do nowego hosta docelowego otrzymuje inny zewnętrzny adres (IP i/lub port). Ponieważ serwer STUN podaje adres dla połączenia z samym serwerem STUN, adres ten nie nadaje się do połączenia z innym klientem. W takich przypadkach w WebRTC używany jest serwer TURN do retransmisji ruchu. Według badań (Ford et al., RFC 3489, 2003), około 8–10% wszystkich urządzeń NAT w internecie jest symetrycznych.

Użycie serwera STUN w WebRTC

Serwer STUN jest integrowany z WebRTC poprzez konfigurację RTCPeerConnection. Przeglądarka lub natywna aplikacja używa STUN do zbierania kandydatów ICE, które następnie są wymieniane przez Signaling Server. W konfiguracji WebRTC serwer STUN jest określany w tablicy iceServers z prefiksem stun: dla UDP lub stuns: dla połączenia TLS.

Rozważmy przykład konfiguracji serwera STUN w JavaScript podczas tworzenia RTCPeerConnection dla aplikacji 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("Kandydat ICE:", event.candidate.candidate);
    }
};

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

W tym przykładzie używane są publiczne serwery STUN Google (stun.l.google.com:19302). Podczas tworzenia offer lub answer przeglądarka automatycznie wysyła STUN Binding Request na określone serwery, otrzymuje zewnętrzny adres (server reflexive candidate) i dodaje go do listy kandydatów ICE. Po zebraniu wszystkich kandydatów są one wysyłane do zdalnego partnera przez Signaling Server w celu próby ustanowienia bezpośredniego połączenia P2P.

Typy kandydatów ICE a STUN

W procesie ICE istnieją trzy typy kandydatów: host (adres lokalny), srflx (server reflexive — uzyskany od STUN) i relay (retransmitowany przez TURN). Serwer STUN zapewnia pojawienie się kandydatów srflx, które mają wyższy priorytet niż relay, ponieważ połączenie przez STUN jest bezpośrednie i nie wymaga retransmisji. Proces ICE sprawdza wszystkie kombinacje kandydatów (lokalne i uzyskane od STUN) obu stron, zaczynając od najwyższych priorytetów.

Ograniczenia protokołu STUN

Serwer STUN ma fundamentalne ograniczenia związane z architekturą protokołu. Głównym ograniczeniem jest brak możliwości działania z Symmetric NAT, gdy każde nowe żądanie do zewnętrznego hosta otrzymuje unikalny port zewnętrzny. W tym przypadku adres uzyskany od serwera STUN nie może być użyty do połączenia z innym partnerem, ponieważ NAT utworzył wiązanie tylko dla komunikacji z samym serwerem STUN.

Drugie ograniczenie wiąże się z tym, że STUN nie zapewnia retransmisji danych. Jeśli bezpośrednie połączenie P2P nie jest możliwe (obaj partnerzy za Symmetric NAT), STUN nie oferuje alternatywnej ścieżki przesyłania danych. W tym przypadku wymagany jest serwer TURN, który pełni rolę retransmitora ruchu medialnego między partnerami, przyjmując dane od jednego uczestnika i wysyłając je do drugiego przez swój publiczny adres IP.

• Symmetric NAT — STUN nie działa przy symetrycznym NAT, ponieważ zewnętrzny adres jest unikalny dla każdego hosta docelowego i nie może być ponownie użyty dla P2P.
• Firewall Deep Packet Inspection — niektóre zapory blokują ruch STUN, wykrywając go po sygnaturach protokołu w pakietach UDP na porcie 3478.
• IPv6 — w sieciach IPv6 NAT zwykle nie jest używany, więc STUN nie jest wymagany, ale WebRTC na IPv6 może korzystać z kandydatów host bez potrzeby STUN lub TURN.
• Zależność od dostępności — serwer STUN musi być dostępny dla klienta na etapie ustanawiania połączenia, w przeciwnym razie kandydaci srflx nie zostaną zebrani.
• Bezpieczeństwo — protokół STUN jest podatny na atak wzmacniania (amplification attack), jeśli serwer jest nieprawidłowo skonfigurowany i odpowiada na żądania z podmienionym adresem źródła.

Pomimo ograniczeń, serwer STUN pozostaje krytycznym komponentem infrastruktury WebRTC. W większości przypadków (80–90%) bezpośrednie połączenie P2P udaje się ustanowić za pomocą STUN, co pozwala uniknąć kosztów retransmisji TURN i zmniejsza opóźnienie przesyłania danych medialnych. W publicznych aplikacjach WebRTC zaleca się stosowanie kombinacji serwerów STUN i TURN z automatycznym fallbackiem.