STUN Server: ano ito, paano ito gumagana at saan ginagamit

Ano ang STUN Server

STUN Server (Session Traversal Utilities for NAT) — ay isang serbisyo sa network na gumagana ayon sa protocol na tinukoy sa RFC 5389 at na-update sa RFC 8489. Ang pangunahing gawain ng STUN server ay magbigay sa client ng impormasyon tungkol sa kanyang sariling pampublikong IP address at port na nakikita mula sa panlabas na network, pati na rin matukoy ang uri ng NAT device sa pagitan ng client at internet.

Ang arkitektura ng STUN ay may dalawang bahagi: STUN client na naka-embed sa application (halimbawa, browser o native na WebRTC application) at STUN server na inilagay sa pampublikong network. Ang client ay nagpapadala ng STUN Binding Request sa server, na sa tugon ay nagpapahiwatig ng IP address at port ng pinagmulan ng request — iyon ay, ang mga pampublikong address ng client na nakikita ng server. Sa pamamagitan ng paghahambing ng mga data na ito sa mga lokal na address, matutukoy ng client kung anong uri ng NAT ang ginagamit sa kanyang network.

STUN Protocol

STUN ay gumagana sa pamamagitan ng UDP (port 3478 bilang default) o TCP (port 3478 o 5349 para sa TLS). Ang STUN message ay binubuo ng 20-byte na header at variable na bilang ng mga attribute. Ang header ay naglalaman ng uri ng mensahe (Binding Request, Binding Response, Binding Error Response), haba, at natatanging transaction identifier (96 bits) na nagpapahintulot sa pagtutugma ng mga request at response. Ang bawat Binding Response ay naglalaman ng attribute na XOR-MAPPED-ADDRESS — ang panlabas na address ng client, na naka-encode na may masking para sa proteksyon laban sa mga pag-atake batay sa pagharang ng STUN traffic.

Paano gumagana ang STUN server

Ang STUN server ay gumagana ayon sa simpleng request-response protocol. Ang client na nasa likod ng NAT ay bumubuo ng Binding Request at ipinapadala ito sa STUN server. Tinatanggap ng server ang packet, kinukuha mula sa UDP header ang source IP address at port ng nagpadala, pagkatapos ay bumubuo ng Binding Response sa pamamagitan ng pag-empake ng address na ito sa attribute na XOR-MAPPED-ADDRESS. Ang tugon ay ibinabalik sa source address ng request.

Tinatanggap ng client ang tugon at kinukuha ang XOR-MAPPED-ADDRESS, na naglalaman ng panlabas na IP address at port na itinalaga ng NAT device. Pagkatapos ay inihahambing ng client ang address na ito sa kanyang lokal (RFC 1919 — pribadong) address. Kung magkatugma ang mga address — ang client ay wala sa likod ng NAT. Kung magkaiba — ang client ay nasa likod ng NAT, at ang panlabas na address ay ginagamit bilang kandidato para sa ICE (Interactive Connectivity Establishment) sa WebRTC.

Proseso ng Pagtuklas ng NAT (NAT Discovery)

Ang STUN server ay nagbibigay-daan sa pagtukoy ng uri ng NAT sa pamamagitan ng isang serye ng mga test request. Ang client ay nagpapadala ng mga request na may iba't ibang flag (CHANGE-REQUEST) at sinusuri ang mga tugon. Ang buong cycle ng pagtuklas ay kinabibilangan ng pagpapadala ng mga request sa iba't ibang IP address at port ng STUN server. Kung ang server ay tumugon sa isang request na may binagong port — NAT ng uri Restricted Cone. Kung hindi tumugon sa request na may binagong port at IP — NAT ng uri Symmetric. Ang impormasyong ito ay kritikal para sa pagpili ng ICE strategy sa WebRTC.

STUN server at mga uri ng NAT

Ang STUN server ay may kakayahang matukoy ang apat na pangunahing uri ng NAT, na ang bawat isa ay may iba't ibang epekto sa posibilidad ng pagtatatag ng P2P na koneksyon. Ang uri ng NAT ay tumutukoy kung ang STUN ay maaaring magbigay ng direktang koneksyon sa pagitan ng dalawang client. Depende sa uri ng NAT kung aling ICE candidate — host, server reflexive o relay — ang gagamitin para sa koneksyon.

Symmetric NAT — ang tanging uri na hindi kayang hawakan ng STUN. Sa Symmetric NAT, ang bawat bagong request sa bagong target na host ay nakakakuha ng ibang panlabas na address (IP at/o port). Dahil ang STUN server ay nag-uulat ng address para sa koneksyon sa STUN server mismo, ang address na ito ay hindi magagamit para sa koneksyon sa ibang client. Sa mga ganitong kaso, sa WebRTC ay ginagamit ang TURN server para sa pag-relay ng trapiko. Ayon sa pananaliksik (Ford et al., RFC 3489, 2003), humigit-kumulang 8–10% ng lahat ng NAT device sa internet ay simetriko.

