STUN Server: bu nədir, necə işləyir və harada istifadə olunur

STUN Server nədir

STUN Server (Session Traversal Utilities for NAT) — RFC 5389-da müəyyən edilmiş və RFC 8489-da yeniləmiş protokol əsasında işləyən řəbəkə xidmətidir. STUN serverinin əsas vəzifəsi müştəriyə onun xarici řəbəkədən görünən öz ictimai IP ünvanı və portu haqqında məlumat vermək, həmçinin müştəri ilə internet arasındakı NAT cihazının növünü müəyyən etməkdir.

STUN arxitekturası iki komponentdən ibarətdir: tətbiqə daxil edilmiş STUN müştərisi (məsələn, brauzer və ya native WebRTC tətbiqi) və ictimai řəbəkədə yerləşdirilmiş STUN serveri. Müştəri serverə STUN Binding Request göndərir, server cavabında sorğun mənbə IP ünvanı və portunu — yəni serverin gördüyü müştərinin ictimai ünvanlarını göstərir. Bu məlumatları lokal ünvanlarla müqayisə edərək, müştəri řəbəkəsində hansı NAT növünün istifadə olunduğunu müəyyən edə bilər.

STUN protokolu

STUN UDP (standart olaraq port 3478) və ya TCP (port 3478 və ya TLS üçün 5349) üzərində işləyir. STUN mesajı 20 baytlıq başlıq və dəyişən sayda atributlardan ibarətdir. Başlıq mesaj növünü (Binding Request, Binding Response, Binding Error Response), uzunluğu və sorğu və cavabı uyğurlamağa imkan verən unikal transaksiya identifikatorunu (96 bit) ehtiva edir. Hər bir Binding Response XOR-MAPPED-ADDRESS atributunu — STUN trafikinin tutulmasına əsaslanan hücumlardan qorunmaq üçün maskalanaraq kodlanmış müştərinin xarici ünvanını ehtiva edir.

STUN serveri necə işləyir

STUN serveri sadə sorğu-cavab protokolu əsasında işləyir. NAT arxasında olan müştəri Binding Request yaradır və onu STUN serverinə göndərir. Server paketi qəbul edir, UDP başlığından mənbə IP ünvanını və göndərən portunu çıxarır, sonra bu ünvanı XOR-MAPPED-ADDRESS atributuna yerləşdirərək Binding Response yaradır. Cavab sorğun mənbə ünvanına geri göndərilir.

Müştəri cavabı alır və NAT cihazı tərəfindən təyin edilmiş xarici IP ünvanı və portu ehtiva edən XOR-MAPPED-ADDRESS-i çıxarır. Sonra müştəri bu ünvanı öz lokal (RFC 1919 — özəl) ünvanı ilə müqayisə edir. Ünvanlar uyğun gəlirsə — müştəri NAT arxasında deyil. Fərqlənirsə — müştəri NAT arxasındadır və xarici ünvan WebRTC-də ICE (Interactive Connectivity Establishment) üçün namizəd kimi istifadə olunur.

NAT aşkarlanması prosesi (NAT Discovery)

STUN serveri test sorğuları ardıcıllığı vasitəsilə NAT növünü müəyyən etməyə imkan verir. Müştəri müxtəlif bayraqlarla (CHANGE-REQUEST) sorğular göndərir və cavabları təhlil edir. Tam aşkarlanma dövriyyəsi STUN serverinin müxtəlif IP ünvanlarına və portlarına sorğular göndərməyi əhatə edir. Server dəyişdirilmiş portla sorğa cavab verirsə — NAT Restricted Cone növünə aiddir. Dəyişdirilmiş port və IP ilə sorğa cavab vermirsə — NAT Symmetric növünə aiddir. Bu məlumat WebRTC-də ICE strategiyasının seçilməsi üçün kritik əhəmiyyət kəsb edir.

STUN serveri və NAT növləri

STUN serveri dörd əsas NAT növünü müəyyən edə bilir, onların hər biri P2P əlaqəsi qurma qabiliyyətinə fərqli təsir göstərir. NAT növü STUN-un iki müştəri arasında birbaşa əlaqəni təmin edib-edə bilməyəcəyini müəyyən edir. Əlaqə üçün hansı ICE namizədinin — host, server reflexive və ya relay — istifadə olunacağı NAT növündən asılıdır.

Symmetric NAT — STUN-un öhdəsindən gələ bilmədiyi yeganı növdür. Symmetric NAT-da hər yeni sorğu yeni hədəf hosta fərqli xarici ünvan (IP və/yaxud port) alır. STUN serveri STUN serverinin özüylə əlaqə üçün ünvanı bildirdiyindən, bu ünvan başqa bir müştəri ilə əlaqə üçün yararsızdır. Belə hallarda WebRTC-də trafiki ötürmək üçün TURN serveri istifadə olunur. Tədqiqatlara görə (Ford et al., RFC 3489, 2003), internetdəki bütün NAT cihazlarının təxminən 8–10%-i simmetrikdir.

