STUN Server: یہ کیا ہے، کیسے کام کرتا ہے اور کہاں استعمال ہوتا ہے

STUN سرور کیا ہے

STUN Server (Session Traversal Utilities for NAT) ایک نیٹ ورک سروس ہے جو RFC 5389 میں متعین اور RFC 8489 میں اپ ڈیٹ کردہ پروٹوکول پر کام کرتی ہے۔ STUN سرور کا بنیادی کام کلائنٹ کو اس کے اپنے عوامی IP ایڈریس اور پورٹ کے بارے میں معلومات فراہم کرنا ہے جیسا کہ بیرونی نیٹ ورک سے دیکھا جاتا ہے، نیز کلائنٹ اور انٹرنیٹ کے درمیان NAT ڈیوائس کی قسم متعین کرنا ہے۔

STUN فن تعمیر میں دو اجزاء شامل ہیں: ایک STUN کلائنٹ جو ایپلیکیشن میں شامل ہوتا ہے (مثلاً براؤزر یا مقامی WebRTC ایپ)، اور ایک STUN سرور جو عوامی نیٹ ورک میں تعینات ہوتا ہے۔ کلائنٹ سرور کو ایک بائنڈنگ درخواست (Binding Request) بھیجتا ہے، جو اپنے جواب میں درخواست کے ماخذ IP ایڈریس اور پورٹ کو ظاہر کرتا ہے — یعنی کلائنٹ کے عوامی ایڈریس جیسا کہ سرور دیکھتا ہے۔ اس ڈیٹا کا اپنے مقامی ایڈریسز سے موازنہ کرکے، کلائنٹ یہ طے کر سکتا ہے کہ اس کے نیٹ ورک میں کس قسم کا NAT استعمال ہو رہا ہے۔

STUN پروٹوکول

STUN UDP (ڈیفالٹ طور پر پورٹ 3478) یا TCP (پورٹ 3478 یا TLS کے لیے 5349) پر کام کرتا ہے۔ ایک STUN پیغام 20 بائٹس کے ہیڈر اور متغیر تعداد میں خصوصیات پر مشتمل ہوتا ہے۔ ہیڈر میں پیغام کی قسم (Binding Request، Binding Response، Binding Error Response)، لمبائی، اور ایک منفرد لین دین شناخت کنندہ (96 بٹ) ہوتا ہے جو درخواستوں اور جوابات کو ملانے کی اجازت دیتا ہے۔ ہر Binding Response میں XOR-MAPPED-ADDRESS خصوصیت ہوتی ہے — کلائنٹ کا بیرونی ایڈریس، جو STUN ٹریفک کی روک تھام پر مبنی حملوں سے بچانے کے لیے ماسکنگ کے ساتھ انکوڈ کیا جاتا ہے۔

STUN سرور کیسے کام کرتا ہے

ایک STUN سرور ایک سادہ درخواست جوابی پروٹوکول پر کام کرتا ہے۔ NAT کے پیچھے موجود کلائنٹ ایک بائنڈنگ درخواست (Binding Request) بناتا ہے اور اسے STUN سرور کو بھیجتا ہے۔ سرور پیکٹ وصول کرتا ہے، UDP ہیڈر سے ماخذ IP ایڈریس اور بھیجنے والے کا پورٹ نکالتا ہے، پھر ایک بائنڈنگ جواب (Binding Response) بناتا ہے، اس ایڈریس کو XOR-MAPPED-ADDRESS خصوصیت میں پیک کرتا ہے۔ جواب درخواست کے ماخذ ایڈریس پر واپس بھیجا جاتا ہے۔

کلائنٹ جواب وصول کرتا ہے اور XOR-MAPPED-ADDRESS نکالتا ہے، جس میں NAT ڈیوائس کے ذریعے متعین کردہ بیرونی IP ایڈریس اور پورٹ ہوتا ہے۔ پھر کلائنٹ اس ایڈریس کا اپنے مقامی (RFC 1919 — نجی) ایڈریس سے موازنہ کرتا ہے۔ اگر ایڈریس مماثل ہیں — کلائنٹ NAT کے پیچھے نہیں ہے۔ اگر مختلف ہیں — کلائنٹ NAT کے پیچھے ہے، اور بیرونی ایڈریس WebRTC میں ICE (Interactive Connectivity Establishment) کے لیے امیدوار کے طور پر استعمال ہوتا ہے۔

NAT دریافت کا عمل

ایک STUN سرور جانچ کی درخواستوں کے ایک سلسلے کے ذریعے NAT کی قسم متعین کرنے کی اجازت دیتا ہے۔ کلائنٹ مختلف جھنڈیوں (CHANGE-REQUEST) کے ساتھ درخواستیں بھیجتا ہے اور جوابات کا تجزیہ کرتا ہے۔ مکمل دریافت کا چکر STUN سرور کے مختلف IP ایڈریسز اور پورٹس پر درخواستیں بھیجنا شامل ہے۔ اگر سرور تبدیل شدہ پورٹ کے ساتھ درخواست کا جواب دیتا ہے — NAT ريسٹریکٹڈ کون قسم کا ہے۔ اگر یہ تبدیل شدہ پورٹ اور IP کے ساتھ درخواست کا جواب نہیں دیتا — NAT سیمیٹرک قسم کا ہے۔ یہ معلومات WebRTC میں ICE حکمت عملی منتخب کرنے کے لیے اہم ہے۔

