راؤٹر VPN فعال کرنے کے بعد کاسٹنگ کیوں بند ہو جاتی ہے
دریافت لنک لوکل ملٹی کاسٹ پر چلتی ہے جبکہ ٹی وی میڈیا خود حاصل کرتا ہے۔ پالیسی کی ڈیفالٹ LAN کی درخواست پکڑ کر ٹنل میں بھیج سکتی ہے۔
راؤٹر VPN فعال کرنے سے پہلے کاسٹنگ کام کرتی تھی اور فعال کرنے کے فوراً بعد ناکام ہو جاتی ہے، جبکہ فون پر عام براؤزنگ اب بھی کام کرتی ہے۔ یہ دونوں باتیں باہم مطابقت رکھتی ہیں، کیونکہ کاسٹنگ ایک واحد کنکشن نہیں ہے۔ فون مقامی نیٹ ورک کے ذریعے ریسیور کو تلاش اور کنٹرول کرتا ہے، اور پھر ریسیور اپنے کنکشن کے ذریعے میڈیا حاصل کرتا ہے۔
دو راستے جو مختلف طریقے سے ناکام ہوتے ہیں
کنٹرول کا راستہ مقامی ہے۔ فون مقامی نیٹ ورک سے پوچھ کر ریسیور تلاش کرتا ہے، پھر جس پتے کا علم ہوا اس پر کنٹرول کنکشن کھولتا ہے۔ اگر ریسیور فہرست میں کبھی ظاہر نہ ہو، تو دریافت کا مرحلہ کسی بھی میڈیا کی درخواست سے پہلے ناکام ہو گیا۔
میڈیا کا راستہ لازماً مقامی نہیں ہوتا۔ بہت سے ریسیور اسٹریم خود حاصل کرتے ہیں، اپنے کنکشن اور اپنی اسناد کے ساتھ، اس لیے فون کا راستہ ریسیور کے راستے کی وضاحت نہیں کرتا۔ جو فون ایک ایگزٹ استعمال کرتا دکھائی دے، وہ اس بارے میں کچھ نہیں بتاتا کہ ٹی وی کی ٹریفک کہاں جاتی ہے۔
یہی تقسیم ہے جس کی وجہ سے ناکامی عجیب لگتی ہے۔ ٹنل نے فون کی روٹنگ ٹیبل بدلی اور ٹی وی کی نہیں بدلی، اس لیے جو علامت جوڑی کے ایک طرف ظاہر ہو اسے اسی طرف تلاش کرنا ہوگا۔ غلط ڈیوائس کو تلاش کرنا ہی عام وجہ ہے کہ درستی کچھ کرتی دکھائی نہیں دیتی۔
دریافت سب سے پہلے کیوں ٹوٹتی ہے
دریافت عام طور پر لنک لوکل ملٹی کاسٹ پر چلتی ہے۔ mDNS 224.0.0.251 کو UDP پورٹ 5353 پر بھیجتا ہے، اور SSDP 239.255.255.250 کو UDP پورٹ 1900 پر بھیجتا ہے۔ دونوں بناوٹ ہی سے ایک لنک تک محدود ہیں، اسی لیے راؤٹر ریپیٹر یا پراکسی کی مدد کے بغیر انہیں حصوں کے درمیان آگے نہیں بھیجتا۔ روٹ شدہ VPN ملٹی کاسٹ گروپ کو نہیں پھیلاتا، اور پالیسی روٹ اس گروپ کو، جو لنک سے کبھی نہیں نکلا، دوسرے لنک پر ظاہر نہیں کر سکتا۔
اس لیے پہلی ناکامی کا انکرپشن سے کوئی تعلق نہیں۔ فون کا ملٹی کاسٹ اسی انٹرفیس سے نکلتا ہے جس پر بھیجا گیا تھا، ریسیور اس حصے میں ہے جو اسے کبھی نہیں دیکھتا، اور ڈیوائس کی فہرست خالی واپس آتی ہے۔ خالی فہرست اس بات کا ثبوت نہیں کہ ٹی وی نے انٹرنیٹ رسائی کھو دی ہے۔
الگ تھلگ پن بغیر کسی VPN کے بھی ویسی ہی علامت پیدا کرتا ہے۔ مہمان نیٹ ورک اور ایکسیس پوائنٹ کی کلائنٹ تنہائی جان بوجھ کر ڈیوائسز کو ایک دوسرے سے بات کرنے سے روکتی ہیں، اور الگ تھلگ حصے پر راؤٹر VPN فعال کرنے سے اس میں کچھ نہیں بدلتا۔ ٹنل دیکھنے سے پہلے تنہائی کی ترتیب دیکھیں۔ یہ سستا جواب ہے اور زیادہ عام بھی۔
حصوں کی ترتیب دوسرا نصف ہے۔ دوسرا راؤٹر، مختلف موڈ میں میش نوڈ، یا کسی اور NAT کے پیچھے وائرڈ حصہ، سب ریسیور کو وہاں رکھ دیتے ہیں جہاں فون کی دریافت کی ٹریفک نہیں پہنچتی۔
پالیسی کی ڈیفالٹ مقامی درخواست کیوں نگل سکتی ہے
جو راؤٹر ساری ٹریفک کو ٹنل میں روٹ کرتا ہے وہ ٹنل انٹرفیس پر ڈیفالٹ روٹ لگاتا ہے۔ اگر LAN پری فکس اس پالیسی سے خارج نہ ہو، تو دو میٹر دور ڈیوائس کے لیے بھیجا گیا پیکٹ اب ڈیفالٹ سے مطابقت رکھتا ہے، اور راؤٹر کنٹرول درخواست سوئچ کی بجائے ٹنل میں بھیج دیتا ہے۔
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
قواعد کی ترتیب نتیجہ طے کرتی ہے۔ پالیسی روٹنگ قواعد کو ترجیحی ترتیب میں جانچتی ہے، اس لیے مقامی پری فکس کے لیے استثنا اس قاعدے سے پہلے آنا چاہیے جو ٹنل ٹیبل منتخب کرتا ہے۔ ٹنل قاعدے کے بعد استثنا شامل کرنے کا کوئی اثر نہیں، اسی لیے درست دکھنے والی ترتیب بھی LAN ٹریفک کو دور کے ایگزٹ پر بھیج سکتی ہے۔
درستی تنگ ہے: کاسٹنگ کے بہاؤ کے لیے مطلوبہ مخصوص مقامی منزلوں کی اجازت دیں، اور باقی تنہائی کو ویسے ہی رہنے دیں۔ پہلے قدم کے طور پر کلائنٹ تنہائی ہٹانا علامت دور کرتا ہے مگر وہ کنٹرول پھینک دیتا ہے جو نیٹ ورک کے لیے بنایا گیا تھا۔
فون پر ایک سرسری جائزہ طے کرتا ہے کہ دو ناکامیوں میں سے کون سی ہے۔ اگر ریسیور تک راستہ ٹنل کی طرف اشارہ کرتا ہے تو مسئلہ پالیسی ہے۔ اگر یہ LAN کی طرف اشارہ کرتا ہے اور دریافت پھر بھی ناکام ہو تو مسئلہ ملٹی کاسٹ یا تنہائی ہے، اور راستے کی کوئی تبدیلی مدد نہیں کرے گی۔
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpوہ مرحلہ جانچیں جو بدلا، ملک نہیں
درج مشاہدات بار بار تجربات سے بہتر ہیں۔ نوٹ کریں کہ ریسیور ڈیوائس کی فہرست میں ظاہر ہوتا ہے یا نہیں، کنٹرول درخواست اس تک پہنچتی ہے یا نہیں، اور اسٹریم منتخب ہونے پر پلے بیک شروع ہوتا ہے یا نہیں۔ ہر جواب ایک مرحلہ شک سے خارج کرتا ہے۔
پھر ایگزٹ مقامات بدلنے کی بجائے ہر مرحلے کو براہ راست جانچیں۔ VPN کا ملک بدلنا میڈیا کے راستے کو جانچتا ہے اور دریافت و کنٹرول کے مراحل کو نہیں چھوتا، اس لیے یہ اتفاقاً مدد کرتا دکھ سکتا ہے مگر کچھ نہیں سکھاتا۔
ریسیور کی طرف، اس کا اپنا راستہ اور اس کی اپنی اکاؤنٹ حالت دیکھیں۔ وہ ٹی وی جو فون سے مختلف ایگزٹ کے ذریعے میڈیا حاصل کرتا ہے ایک معمول کی بناوٹ ہے، اور وہاں ناکامی فون کے ٹنل کے بارے میں نہیں بلکہ ریسیور کی نیٹ ورک پالیسی کے بارے میں سوال ہے۔
نتیجہ ایک جملے میں لکھیں کہ کون سا مرحلہ ٹوٹا اور اسے کس نے بدلا۔ وہ جملہ ملک بدلنے کے ایک ہفتے سے زیادہ قیمتی ہے، اور اگلی فرم ویئر تازہ کاری تک قائم رہتا ہے۔
کاسٹنگ ٹنلوں کے بارے میں عمومی قاعدے کے لیے اچھا امتحانی موقع ہے۔ جب نیٹ ورک میں ایک شامل کیا جائے تو پہلا سوال یہ ہے کہ کون سی منزلیں کبھی اس میں داخل نہیں ہونی چاہیے تھیں۔ دوسرا یہ کہ پالیسی نے ان میں سے کسے خاموشی سے قبول کر لیا۔