STUN serverinin WebRTC-də istifadəsi

STUN serveri RTCPeerConnection konfiqurasiyası vasitəsilə WebRTC-yə inteqrasiya olunur. Brauzer və ya native tətbiq ICE namizədlərini toplamaq üçün STUN-dan istifadə edir, sonra onlar Signaling Server vasitəsilə mübadilə olunur. WebRTC konfiqurasiyasında STUN serveri UDP üçün stun: prefiksi və ya TLS əlaqəsi üçün stuns: prefiksi ilə iceServers massivində göstərilir.

WebRTC tətbiqi üçün RTCPeerConnection yaradılarkən JavaScript-də STUN serverinin konfiqurasiya nümunəsini nəzərdən keçirək.

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

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

Bu nümunədə Google-un ictimai STUN serverləri (stun.l.google.com:19302) istifadə olunur. Offer və ya answer yaradılarkən brauzer avtomatik olaraq göstərilən serverlərə STUN Binding Request göndərir, xarici ünvanı (server reflexive candidate) alır və onu ICE namizədləri siyahısına əlavə edir. Bütün namizədlər toplandıqdan sonra birbaşa P2P əlaqəsi qurmaq cəhdi üçün Signaling Server vasitəsilə uzaq tərəfə göndərilir.

ICE namizəd növləri və STUN

ICE prosesində üç növ namizəd var: host (lokal ünvan), srflx (server reflexive — STUN-dan alınmış) və relay (TURN vasitəsilə ötürülən). STUN serveri relay-dən daha yüksək prioritetə malik srflx namizədlərinin yaranmasını təmin edir, çünki STUN vasitəsilə əlaqə birbaşadır və ötürmə tələb etmir. ICE prosesi hər iki tərəfin bütün namizəd kombinasiyalarını (lokal və STUN-dan alınmış) yüksək prioritetlərdən başlayaraq yoxlayır.

STUN protokolunun məhdudiyyətləri

STUN serveri protokol arxitekturası ilə əlaqəli fundamental məhdudiyyətlərə malikdir. Əsas məhdudiyyət Symmetric NAT ilə işləyə bilməməsidi, burada hər yeni sorğu xarici hosta unikal xarici port alır. Bu halda STUN serverindən alınan ünvan başqa bir tərəflə əlaqə üçün istifadə edilə bilməz, çünki NAT yalnız STUN serverinin özüylə əlaqə üçün bağlantı yaratmışdır.

İkinci məhdudiyyət onunla əlaqəlidir ki, STUN məlumatların ötürülməsini təmin etmir. Birbaşa P2P əlaqəsi mümkün deyilsə (hər iki tərəf Symmetric NAT arxasındadırsa), STUN məlumatların ötürülməsi üçün alternativ yol təqdim etmir. Bu halda TURN serveri tələb olunur, o, iştirakçılardan birindən məlumatları qəbul edib öz ictimai IP ünvanı vasitəsilə digərinə göndərərək media trafikinin ötürücüsü rolunu oynayır.

• Symmetric NAT — STUN simmetrik NAT ilə işləmir, çünki xarici ünvan hər hədəf host üçün unikaldır və P2P üçün təkrar istifadə edilə bilməz.
• Firewall Deep Packet Inspection — bəzi firewall-lar 3478 portunda UDP paketlərində protokol imzalarına görə STUN trafikini bloklayır.
• IPv6 — IPv6 řəbəkələrində NAT adətən istifadə olunmur, buna görə STUN tələb olunmur, lakin IPv6 üzərində WebRTC STUN və ya TURN-a ehtiyac olmadan host namizədləri ilə kifayətlənə bilər.
• Ələqədarlıqdan asılılıq — STUN serveri əlaqə qurma mərhələsində müştəri üçün əlçatan olmalıdır, əks halda srflx namizədləri toplanmayacaq.
• Təhlükəsizlik — STUN protokolu gücləndirmə hücumuna (amplification attack) qarşı həssasdır, əgər server düzgün konfiqurasiya edilməyibsə və saxta mənbə ünvanı ilə sorğulata cavab verirsə.

Məhdudiyyətlərə baxmayaraq, STUN serveri WebRTC infrastrukturunun vacib komponenti olaraq qalır. Əksər hallarda (80–90%) STUN köməyi ilə birbaşa P2P əlaqəsi qurmaq mümkündür, bu da TURN ötürmə xərclərindən qaçmağa və media məlumatlarının ötürülmə gecikməsini azaltmağa imkan verir. İctimai WebRTC tətbiqləri üçün istənilən řəbəkə şəraitində əlaqəni təmin etmək üçün STUN və TURN serverlərinin kombinasiyasını avtomatik fallback ilə istifadə etmək tövsiyə olunur.