STUN سرور اور NAT کی اقسام

ایک STUN سرور چار اہم اقسام کے NAT کا پتہ لگا سکتا ہے، جن میں سے ہر ایک P2P کنکشن قائم کرنے کی صلاحیت کو مختلف طریقے سے متاثر کرتا ہے۔ NAT کی قسم طے کرتی ہے کہ آیا STUN دو کلائنٹس کے درمیان براہ راست کنکشن فعال کر سکتا ہے۔ یہ بھی طے کرتی ہے کہ کنکشن کے لیے کون سا ICE امیدوار — host، server reflexive یا relay — استعمال ہوگا۔

Symmetric NAT وہ واحد قسم ہے جس سے STUN نمٹ نہیں سکتا۔ Symmetric NAT کے ساتھ، ایک نئے منزل میزبان کو ہر نئی درخواست ایک مختلف بیرونی ایڈریس (IP اور/یا پورٹ) حاصل کرتی ہے۔ چونکہ STUN سرور خود STUN سرور سے کنکشن کے لیے ایڈریس رپورٹ کرتا ہے، یہ ایڈریس دوسرے کلائنٹ سے جڑنے کے لیے نا مناسب ہے۔ ایسے معاملات میں، WebRTC ٹریفک کو ریلے کرنے کے لیے TURN سرور استعمال کرتا ہے۔ تحقیق کے مطابق (Ford et al., RFC 3489, 2003)، انٹرنیٹ پر تقریباً 8–10% NAT ڈیوائسز سیمیٹرک ہیں۔

WebRTC میں STUN سرور کا استعمال

STUN سرور RTCPeerConnection کنفیگریشن کے ذریعے WebRTC میں ضم ہوتا ہے۔ براؤزر یا مقامی ایپلیکیشن ICE امیدوار جمع کرنے کے لیے STUN استعمال کرتی ہے، جو بعد میں سگنلنگ سرور کے ذریعے تبادلہ کیے جاتے ہیں۔ WebRTC کنفیگریشن میں، STUN سرور iceServers صف میں UDP کے لیے stun: سابقہ یا TLS کنکشن کے لیے stuns: کے ساتھ متعین کیا جاتا ہے۔

آئیے WebRTC ایپلیکیشن کے لیے RTCPeerConnection بناتے وقت JavaScript میں STUN سرور سیٹ اپ کی ایک مثال دیکھتے ہیں۔

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);

یہ مثال Google کے عوامی STUN سرورز (stun.l.google.com:19302) استعمال کرتی ہے۔ offer یا answer بناتے وقت، براؤزر خود بخود متعین سرورز کو STUN بائنڈنگ درخواست بھیجتا ہے، بیرونی ایڈریس (server reflexive امیدوار) حاصل کرتا ہے اور اسے ICE امیدواروں کی فہرست میں شامل کرتا ہے۔ تمام امیدواروں کے جمع ہونے کے بعد، وہ براہ راست 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 کے لیے دوبارہ استعمال نہیں کیا جا سکتا۔
• فائر وال گہری پیکٹ معائنہ — کچھ فائر والز پورٹ 3478 پر UDP پیکٹوں میں پروٹوکول کے دستخط کا پتہ لگا کر STUN ٹریفک کو بلاک کرتی ہیں۔
• IPv6 — IPv6 نیٹ ورکس میں، NAT عام طور پر استعمال نہیں ہوتا، اس لیے STUN کی ضرورت نہیں، لیکن IPv6 پر WebRTC STUN یا TURN کی ضرورت کے بغیر host امیدوار استعمال کر سکتا ہے۔
• دستیابی پر انحصار — STUN سرور کنکشن قیام کے مرحلے کے دوران کلائنٹ کے لیے قابل رسائی ہونا چاہیے، ورنہ srflx امیدوار جمع نہیں ہوں گے۔
• سیکیورٹی — STUN پروٹوکول ایمپلیفیکیشن حملوں کا شکار ہے اگر سرور غلط طریقے سے کنفیگر کیا گیا ہو اور جعلی ماخذ ایڈریس والی درخواستوں کا جواب دیتا ہو۔

حدود کے باوجود، STUN سرور WebRTC انفراسٹرکچر کا ایک اہم جزو بنا ہوا ہے۔ زیادہ تر معاملات میں (80–90%)، STUN استعمال کرکے براہ راست P2P کنکشن قائم کیا جا سکتا ہے، جو TURN ریلے کے اخراجات سے بچاتا ہے اور میڈیا ڈیٹا کی ترسیل میں تاخیر کو کم کرتا ہے۔ عوامی WebRTC ایپلیکیشنز کے لیے، کسی بھی نیٹ ورک کے حالات میں کنکشن کی ضمانت کے لیے خودکار فالبیک کے ساتھ STUN اور TURN سرورز کا امتزاج استعمال کرنے کی سفارش کی جاتی ہے۔