STUN Server: nedir, nasıl çalışır ve nerede kullanılır

STUN Sunucusu Nedir

STUN Server (Session Traversal Utilities for NAT), RFC 5389'da tanımlanan ve RFC 8489'da güncellenen protokole göre çalışan bir ağ hizmetidir. Bir STUN sunucusunun temel görevi, istemciye dış ağdan göründüğü şekilde kendi genel IP adresi ve portu hakkında bilgi sağlamak ve ayrıca istemci ile internet arasındaki NAT cihazının türünü belirlemektir.

STUN mimarisi iki bileşen içerir: uygulamaya gömülü bir STUN istemcisi (örneğin bir tarayıcı veya yerel WebRTC uygulaması) ve genel ağda dağıtılan bir STUN sunucusu. İstemci sunucuya bir Binding Request gönderir, sunucu yanıtında isteğin kaynak IP adresini ve portunu — yani sunucunun gördüğü şekilde istemcinin genel adreslerini — belirtir. Bu verileri kendi yerel adresleriyle karşılaştırarak istemci, ağında hangi NAT türünün kullanıldığını belirleyebilir.

STUN Protokolü

STUN, UDP (varsayılan olarak port 3478) veya TCP (port 3478 veya TLS için 5349) üzerinde çalışır. Bir STUN mesajı, 20 baytlık bir başlık ve değişken sayıda özellikten oluşur. Başlık, mesaj türünü (Binding Request, Binding Response, Binding Error Response), uzunluğu ve istekleri ve yanıtları eşleştirmeye olanak tanıyan benzersiz bir işlem tanımlayıcısını (96 bit) içerir. Her Binding Response, STUN trafiği engellemesine dayalı saldırılara karşı korumak için maskeleme ile kodlanmış XOR-MAPPED-ADDRESS özelliğini — istemcinin harici adresini — içerir.

STUN Sunucusu Nasıl Çalışır

Bir STUN sunucusu basit bir istek-yanıt protokolüyle çalışır. NAT arkasındaki istemci bir Binding Request oluşturur ve STUN sunucusuna gönderir. Sunucu paketi alır, UDP başlığından kaynak IP adresini ve gönderenin portunu çıkarır, ardından bu adresi XOR-MAPPED-ADDRESS özelliğinde paketleyerek bir Binding Response oluşturur. Yanıt, isteğin kaynak adresine geri gönderilir.

İstemci yanıtı alır ve NAT cihazı tarafından atanan harici IP adresini ve portu içeren XOR-MAPPED-ADDRESS'i çıkarır. Ardından istemci bu adresi kendi yerel (RFC 1919 — özel) adresiyle karşılaştırır. Adresler eşleşirse — istemci NAT arkasında değildir. Farklıysa — istemci NAT arkasındadır ve harici adres WebRTC'de ICE (Etkileşimli Bağlantı Kurulumu) için bir aday olarak kullanılır.

NAT Keşif Süreci

Bir STUN sunucusu, bir dizi test isteği aracılığıyla NAT türünün belirlenmesine olanak tanır. İstemci farklı bayraklarla (CHANGE-REQUEST) istekler gönderir ve yanıtları analiz eder. Tam keşif döngüsü, STUN sunucusunun farklı IP adreslerine ve portlarına istek göndermeyi içerir. Sunucu değiştirilmiş bir portla isteğe yanıt verirse — NAT Restricted Cone türündedir. Değiştirilmiş port ve IP ile isteğe yanıt vermezse — NAT Symmetric türündedir. Bu bilgi, WebRTC'de ICE stratejisini seçmek için kritiktir.

STUN Sunucusu ve NAT Türleri

Bir STUN sunucusu dört ana NAT türünü tespit edebilir ve her biri bir P2P bağlantısı kurma yeteneğini farklı şekilde etkiler. NAT türü, STUN'un iki istemci arasında doğrudan bağlantıya izin verip veremeyeceğini belirler. Ayrıca bağlantı için hangi ICE adayının — host, server reflexive veya relay — kullanılacağını da belirler.

Symmetric NAT, STUN'un başa çıkamadığı tek türdür. Symmetric NAT ile yeni bir hedef sunucuya yapılan her yeni istek farklı bir harici adres (IP ve/veya port) alır. STUN sunucusu, STUN sunucusunun kendisine olan bağlantı için adresi bildirdiğinden, bu adres başka bir istemciye bağlanmak için uygun değildir. Bu gibi durumlarda WebRTC, trafiği aktarmak için bir TURN sunucusu kullanır. Araştırmaya göre (Ford ve diğerleri, RFC 3489, 2003), internetteki tüm NAT cihazlarının yaklaşık %8–10'u simetriktir.

