STUN Server: mi ez, hogyan működik és hol használják

Mi az a STUN Server

STUN Server (Session Traversal Utilities for NAT) — egy hálózati szolgáltatás, amely az RFC 5389-ben meghatározott és az RFC 8489-ben frissített protokoll szerint működik. A STUN szerver fő feladata, hogy információt nyújtson az ügyfélnek a saját nyilvános IP-címéről és portjáról, amelyek a külső hálózatból láthatók, valamint meghatározza az ügyfél és az internet közötti NAT eszköz típusát.

A STUN architektúra két összetevőből áll: az alkalmazásba ágyazott STUN ügyfélből (például böngésző vagy natív WebRTC alkalmazás) és a nyilvános hálózatban elhelyezett STUN szerverből. Az ügyfél STUN Binding Requestet küld a szerverre, amely a válaszban jelzi a kérés forrásának IP-címét és portját — vagyis az ügyfél szerver által látott nyilvános címeit. Összehasonlítva ezeket az adatokat a helyi címekkel, az ügyfél meghatározhatja, hogy milyen típusú NAT-ot használnak a hálózatában.

STUN protokoll

STUN UDP-n (alapértelmezett 3478-as port) vagy TCP-n (3478-as port vagy 5349-es TLS-hez) keresztül működik. A STUN üzenet egy 20 bájtos fejlécből és változó számú attribútumból áll. A fejléc tartalmazza az üzenet típusát (Binding Request, Binding Response, Binding Error Response), a hosszt és egy egyedi tranzakcióazonosítót (96 bit), amely lehetővé teszi a kérések és válaszok párosítását. Minden Binding Response tartalmazza az XOR-MAPPED-ADDRESS attribútumot — az ügyfél külső címét, amely maszkolással van kódolva a STUN forgalom elfogásán alapuló támadások elleni védelem érdekében.

Hogyan működik a STUN szerver

A STUN szerver egy egyszerű kérés-válasz protokoll szerint működik. A NAT mögött lévő ügyfél Binding Requestet készít és elküldi a STUN szerverre. A szerver megkapja a csomagot, kivonja az UDP fejlécből a forrás IP-címet és a feladó portját, majd Binding Responseot készít, becsomagolva ezt a címet az XOR-MAPPED-ADDRESS attribútumba. A válasz visszaküldésre kerül a kérés forráscímére.

Az ügyfél megkapja a választ és kivonja az XOR-MAPPED-ADDRESS-t, amely a NAT eszköz által hozzárendelt külső IP-címet és portot tartalmazza. Ezután az ügyfél összehasonlítja ezt a címet a saját helyi (RFC 1919 — privát) címével. Ha a címek megegyeznek — az ügyfél nincs NAT mögött. Ha eltérnek — az ügyfél NAT mögött van, és a külső cím jelöltként szolgál az ICE (Interactive Connectivity Establishment) számára a WebRTC-ben.

NAT felderítési folyamat (NAT Discovery)

A STUN szerver lehetővé teszi a NAT típusának meghatározását tesztkérések sorozatán keresztül. Az ügyfél különböző jelzőkkel (CHANGE-REQUEST) küld kéréseket és elemzi a válaszokat. A teljes felderítési ciklus magában foglalja a kérések küldését a STUN szerver különböző IP-címeire és portjaira. Ha a szerver válaszol a módosított porttal rendelkező kérésre — a NAT Restricted Cone típusú. Ha nem válaszol a módosított porttal és IP-vel rendelkező kérésre — a NAT Symmetric típusú. Ez az információ kritikus fontosságú az ICE stratégia kiválasztásához a WebRTC-ben.

STUN szerver és NAT típusok

A STUN szerver képes meghatározni négy fő NAT típust, amelyek mindegyike eltérően befolyásolja a P2P kapcsolat létrehozásának lehetőségét. A NAT típusa határozza meg, hogy a STUN képes-e közvetlen kapcsolatot biztosítani két ügyfél között. A NAT típusától függ, hogy melyik ICE jelölt — host, server reflexive vagy relay — kerül felhasználásra a kapcsolathoz.

Symmetric NAT — az egyetlen típus, amellyel a STUN nem boldogul. Symmetric NAT esetén minden új kérés egy új célhosthoz más külső címet (IP és/vagy port) kap. Mivel a STUN szerver a STUN szerverrel való kapcsolathoz jelenti a címet, ez a cím nem használható másik ügyfélhez való kapcsolódáshoz. Ilyen esetekben a WebRTC-ben TURN szervert használnak a forgalom továbbítására. Kutatások szerint (Ford et al., RFC 3489, 2003) az interneten lévő összes NAT eszköz körülbelül 8–10%-a szimmetrikus.

