STUN Server: چیست، چگونه کار می‌کند و کجا استفاده می‌شود

STUN Server چیست

STUN Server (Session Traversal Utilities for NAT) — یک خدمات شبکه است که بر اساس پروتکل تعریف شده در RFC 5389 و به‌روزرسانی شده در RFC 8489 کار می‌کند. وظیفه اصلی سرور STUN ارائه اطلاعاتی درباره آدرس IP عمومی و پورت مشتری که از شبکه خارجی قابل مشاهده است و نیز تعیین نوع دستگاه NAT بین مشتری و اینترنت است.

معماری STUN شامل دو ماژول است: مشتری STUN به کار رفته در نرم‌افزار (مانند مرورگر یا نرم‌افزار ماتیوی WebRTC) و سرور STUN مستقر در شبکه عمومی. مشتری یک STUN Binding Request به سرور ارسال می‌کند، سرور در پاسخ آدرس IP و پورت منبع درخواست را — یعنی آدرس‌های عمومی مشتری که سرور می‌بیند را مشخص می‌کند. با مقایسه این داده‌ها با آدرس‌های محلی، مشتری می‌تواند تعیین کند که چه نوع NAT در شبکه او استفاده می‌شود.

پروتکل STUN

STUN بر روی UDP (پورت 3478 پیش‌فرض) یا TCP (پورت 3478 یا 5349 برای TLS) کار می‌کند. پیام STUN شامل یک سربرگ 20 بایتی و تعداد متغیری از ویژگی‌هاست. سربرگ شامل نوع پیام (Binding Request، Binding Response، Binding Error Response)، طول و یک شناسه تراکنش منحصربه‌فرد (96 بیت) است که امکان تطابق درخواست‌ها و پاسخ‌ها را فراهم می‌کند. هر Binding Response شامل ویژگی XOR-MAPPED-ADDRESS است — آدرس خارجی مشتری که برای محافظت در برابر حملات مبتنی بر رهگیری ترافیک STUN با پوشش کدگذاری شده است.

سرور STUN چگونه کار می‌کند

سرور STUN بر اساس یک پروتکل ساده درخواست-پاسخ کار می‌کند. مشتری که در پشت NAT قرار دارد، یک Binding Request تشکیل می‌دهد و آن را به سرور STUN ارسال می‌کند. سرور بسته را دریافت می‌کند، آدرس IP منبع و پورت فرستنده را از سربرگ UDP استخراج می‌کند، سپس با قرار دادن این آدرس در ویژگی XOR-MAPPED-ADDRESS یک Binding Response تشکیل می‌دهد. پاسخ به آدرس منبع درخواست برگردانده می‌شود.

مشتری پاسخ را دریافت می‌کند و XOR-MAPPED-ADDRESS را که شامل آدرس IP خارجی و پورت تعیین شده توسط دستگاه NAT است استخراج می‌کند. سپس مشتری این آدرس را با آدرس محلی خود (RFC 1919 — خصوصی) مقایسه می‌کند. اگر آدرس‌ها یکسان باشند — مشتری در پشت NAT نیست. اگر متفاوت باشند — مشتری در پشت NAT است و آدرس خارجی به عنوان کاندید برای ICE (Interactive Connectivity Establishment) در WebRTC استفاده می‌شود.

فرآیند کشف NAT (NAT Discovery)

سرور STUN امکان تعیین نوع NAT را از طریق یک تسلسل درخواست‌های آزمایشی فراهم می‌کند. مشتری درخواست‌هایی با علملکردهای مختلف (CHANGE-REQUEST) ارسال می‌کند و پاسخ‌ها را تجزیه و تحلیل می‌کند. چرخه کامل کشف شامل ارسال درخواست‌ها به آدرس‌های IP و پورت‌های مختلف سرور STUN است. اگر سرور به درخواست با پورت تغییر یافته پاسخ دهد — NAT از نوع Restricted Cone. اگر به درخواست با پورت و IP تغییر یافته پاسخ ندهد — NAT از نوع Symmetric. این اطلاعات برای انتخاب استراتژی ICE در WebRTC حیاتی است.

سرور STUN و انواع NAT

سرور STUN قادر به تعیین چهار نوع اصلی NAT است، که هر کدام به طور متفاوتی بر امکان برقراری اتصال P2P تأثیر می‌گذارند. نوع NAT مشخص می‌کند که آیا STUN می‌تواند اتصال مستقیم بین دو مشتری را تضمین کند. اینکه کدام کاندید ICE — host، server reflexive یا relay — برای اتصال استفاده می‌شود به نوع NAT بستگی دارد.

Symmetric NAT — تنها نوعی است که STUN از عهده آن بر نمی‌آید. در Symmetric NAT، هر درخواست جدید به میزبان مقصد جدید یک آدرس خارجی متفاوت (IP و/یا پورت) دریافت می‌کند. از آنجایی که سرور STUN آدرس را برای اتصال با خود سرور STUN گزارش می‌دهد، این آدرس برای اتصال با یک مشتری دیگر قابل استفاده نیست. در چنین مواردی در WebRTC از سرور TURN برای انتقال ترافیک استفاده می‌شود. بر اساس تحقیقات (Ford et al.، RFC 3489، 2003)، تقریباً 8–10% از کلیه دستگاه‌های NAT در اینترنت متناظر هستند.