WebRTC'de STUN Sunucusu Kullanımı

Bir STUN sunucusu, RTCPeerConnection yapılandırması aracılığıyla WebRTC'ye entegre edilir. Bir tarayıcı veya yerel uygulama, ICE adaylarını toplamak için STUN kullanır ve bunlar daha sonra Signaling Server aracılığıyla değiştirilir. WebRTC yapılandırmasında, STUN sunucusu iceServers dizisinde UDP için stun: öneki veya TLS bağlantıları için stuns: ile belirtilir.

Bir WebRTC uygulaması için RTCPeerConnection oluştururken JavaScript'te bir STUN sunucusu yapılandırması örneğini inceleyelim.

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

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

Bu örnek, Google'ın genel STUN sunucularını kullanır (stun.l.google.com:19302). Bir offer veya answer oluştururken, tarayıcı otomatik olarak belirtilen sunuculara bir STUN Binding Request gönderir, harici adresi (server reflexive adayı) alır ve bunu ICE adayları listesine ekler. Tüm adaylar toplandıktan sonra, doğrudan P2P bağlantısı kurma girişimi için Signaling Server aracılığıyla uzak eşe gönderilirler.

ICE Aday Türleri ve STUN

ICE sürecinde üç tür aday vardır: host (yerel adres), srflx (server reflexive — STUN'dan alınan) ve relay (TURN aracılığıyla aktarılan). STUN sunucusu, relay adaylarından daha yüksek önceliğe sahip srflx adaylarının oluşturulmasını sağlar çünkü STUN tabanlı bağlantı doğrudandır ve aktarım gerektirmez. ICE süreci, her iki eşin tüm aday kombinasyonlarını (yerel ve STUN'dan alınan) en yüksek önceliklerden başlayarak kontrol eder.

STUN Protokolünün Sınırlamaları

Bir STUN sunucusunun protokol mimarisiyle ilgili temel sınırlamaları vardır. Ana sınırlama, harici bir sunucuya yapılan her yeni isteğin benzersiz bir harici port aldığı Symmetric NAT ile çalışamamasıdır. Bu durumda, STUN sunucusundan alınan adres, NAT yalnızca STUN sunucusunun kendisiyle iletişim için bir bağlama oluşturduğundan, başka bir eşe bağlanmak için kullanılamaz.

İkinci sınırlama, STUN'un veri aktarımı sağlamamasıdır. Doğrudan P2P bağlantısı mümkün değilse (her iki eş Symmetric NAT arkasında), STUN veri iletimi için alternatif bir yol sunmaz. Bu durumda, eşler arasında medya trafiği rölesi olarak görev yapan, bir katılımcıdan veri alan ve bunu genel IP adresi aracılığıyla bir başkasına gönderen bir TURN sunucusu gerekir.

• Symmetric NAT — STUN simetrik NAT ile çalışmaz çünkü harici adres her hedef sunucu için benzersizdir ve P2P için yeniden kullanılamaz.
• Güvenlik Duvarı Derin Paket İncelemesi — bazı güvenlik duvarları, 3478 portundaki UDP paketlerinde protokol imzalarını tespit ederek STUN trafiğini engeller.
• IPv6 — IPv6 ağlarında NAT genellikle kullanılmaz, bu nedenle STUN gerekli değildir, ancak IPv6 üzerinde WebRTC, STUN veya TURN gerektirmeden host adaylarını kullanabilir.
• Kullanılabilirliğe bağımlılık — STUN sunucusu, bağlantı kurulum aşamasında istemci tarafından erişilebilir olmalıdır, aksi takdirde srflx adayları toplanmaz.
• Güvenlik — STUN protokolü, sunucu yanlış yapılandırılmışsa ve sahte kaynak adresli isteklere yanıt veriyorsa, amplifikasyon saldırılarına karşı savunmasızdır.

Sınırlamalara rağmen, bir STUN sunucusu WebRTC altyapısının kritik bir bileşeni olmaya devam etmektedir. Çoğu durumda (%80–90), STUN kullanılarak doğrudan bir P2P bağlantısı kurulabilir, bu da TURN aktarım maliyetlerinden kaçınır ve medya verisi iletim gecikmesini azaltır. Genel WebRTC uygulamaları için, herhangi bir ağ koşulunda bağlantıyı garanti etmek amacıyla otomatik yedeklemeli STUN ve TURN sunucularının bir kombinasyonunun kullanılması önerilir.