Paggamit ng STUN server sa WebRTC

Ang STUN server ay isinasama sa WebRTC sa pamamagitan ng configuration ng RTCPeerConnection. Ang browser o native na application ay gumagamit ng STUN para sa pagkolekta ng mga ICE candidate, na pagkatapos ay ipinagpapalit sa pamamagitan ng Signaling Server. Sa configuration ng WebRTC, ang STUN server ay tinutukoy sa array na iceServers na may prefix na stun: para sa UDP o stuns: para sa TLS connection.

Tingnan natin ang isang halimbawa ng pag-configure ng STUN server sa JavaScript kapag gumagawa ng RTCPeerConnection para sa isang WebRTC application.

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("Kandidato sa ICE:", event.candidate.candidate);
    }
};

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

Sa halimbawang ito, ginagamit ang mga pampublikong STUN server ng Google (stun.l.google.com:19302). Kapag gumagawa ng offer o answer, awtomatikong nagpapadala ang browser ng STUN Binding Request sa mga tinukoy na server, natatanggap ang panlabas na address (server reflexive candidate) at idinadagdag ito sa listahan ng mga ICE candidate. Pagkatapos makolekta ang lahat ng kandidato, ipinapadala sila sa malayong partner sa pamamagitan ng Signaling Server para subukang magtatag ng direktang P2P na koneksyon.

Mga Uri ng ICE Candidate at STUN

Sa proseso ng ICE, may tatlong uri ng kandidato: host (lokal na address), srflx (server reflexive — nakuha mula sa STUN) at relay (na-relay sa pamamagitan ng TURN). Tinitiyak ng STUN server ang paglitaw ng mga srflx na kandidato, na may mas mataas na priyoridad kaysa sa relay, dahil ang koneksyon sa pamamagitan ng STUN ay direkta at hindi nangangailangan ng relay. Sinusuri ng ICE process ang lahat ng kombinasyon ng mga kandidato (lokal at nakuha mula sa STUN) ng parehong partido, simula sa pinakamataas na priyoridad.

Mga limitasyon ng STUN protocol

Ang STUN server ay may mga pangunahing limitasyon na nauugnay sa arkitektura ng protocol. Ang pangunahing limitasyon ay ang kawalan ng kakayahang gumana sa Symmetric NAT, kung saan ang bawat bagong request sa panlabas na host ay nakakakuha ng natatanging panlabas na port. Sa kasong ito, ang address na nakuha mula sa STUN server ay hindi maaaring gamitin para sa koneksyon sa ibang partner, dahil ang NAT ay lumikha ng binding para lamang sa komunikasyon sa STUN server mismo.

Ang pangalawang limitasyon ay nauugnay sa katotohanan na ang STUN ay hindi nagbibigay ng relay ng data. Kung ang direktang P2P na koneksyon ay imposible (parehong partido ay nasa likod ng Symmetric NAT), ang STUN ay hindi nagbibigay ng alternatibong landas para sa paghahatid ng data. Sa kasong ito, kinakailangan ang TURN server, na kumikilos bilang relay ng media traffic sa pagitan ng mga partido, tumatanggap ng data mula sa isang kalahok at ipinapadala ito sa isa pa sa pamamagitan ng kanyang pampublikong IP address.

• Symmetric NAT — hindi gumagana ang STUN sa symmetric NAT, dahil ang panlabas na address ay natatangi para sa bawat target na host at hindi maaaring magamit muli para sa P2P.
• Firewall Deep Packet Inspection — ang ilang firewall ay humaharang sa STUN traffic sa pamamagitan ng pag-detect nito batay sa mga protocol signature sa UDP packets sa port 3478.
• IPv6 — sa mga IPv6 network, ang NAT ay karaniwang hindi ginagamit, kaya hindi kinakailangan ang STUN, ngunit ang WebRTC sa IPv6 ay maaaring gumamit ng host candidates nang hindi nangangailangan ng STUN o TURN.
• Pag-asa sa pagkakaroon — ang STUN server ay dapat na ma-access ng client sa yugto ng pagtatatag ng koneksyon, kung hindi, ang mga srflx candidate ay hindi makokolekta.
• Seguridad — ang STUN protocol ay mahina sa amplification attack kung ang server ay hindi wastong na-configure at tumugon sa mga request na may pekeng source address.

Sa kabila ng mga limitasyon, ang STUN server ay nananatiling kritikal na bahagi ng imprastraktura ng WebRTC. Sa karamihan ng mga kaso (80–90%), ang direktang P2P na koneksyon ay maaaring maitatag sa tulong ng STUN, na nagpapahintulot na maiwasan ang mga gastos sa TURN relay at mabawasan ang latency ng paghahatid ng media data. Para sa mga pampublikong WebRTC application, inirerekomenda na gumamit ng kombinasyon ng STUN at TURN server na may automatic fallback para sa garantiya ng koneksyon sa lahat ng kondisyon ng network.