STUN Server: bu nima, qanday ishlaydi va qayerda ishlatiladi

STUN Server nima

STUN Server (Session Traversal Utilities for NAT) — RFC 5389 da belgilangan va RFC 8489 da yangilangan protokol bo‘yicha ishlaydigan tarmoq xizmati. STUN serverining asosiy vazifasi mijozga uning tashqi tarmoqdan ko‘rinadigan o‘zining umumiy IP-manzili va porti haqida ma‘lumot berish, shuningdek, mijoz va internet o‘rtasidagi NAT qurilmasi turini aniqlashdir.

STUN arxitekturasi ikkita komponentni o‘z ichiga oladi: ilovaga o‘rnatilgan STUN mijoz (masalan, brauzer yoki native WebRTC ilovasi) va umumiy tarmoqda joylashgan STUN serveri. Mijoz serverga STUN Binding Request yuboradi, server javobida so‘rov manbaining IP-manzili va portini — ya‘ni server ko‘radigan mijozning umumiy manzillarini ko‘rsatadi. Ushbu ma‘lumotlarni lokal manzillar bilan taqqoslab, mijoz o‘z tarmog‘ida qanday NAT turi ishlatilayotganini aniqlay oladi.

STUN protokoli

STUN UDP (standart bo‘yicha 3478-port) yoki TCP (3478-port yoki TLS uchun 5349-port) orqali ishlaydi. STUN xabari 20 baytlik sarlavha va o‘zgaruvchan miqdordagi atributlardan iborat. Sarlavha xabar turini (Binding Request, Binding Response, Binding Error Response), uzunlikni va so‘rov va javoblarni moslashtirish imkonini beradigan noyob tranzaksiya identifikatorini (96 bit) o‘z ichiga oladi. Har bir Binding Response XOR-MAPPED-ADDRESS atributini — STUN trafigini tutib olishga asoslangan hujumlardan himoya qilish uchun maskalangan mijozning tashqi manzilini o‘z ichiga oladi.

STUN serveri qanday ishlaydi

STUN serveri oddiy so‘rov-javob protokoli asosida ishlaydi. NAT orqasida joylashgan mijoz Binding Request yaratadi va uni STUN serveriga yuboradi. Server paketni qabul qiladi, UDP sarlavhasidan manba IP-manzili va jo‘natuvchi portini chiqaradi, so‘ngra bu manzilni XOR-MAPPED-ADDRESS atributiga joylashtirib Binding Response yaratadi. Javob so‘rovning manba manziliga qaytariladi.

Mijoz javobni oladi va NAT qurilmasi tomonidan tayinlangan tashqi IP-manzil va portni o‘z ichiga olgan XOR-MAPPED-ADDRESS ni chiqaradi. So‘ngra mijoz bu manzilni o‘zining lokal (RFC 1919 — xususiy) manzili bilan taqqoslaydi. Agar manzillar mos kelsa — mijoz NAT orqasida emas. Agar farq qilsa — mijoz NAT orqasida va tashqi manzil WebRTC-da ICE (Interactive Connectivity Establishment) uchun nomzod sifatida ishlatiladi.

NATni aniqlash jarayoni (NAT Discovery)

STUN serveri test so‘rovlari ketma-ketligi orqali NAT turini aniqlash imkonini beradi. Mijoz turli bayroqlar (CHANGE-REQUEST) bilan so‘rovlar yuboradi va javoblarni tahlil qiladi. To‘liq aniqlash sikli STUN serverining turli IP-manzillari va portlariga so‘rovlar yuborishni o‘z ichiga oladi. Agar server o‘zgartirilgan port bilan so‘rovga javob bersa — NAT Restricted Cone turiga kiradi. Agar o‘zgartirilgan port va IP bilan so‘rovga javob bermasa — NAT Symmetric turiga kiradi. Ushbu ma‘lumot WebRTC-da ICE strategiyasini tanlash uchun juda muhimdir.

STUN serveri va NAT turlari

STUN serveri to‘rtta asosiy NAT turini aniqlay oladi, ularning har biri P2P ulanishini o‘rnatish imkoniyatiga turlicha ta‘sir qiladi. NAT turi STUN ikki mijoz o‘rtasida to‘g‘ridan-to‘g‘ri ulanishni ta‘minlay oladimi yoki yo‘qmi, buni aniqlaydi. Ulanish uchun qaysi ICE nomzodi — host, server reflexive yoki relay — ishlatilishi NAT turiga bog‘liq.

Symmetric NAT — STUN uddasidan chiqa olmaydigan yagona tur. Symmetric NAT-da har bir yangi so‘rov yangi maqsadli hostga boshqa tashqi manzil (IP va/yoki port) oladi. STUN serveri STUN serverining o‘zi bilan ulanish uchun manzilni bildirganligi sababli, bu manzil boshqa mijoz bilan ulanish uchun yaroqsiz. Bunday hollarda WebRTC-da trafikni uzatish uchun TURN serveri ishlatiladi. Tadqiqotlarga ko‘ra (Ford et al., RFC 3489, 2003), internetdagi barcha NAT qurilmalarining taxminan 8–10% simmetrikdir.

