STUN Server: apa itu, cara kerja dan di mana digunakan

Apa itu STUN Server

STUN Server (Session Traversal Utilities for NAT) — adalah layanan jaringan yang beroperasi berdasarkan protokol yang didefinisikan dalam RFC 5389 dan diperbarui dalam RFC 8489. Tugas utama server STUN adalah memberikan informasi kepada klien tentang alamat IP publik dan port-nya sendiri yang terlihat dari jaringan eksternal, serta menentukan jenis perangkat NAT antara klien dan internet.

Arsitektur STUN mencakup dua komponen: klien STUN yang tertanam dalam aplikasi (misalnya, browser atau aplikasi WebRTC native) dan server STUN yang ditempatkan di jaringan publik. Klien mengirim STUN Binding Request ke server, yang dalam responsnya menunjukkan alamat IP dan port sumber permintaan — yaitu alamat publik klien yang dilihat oleh server. Dengan membandingkan data ini dengan alamat lokal, klien dapat menentukan jenis NAT apa yang digunakan di jaringannya.

Protokol STUN

STUN bekerja melalui UDP (port 3478 secara default) atau TCP (port 3478 atau 5349 untuk TLS). Pesan STUN terdiri dari header 20-byte dan sejumlah atribut yang bervariasi. Header berisi jenis pesan (Binding Request, Binding Response, Binding Error Response), panjang, dan pengidentifikasi transaksi unik (96 bit) yang memungkinkan pencocokan permintaan dan respons. Setiap Binding Response berisi atribut XOR-MAPPED-ADDRESS — alamat eksternal klien, yang dikodekan dengan masking untuk melindungi dari serangan berdasarkan penyadapan lalu lintas STUN.

Cara kerja server STUN

Server STUN bekerja berdasarkan protokol permintaan-respons sederhana. Klien yang berada di belakang NAT membentuk Binding Request dan mengirimkannya ke server STUN. Server menerima paket, mengekstrak dari header UDP alamat IP sumber dan port pengirim, kemudian membentuk Binding Response dengan mengemas alamat ini ke dalam atribut XOR-MAPPED-ADDRESS. Respons dikirim kembali ke alamat sumber permintaan.

Klien menerima respons dan mengekstrak XOR-MAPPED-ADDRESS, yang berisi alamat IP eksternal dan port yang ditetapkan oleh perangkat NAT. Kemudian klien membandingkan alamat ini dengan alamat lokalnya (RFC 1919 — privat). Jika alamat cocok — klien tidak berada di belakang NAT. Jika berbeda — klien berada di belakang NAT, dan alamat eksternal digunakan sebagai kandidat untuk ICE (Interactive Connectivity Establishment) di WebRTC.

Proses Deteksi NAT (NAT Discovery)

Server STUN memungkinkan penentuan jenis NAT melalui serangkaian permintaan uji. Klien mengirim permintaan dengan berbagai flag (CHANGE-REQUEST) dan menganalisis respons. Siklus deteksi lengkap mencakup pengiriman permintaan ke berbagai alamat IP dan port server STUN. Jika server merespons permintaan dengan port yang diubah — NAT jenis Restricted Cone. Jika tidak merespons permintaan dengan port dan IP yang diubah — NAT jenis Symmetric. Informasi ini sangat penting untuk pemilihan strategi ICE di WebRTC.

Server STUN dan jenis NAT

Server STUN mampu menentukan empat jenis utama NAT, yang masing-masing mempengaruhi kemungkinan pembentukan koneksi P2P secara berbeda. Jenis NAT menentukan apakah STUN dapat menyediakan koneksi langsung antara dua klien. Dari jenis NAT tergantung kandidat ICE mana — host, server reflexive, atau relay — yang akan digunakan untuk koneksi.

Symmetric NAT — satu-satunya jenis yang tidak dapat diatasi oleh STUN. Pada Symmetric NAT, setiap permintaan baru ke host tujuan baru mendapatkan alamat eksternal yang berbeda (IP dan/atau port). Karena server STUN melaporkan alamat untuk koneksi dengan server STUN itu sendiri, alamat ini tidak dapat digunakan untuk koneksi dengan klien lain. Dalam kasus seperti itu, di WebRTC digunakan server TURN untuk meneruskan lalu lintas. Menurut penelitian (Ford et al., RFC 3489, 2003), sekitar 8–10% dari semua perangkat NAT di internet bersifat simetris.