استفاده از سرور STUN در WebRTC

سرور STUN از طریق پیکربندی RTCPeerConnection در WebRTC ادغام می‌شود. مرورگر یا نرم‌افزار ماتیوی از STUN برای جمع‌آوری کاندیدات‌های ICE استفاده می‌کند، که سپس از طریق Signaling Server مبادله می‌شوند. در پیکربندی WebRTC، سرور STUN در ماتریس iceServers با پیشوند stun: برای UDP یا stuns: برای اتصال TLS مشخص می‌شود.

بیایید مثالی از راه‌اندازی سرور STUN در JavaScript برای ایجاد RTCPeerConnection در یک برنامه 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("کاندید ICE:", event.candidate.candidate);
    }
};

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

در این مثال از سرورهای STUN عمومی گوگل (stun.l.google.com:19302) استفاده شده است. در حین ایجاد offer یا answer، مرورگر به طور خودکار یک STUN Binding Request به سرورهای مشخص شده ارسال می‌کند، آدرس خارجی (server reflexive candidate) را دریافت و آن را به لیست کاندیدات‌های ICE اضافه می‌کند. پس از جمع‌آوری همه کاندیدات‌ها، آنها از طریق Signaling Server به طرف دور برای تلاش برای برقراری اتصال مستقیم P2P ارسال می‌شوند.

انواع کاندیدات ICE و STUN

در فرآیند ICE سه نوع کاندید وجود دارد: host (آدرس محلی)، srflx (server reflexive — به‌دست آمده از STUN) و relay (انتقال یافته از طریق TURN). سرور STUN ایجاد کاندیدات‌های srflx را تضمین می‌کند که اولویت بالاتری نسبت به relay دارند، زیرا اتصال از طریق STUN مستقیم است و نیازی به انتقال ندارد. فرآیند ICE تمام ترکیبات کاندیدات (محلی و به‌دست آمده از STUN) هر دو طرف را از بالاترین اولویت‌ها شروع کرده بررسی می‌کند.

محدودیت‌های پروتکل STUN

سرور STUN محدودیت‌های بنیادینی مرتبط با معماری پروتکل دارد. محدودیت اصلی عدم قابلیت کار با Symmetric NAT است، جایی که هر درخواست جدید به یک میزبان خارجی یک پورت خارجی منحصربه‌فرد دریافت می‌کند. در این صورت، آدرس به‌دست آمده از سرور STUN قابل استفاده برای اتصال با طرف دیگر نیست، زیرا NAT تنها برای ارتباط با خود سرور STUN پیوند ایجاد کرده است.

محدودیت دوم مرتبط با این است که STUN انتقال داده‌ها را تأمین نمی‌کند. اگر اتصال مستقیم P2P امکانپذیر نباشد (هر دو طرف در پشت Symmetric NAT باشند)، STUN راه جایگزینی برای انتقال داده‌ها ارائه نمی‌دهد. در این صورت سرور TURN مورد نیاز است که به عنوان انتقال‌دهنده ترافیک میان طرفین عمل می‌کند، داده‌ها را از یک شرکت‌کننده دریافت کرده و از طریق آدرس IP عمومی خود به طرف دیگر ارسال می‌کند.

• Symmetric NAT — STUN با NAT متناظر کار نمی‌کند، زیرا آدرس خارجی برای هر میزبان مقصد منحصربه‌فرد است و قابل استفاده مجدد برای P2P نیست.
• Firewall Deep Packet Inspection — بعضی دیوارهای آتش ترافیک STUN را با تشخیص امضای پروتکل در بسته‌های UDP در پورت 3478 بلوک می‌کنند.
• IPv6 — در شبکه‌های IPv6 معمولاً NAT استفاده نمی‌شود، بنابراین STUN لازم نیست، اما WebRTC در IPv6 می‌تواند بدون نیاز به STUN یا TURN از کاندیدات‌های host استفاده کند.
• وابستگی به دسترسی — سرور STUN باید در مرحله برقراری اتصال برای مشتری دسترس باشد، در غیر این صورت کاندیدات‌های srflx جمع‌آوری نخواهند شد.
• امنیت — پروتکل STUN در معرض حمله تقویت (amplification attack) است اگر سرور به طور نادرست پیکربندی شده باشد و به درخواست‌ها با آدرس منبع جعلی پاسخ دهد.

با وجود محدودیت‌ها، سرور STUN یک ماژول حیاتی زیرساخت WebRTC باقی می‌ماند. در اکثر موارد (80–90٪) اتصال مستقیم P2P با کمک STUN برقرار می‌شود که این امر از هزینه‌های انتقال TURN جلوگیری کرده و تأخیر انتقال داده‌های رسانه را کاهش می‌دهد. برای برنامه‌های WebRTC عمومی، توصیه می‌شود از ترکیب سرورهای STUN و TURN با فال‌بک خودکار برای تضمین اتصال در هر شرایط شبکه استفاده کنید.