STUN serverini WebRTC-da qo‘llash

STUN serveri RTCPeerConnection konfiguratsiyasi orqali WebRTC-ga integratsiya qilinadi. Brauzer yoki native ilova ICE nomzodlarini yig‘ish uchun STUN-dan foydalanadi, so‘ngra ular Signaling Server orqali almashiniladi. WebRTC konfiguratsiyasida STUN serveri UDP uchun stun: prefiksi yoki TLS ulanishi uchun stuns: prefiksi bilan iceServers massivida ko‘rsatiladi.

WebRTC ilovasi uchun RTCPeerConnection yaratishda JavaScript-da STUN serverini sozlash misolini ko‘rib chiqaylik.

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

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

Ushbu misolda Google-ning umumiy STUN serverlari (stun.l.google.com:19302) ishlatiladi. Offer yoki answer yaratishda brauzer avtomatik ravishda ko‘rsatilgan serverlarga STUN Binding Request yuboradi, tashqi manzilni (server reflexive candidate) oladi va uni ICE nomzodlari ro‘yxatiga qo‘shadi. Barcha nomzodlar yig‘ilgandan so‘ng, to‘g‘ridan-to‘g‘ri P2P ulanishini o‘rnatishga harakat qilish uchun Signaling Server orqali uzoq tarafga yuboriladi.

ICE nomzod turlari va STUN

ICE jarayonida uch turdagi nomzod mavjud: host (lokal manzil), srflx (server reflexive — STUN-dan olingan) va relay (TURN orqali uzatilgan). STUN serveri relay-dan yuqoriroq prioritetga ega bo‘lgan srflx nomzodlarining paydo bo‘lishini ta‘minlaydi, chunki STUN orqali ulanish to‘g‘ridan-to‘g‘ri va uzatishni talab qilmaydi. ICE jarayoni ikkala tarafning barcha nomzod kombinatsiyalarini (lokal va STUN-dan olingan) eng yuqori prioritetlardan boshlab tekshiradi.

STUN protokoli cheklovlari

STUN serveri protokol arxitekturasi bilan bog‘liq fundamental cheklovlarga ega. Asosiy cheklov — Symmetric NAT bilan ishlay olmaslik, bunda har bir yangi so‘rov tashqi hostga noyob tashqi port oladi. Bu holda STUN serveridan olingan manzil boshqa taraf bilan ulanish uchun ishlatilmaydi, chunki NAT faqat STUN serverining o‘zi bilan aloqa qilish uchun bog‘lanish yaratgan.

Ikkinchi cheklov shundaki, STUN ma‘lumotlarni uzatishni ta‘minlamaydi. Agar to‘g‘ridan-to‘g‘ri P2P ulanishi imkonsiz bo‘lsa (ikkala taraf Symmetric NAT orqasida), STUN ma‘lumotlarni uzatish uchun muqobil yo‘l taklif qilmaydi. Bu holda TURN serveri talab qilinadi, u qatnashchilardan biridan ma‘lumotlarni qabul qilib, o‘zining umumiy IP-manzili orqali boshqasiga yuborib, media trafigining uzatuvchisi rolini o‘ynaydi.

• Symmetric NAT — STUN simmetrik NAT bilan ishlamaydi, chunki tashqi manzil har bir maqsadli host uchun noyob va P2P uchun qayta ishlatilmaydi.
• Firewall Deep Packet Inspection — ba‘zi firewall-lar 3478-portdagi UDP paketlarida protokol imzolari bo‘yicha STUN trafigini bloklaydi.
• IPv6 — IPv6 tarmoqlarida NAT odatda ishlatilmaydi, shuning uchun STUN talab qilinmaydi, lekin IPv6-dagi WebRTC STUN yoki TURN ga ehtiyoj sezmasdan host nomzodlari bilan cheklanishi mumkin.
• Mavjudligiga bog‘liqlik — STUN serveri ulanishni o‘rnatish bosqichida mijoz uchun mavjud bo‘lishi kerak, aks holda srflx nomzodlari yig‘ilmaydi.
• Xavfsizlik — STUN protokoli kuchaytirish hujumiga (amplification attack) moyil, agar server noto‘g‘ri sozlangan bo‘lsa va soxta manba manzili bilan so‘rovlarga javob bersa.

Cheklovlarga qaramay, STUN serveri WebRTC infratuzilmasining muhim komponenti bo‘lib qolmoqda. Ko‘p hollarda (80–90%) STUN yordamida to‘g‘ridan-to‘g‘ri P2P ulanishini o‘rnatish mumkin, bu TURN uzatish xarajatlaridan qochish va media ma‘lumotlarini uzatish kechikishini kamaytirish imkonini beradi. Umumiy WebRTC ilovalari uchun har qanday tarmoq sharoitida ulanishni kafolatlash uchun STUN va TURN serverlari kombinatsiyasini avtomatik fallback bilan ishlatish tavsiya etiladi.