Penggunaan server STUN di WebRTC

Server STUN diintegrasikan ke dalam WebRTC melalui konfigurasi RTCPeerConnection. Browser atau aplikasi native menggunakan STUN untuk mengumpulkan kandidat ICE, yang kemudian dipertukarkan melalui Signaling Server. Dalam konfigurasi WebRTC, server STUN ditentukan dalam array iceServers dengan awalan stun: untuk UDP atau stuns: untuk koneksi TLS.

Mari kita lihat contoh konfigurasi server STUN di JavaScript saat membuat RTCPeerConnection untuk aplikasi WebRTC.

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

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

Dalam contoh ini, server STUN publik Google (stun.l.google.com:19302) digunakan. Saat membuat offer atau answer, browser secara otomatis mengirim STUN Binding Request ke server yang ditentukan, menerima alamat eksternal (server reflexive candidate) dan menambahkannya ke daftar kandidat ICE. Setelah semua kandidat terkumpul, mereka dikirim ke mitra jarak jauh melalui Signaling Server untuk mencoba membuat koneksi P2P langsung.

Jenis Kandidat ICE dan STUN

Dalam proses ICE ada tiga jenis kandidat: host (alamat lokal), srflx (server reflexive — diperoleh dari STUN) dan relay (diteruskan melalui TURN). Server STUN memastikan munculnya kandidat srflx, yang memiliki prioritas lebih tinggi daripada relay, karena koneksi melalui STUN bersifat langsung dan tidak memerlukan penerusan. Proses ICE memeriksa semua kombinasi kandidat (lokal dan diperoleh dari STUN) dari kedua pihak, dimulai dari prioritas tertinggi.

Keterbatasan protokol STUN

Server STUN memiliki keterbatasan fundamental terkait arsitektur protokol. Keterbatasan utama adalah ketidakmampuan bekerja dengan Symmetric NAT, di mana setiap permintaan baru ke host eksternal mendapatkan port eksternal yang unik. Dalam hal ini, alamat yang diperoleh dari server STUN tidak dapat digunakan untuk koneksi dengan mitra lain, karena NAT telah membuat ikatan hanya untuk komunikasi dengan server STUN itu sendiri.

Keterbatasan kedua terkait dengan fakta bahwa STUN tidak menyediakan penerusan data. Jika koneksi P2P langsung tidak memungkinkan (kedua pihak berada di belakang Symmetric NAT), STUN tidak menyediakan jalur alternatif untuk transmisi data. Dalam hal ini diperlukan server TURN, yang bertindak sebagai penerus lalu lintas media antara pihak, menerima data dari satu peserta dan mengirimkannya ke peserta lain melalui alamat IP publiknya.

• Symmetric NAT — STUN tidak bekerja dengan NAT simetris, karena alamat eksternal unik untuk setiap host tujuan dan tidak dapat digunakan kembali untuk P2P.
• Firewall Deep Packet Inspection — beberapa firewall memblokir lalu lintas STUN dengan mendeteksinya berdasarkan tanda tangan protokol dalam paket UDP pada port 3478.
• IPv6 — di jaringan IPv6, NAT biasanya tidak digunakan, sehingga STUN tidak diperlukan, tetapi WebRTC di IPv6 dapat menggunakan kandidat host tanpa perlu STUN atau TURN.
• Ketergantungan pada ketersediaan — server STUN harus dapat diakses oleh klien pada tahap pembentukan koneksi, jika tidak kandidat srflx tidak akan terkumpul.
• Keamanan — protokol STUN rentan terhadap serangan amplifikasi (amplification attack) jika server dikonfigurasi dengan tidak benar dan merespons permintaan dengan alamat sumber palsu.

Meskipun memiliki keterbatasan, server STUN tetap menjadi komponen penting infrastruktur WebRTC. Dalam sebagian besar kasus (80–90%), koneksi P2P langsung dapat dibuat dengan bantuan STUN, yang memungkinkan menghindari biaya penerusan TURN dan mengurangi latensi transmisi data media. Untuk aplikasi WebRTC publik, disarankan menggunakan kombinasi server STUN dan TURN dengan fallback otomatis untuk menjamin koneksi dalam segala kondisi jaringan.