STUN szerver használata a WebRTC-ben

A STUN szerver az RTCPeerConnection konfigurációján keresztül integrálódik a WebRTC-be. A böngésző vagy natív alkalmazás STUN-t használ az ICE jelöltek gyűjtéséhez, amelyeket aztán a Signaling Serveren keresztül cserélnek ki. A WebRTC konfigurációban a STUN szerver az iceServers tömbben van megadva stun: előtaggal UDP-hez vagy stuns: előtaggal TLS kapcsolathoz.

Nézzünk egy példát a STUN szerver konfigurálására JavaScript-ben RTCPeerConnection létrehozásakor egy WebRTC alkalmazáshoz.

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

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

Ebben a példában a Google nyilvános STUN szerverei (stun.l.google.com:19302) vannak használva. Az offer vagy answer létrehozásakor a böngésző automatikusan STUN Binding Requestet küld a megadott szerverekre, megkapja a külső címet (server reflexive candidate) és hozzáadja az ICE jelöltek listájához. Az összes jelölt összegyűjtése után elküldésre kerülnek a távoli partnernek a Signaling Serveren keresztül a közvetlen P2P kapcsolat létrehozásának kísérletéhez.

ICE jelölt típusok és STUN

Az ICE folyamatban három típusú jelölt létezik: host (helyi cím), srflx (server reflexive — STUN-tól származó) és relay (TURN-on keresztül továbbított). A STUN szerver biztosítja az srflx jelöltek megjelenését, amelyek magasabb prioritással rendelkeznek, mint a relay, mivel a STUN-on keresztüli kapcsolat közvetlen és nem igényel továbbítást. Az ICE folyamat ellenőrzi a jelöltek összes kombinációját (helyi és STUN-tól származó) mindkét fél esetében, a legmagasabb prioritásoktól kezdve.

A STUN protokoll korlátozásai

A STUN szerver alapvető korlátozásokkal rendelkezik, amelyek a protokoll architektúrájához kapcsolódnak. A fő korlátozás a Symmetric NAT-tal való működés képtelensége, amikor minden új kérés egy külső hosthoz egyedi külső portot kap. Ebben az esetben a STUN szervertől kapott cím nem használható egy másik partnerrel való kapcsolatra, mert a NAT csak a STUN szerverrel való kommunikációhoz hozott létre kötést.

A második korlátozás azzal kapcsolatos, hogy a STUN nem biztosít adattovábbítást. Ha a közvetlen P2P kapcsolat lehetetlen (mindkét fél Symmetric NAT mögött van), a STUN nem kínál alternatív útvonalat az adatok továbbításához. Ebben az esetben TURN szerverre van szükség, amely a felek közötti médiaforgalom továbbítójaként működik, fogadva az adatokat az egyik résztvevőtől és elküldve a másiknak a saját nyilvános IP-címén keresztül.

• Symmetric NAT — a STUN nem működik szimmetrikus NAT-tal, mert a külső cím egyedi minden célhosthoz és nem használható újra P2P-hez.
• Firewall Deep Packet Inspection — néhány tűzfal blokkolja a STUN forgalmat a protokoll aláírások alapján a 3478-as porton lévő UDP csomagokban.
• IPv6 — az IPv6 hálózatokban általában nem használnak NAT-ot, így a STUN nem szükséges, de a WebRTC IPv6-on host jelöltekkel is boldogulhat STUN vagy TURN nélkül.
• Függőség az elérhetőségtől — a STUN szervernek elérhetőnek kell lennie az ügyfél számára a kapcsolat létrehozásának szakaszában, ellenkező esetben az srflx jelöltek nem kerülnek összegyűjtésre.
• Biztonság — a STUN protokoll sebezhető az erősítési támadással (amplification attack) szemben, ha a szerver helytelenül van konfigurálva és hamis forráscímmel rendelkező kérésekre válaszol.

A korlátozások ellenére a STUN szerver a WebRTC infrastruktúra kritikus összetevője marad. A legtöbb esetben (80–90%) a közvetlen P2P kapcsolat létrehozható a STUN segítségével, ami lehetővé teszi a TURN továbbítási költségek elkerülését és csökkenti a médiaadatok továbbításának késleltetését. Nyilvános WebRTC alkalmazásokhoz ajánlott a STUN és TURN szerverek kombinációjának használata automatikus fallbackkel a kapcsolat garantálásához minden hálózati körülmények között.