VPN یا TURN ریلے: WebRTC کال دراصل کون لے جاتا ہے؟
ٹنل ICE جس راستے کو دیکھتا ہے اسے بدلتا ہے؛ یہ کبھی ریلے مختص نہیں کرتا اور سگنلنگ فراہم نہیں کرتا۔ موازنہ کریں کہ VPN ایگریس اور TURN سرور کیا دیتے ہیں۔
صفحہ VPN کے ذریعے لوڈ ہوتا ہے، مگر کال کبھی نہیں جڑتی: ایک ہی پتہ پٹی میں دو الگ خرابیاں۔ ٹنل نے وہ راستہ بدلا جو براؤزر استعمال کرتا ہے؛ یہ سگنلنگ سروس، STUN سرور یا ریلے نہیں بنا، اور یہ بھی طے نہیں کرتا کہ ICE کون سی امیدوار جوڑی چنے گا۔ ہر جزو کا کام الگ کرنا ہی مبہم «WebRTC بلاک ہے» کو ایک مخصوص خرابی میں بدلتا ہے۔
چار کام، جن میں ٹنل صرف ایک کو چھوتا ہے
ایپلیکیشن کسی سگنلنگ انتظام کے ذریعے سیشن معلومات کا تبادلہ کرتی ہے، اور یہ پہلا کام ہے۔ ICE امیدوار پتے جمع کرتا ہے اور جوڑیاں جانچتا ہے تاکہ کوئی ایک کام کرے، یہ دوسرا ہے۔ STUN ساتھی کو یہ جاننے دیتا ہے کہ اس کی ٹریفک باہر سے کیسی دکھتی ہے، اور TURN ان صورتوں کے لیے ریلے مختص کرتا ہے جہاں کوئی سیدھا راستہ نہ ہو۔ وہ چار کردار الگ ہیں، اور VPN ان پتوں اور فلٹرنگ پر اثر ڈالتا ہے جن سے وہ ملتے ہیں، ان میں سے کوئی بھی خود فراہم نہیں کرتا۔
اسی لیے کامیاب لاگ اِن میڈیا راستے کے بارے میں کچھ نہیں کہتا۔ سگنلنگ عام طور پر اسی HTTPS پر چلتی ہے جو صفحہ پہلے ہی استعمال کرتا ہے، پورٹ 443 پر، جبکہ میڈیا UDP کے ذریعے بالکل مختلف منزل تک جا سکتا ہے۔
نجی پتہ کاری الجھن کو بڑھاتی ہے۔ ٹنل کا پتہ ساتھی کے لیے صرف اسی وقت مفید ہوتا ہے جب اس کے پاس وہاں واپس آنے کا ارادہ شدہ راستہ ہو؛ نجی ہونا باہمی رسائی کا ثبوت نہیں، اور براؤزر ایسے امیدوار ہٹاتے وقت اسے ایسا نہیں سمجھتے جنہیں جانچا نہیں جا سکتا۔ جو امیدوار آپ کو مقامی لگتا ہے وہ دوسری طرف سے ناقابلِ جانچ ہو سکتا ہے۔ ٹنل میڈیا گرا رہا ہے یہ نتیجہ نکالنے سے پہلے اس خلا کو خارج کرنا بہتر ہے۔
VPN ایگریس کا TURN ریلے سے موازنہ کریں
دونوں پیکٹ آگے بھیجتے ہیں، اسی لیے انہیں خلط ملط کیا جاتا ہے، اور اوپر دی گئی موازنہ جدول کو خصوصیات کی فہرست کے طور پر نہیں بلکہ کالم بہ کالم پڑھنا چاہیے۔ ریلے کی مختصی ہر سیشن کے لیے ایک شے ہے جو مستند درخواست سے بنتی ہے؛ ٹنل ایک راستہ ہے۔ ایک کے پاس ختم ہونے والی اسناد ہیں، دوسرے کے پاس ساتھی کا پتہ جو یا تو قابلِ رسائی ہے یا نہیں۔
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
پورٹ نمبر فرق کو ٹھوس بناتے ہیں۔ TURN بطورِ طے شدہ UDP اور TCP کے لیے 3478 اور TLS کے لیے 5349 پر سنتا ہے، اور جو نیٹ ورک 443 کی اجازت دے مگر وہ پورٹ چھوڑ دے، وہاں براؤزنگ معمول پر رہتے ہوئے ریلے والی کالیں ناکام ہوں گی۔ VPN کا پورٹ بدلنے سے ان میں سے کچھ بھی کنفیگر نہیں ہوتا، کیونکہ اہم پورٹ ٹنل کے نہیں بلکہ ریلے سروس کے ہیں۔
تشخیص پڑھیں، پھر کال جانچیں
براؤزر پیکٹ کیپچر کے بغیر ضروری معلومات دکھاتے ہیں۔ اپنے براؤزر کے لیے WebRTC تشخیصی صفحہ کھولیں، کال کریں، اور جمع شدہ فہرست کے بجائے منتخب امیدوار جوڑی پڑھیں: کون سی مقامی اور دور امیدوار اقسام چنی گئیں، کس ٹرانسپورٹ اور پتہ خاندان پر، اور راستہ سیدھا ہے یا ریلے والا۔
دو پڑھائیاں پہلے سے جاننا بہتر ہے۔ اگر منتخب جوڑی نجی پتوں پر ہوسٹ سے ہوسٹ ہے تو میڈیا ایسے راستے پر رہتا ہے جس پر آپ استدلال کر سکتے ہیں؛ اگر ریلے سے ریلے ہے تو کال ریلے کی گنجائش خرچ کرتی ہے اور اس سروس کی دستیابی پر منحصر ہے۔ منتخب جوڑی کے بغیر «جانچ رہا ہے» پر رکنے والی خرابی کا مطلب ہے کہ امیدوار جمع ہوئے مگر کوئی بھی رابطہ جانچ پاس نہ کر سکا۔
پھر اسی کال میں وہی دو سرے صرف ایک منظور شدہ شرط بدل کر موازنہ کریں، اور نتیجہ «جڑ گیا» اشارے پر نہیں بلکہ دو طرفہ میڈیا یا ڈیٹا پر قبول کریں۔ امیدواروں کا اجتماع بہت سے ایسے مواقع میں کامیاب ہوتا ہے جو آڈیو کا ایک فریم بھی نہیں لے جاتے۔ تبدیلی کے دوسری طرف کال دہرائیں اور دونوں تشخیصی کیپچر رکھیں، کیونکہ دو دوڑوں کا موازنہ کسی ایک کو تنہا پڑھنے سے زیادہ معلومات دیتا ہے۔ وہی سرے، وہی کوڈیک، ایک بدلا ہوا متغیر۔
جو ایپلیکیشن جان بوجھ کر اپنی ICE ٹرانسپورٹ پالیسی relay پر رکھتی ہے وہ صرف ریلے امیدوار مانگتی ہے۔ یہ ترتیب ریلے نہیں بناتی اور غائب اسناد کی مرمت نہیں کرتی؛ یہ تقاضا واضح کرتی ہے، جو تب مفید ہے جب کوئی سائٹ کی چنی ہوئی پالیسی پر VPN کو موردِ الزام ٹھہرائے۔
رازداری کے دعوے کو شہادتوں جتنا ہی محدود رکھیں
امیدواروں کا ظاہر ہونا براؤزر اور ایپلیکیشن پالیسی پر منحصر ہے، صرف ٹنل کی حالت پر نہیں، اور W3C کی ساتھی رابطہ تفصیل IP کے سلوک کو اپنا الگ معاملہ سمجھتی ہے۔ اس لیے جڑا ہوا VPN یہ وعدہ کرنے کے لیے کمزور بنیاد ہے کہ کال صرف ایک منتخب پتہ ظاہر کرتی ہے۔ ایک ہی ٹنل کے پیچھے دو ساتھی ایسا راستہ بھی چن سکتے ہیں جو میزبان سے کبھی نہ نکلے، جو بیک وقت رازداری میں بہتری اور رابطے کی قید ہے۔
جو آپ درست طریقے سے کہہ سکتے ہیں وہ زیادہ محدود اور زیادہ مفید ہے: کون سی امیدوار جوڑی چنی گئی، کس ٹرانسپورٹ نے اسے لے جایا، اور وہ راستہ ٹنل کے اندر رہا یا نہیں۔ چلتی اور ناکام کال کے لیے یہ تین حقائق لکھ لیں، اور فرق عام طور پر اس جزو کا نام لیتا ہے جسے ٹھیک کرنا ہے۔
رابطہ چل نکلنے کے بعد کارکردگی کو رسائی سے الگ کریں۔ نقصان، تاخیر، قطار اور MTU سب صحیح امیدوار جوڑی کے نیچے کی طرف ہیں، اور رک رک کر چلتی کال کو رابطے کی خرابی سمجھنا آپ کو بلا وجہ امیدوار فہرست کی طرف واپس بھیجتا ہے۔