VPN پر کاسٹنگ: دریافت، کنٹرول یا اسٹریم؟
غائب ریسیور، مسترد سیشن اور رکتی ہوئی اسٹریم مختلف جگہوں پر ناکام ہوتے ہیں۔ فون کی VPN پالیسی یا نیٹ ورک بدلنے سے پہلے مرحلے کا نام لیں۔
کاسٹنگ تین جگہوں پر ٹوٹتی ہے جو صوفے سے ایک جیسی دکھتی ہیں۔ فون کو ریسیور کبھی نظر نہ آئے، ریسیور نمودار ہو کر سیشن سے انکار کر دے، یا سیشن شروع ہو کر ایک منٹ بعد رک جائے۔ فون میں ٹنل ان راستوں میں سے ہر ایک کو مختلف طرح بدلتا ہے، اور ان میں سے ایک کے لیے کچھ بھی نہیں بدلتا۔ پہلے ناکام مرحلے کا نام لیں، پھر فیصلہ کریں کہ پالیسی بدلنا ہی درست لیور ہے۔
پالیسی بدلنے سے پہلے ناکام مرحلے کا نام لیں
کاسٹ آئیکن کو چھونے کے فوراً بعد فون کیا کرتا ہے، یہ دیکھیں۔ خالی فہرست دریافت کا نتیجہ ہے، ناکامی کی اطلاع دینے والا چھونا کنٹرول کا نتیجہ ہے، اور رکنے سے پہلے شروع ہونے والا سیشن پلے بیک کا نتیجہ ہے۔ ان تینوں کے مالک مختلف ہیں، اور عام طور پر صرف پہلے دو ہی فون کی ٹنل ترتیبات سے متعلق ہوتے ہیں۔
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
کچھ بھی بدلنے سے پہلے مرحلہ لکھ لیں۔ غلط مرحلے پر لگائی گئی اصلاح اگلا امتحان ناقابل مطالعہ کر دیتی ہے، اور کاسٹنگ کی زیادہ تر کہانیاں اسی الجھن سے نکلتی ہیں۔
دریافت مقامی ٹریفک ہے، اور ٹنل اسے چھپا دیتا ہے
ریسیور اپنا اعلان مقامی اعلانات کے ذریعے کرتے ہیں اور فون انہیں اسی لنک پر سوالات سے ڈھونڈتا ہے، اس لیے جو بھی فون کو اس لنک سے ہٹاتا ہے وہ ریسیور کو فہرست سے ہٹا دیتا ہے۔ جو ٹنل ساری ٹریفک LAN سے دور لے جاتا ہے وہ ان تبادلوں کو چھپا سکتا ہے، اور ایپ کی سطح پر مقامی نیٹ ورک کی اجازت راستہ موجود ہونے پر بھی انہیں روک سکتی ہے۔ کلائنٹ علیحدگی والا مہمان Wi-Fi بغیر کسی VPN کے وہی خالی فہرست دیتا ہے۔ ٹنل کو قصوروار ٹھہرانے سے پہلے ثابت کریں کہ دونوں آلات ایک ہی حصہ بانٹتے ہیں۔
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRپہلا کمانڈ بتاتا ہے کہ معاون مشین کے حصے میں کیا خود کا اعلان کر رہا ہے، اور دوسرا ملٹی کاسٹ DNS گروپ سے براہ راست پوچھتا ہے۔ دونوں میں نہ ہونے والا ریسیور فون کی ایپ میں بھی نظر نہیں آئے گا، فون کی ٹنل حالت جو بھی ہو۔ اگر ریسیور اس آلے سے نظر آتا ہے جس کا ٹنل بند ہے اور اس سے نظر نہیں آتا جس کا ٹنل کھلا ہے، تو آپ نے مرحلہ اور وجہ ایک ساتھ ڈھونڈ لیے۔
LAN استثنا ٹنل کو کھلا رکھتا ہے
بہت سے کلائنٹ مقامی نیٹ ورک کا استثنا دیتے ہیں جو ٹنل کو فعال رکھتے ہوئے مقامی پتوں کی اجازت دیتا ہے۔ کِل سوئچ یا پورا فائر وال بند کرنے کے بجائے وہی دستاویزی ترتیب استعمال کریں، کیونکہ وہ کاسٹنگ کی ضرورت سے کہیں زیادہ بدلتے ہیں۔ اگر نیٹ ورک جان بوجھ کر سمارٹ آلات الگ کرتا ہے، تو ہموار رسائی کے بجائے مالک سے مخصوص دریافت، کنٹرول اور واپسی کی ٹریفک مانگیں۔
nc -vz 192.168.1.50 8009ریسیور کی طرف کنٹرول کا امتحان اجازت کو رسائی سے الگ کرتا ہے: جواب دینے والا پورٹ یعنی راستہ موجود ہے، جبکہ انکار یعنی فون کو آلہ دریافت کرنے کی اجازت تھی اور وہ پھر بھی اس سے بات نہیں کر سکتا۔ 8008 اور 8009 عام کاسٹ پورٹ ہیں، اور ایپ دیگر استعمال کر سکتی ہے، اس لیے ایک مسترد پورٹ کو اشارہ سمجھیں، فیصلہ نہیں۔ استثنا اور ایپ کی اجازت آزاد رہتے ہیں، کیونکہ مقامی رسائی دینا راستہ نہیں بناتا اور راستہ شامل کرنا اجازت نہیں دیتا۔ کِل سوئچ دوبارہ جڑنے کے بعد مقامی ٹریفک بھی گرا سکتا ہے، اسی لیے ٹنل واپس آنے پر دریافت دوبارہ پرکھنی چاہیے۔
پلے بیک فون کا کنکشن استعمال نہ کرے
ایپ کی ہدایت والے سیشن میں فون ریسیور کو میڈیا پتہ دیتا ہے اور ریسیور اسے اپنے کنکشن سے لاتا ہے، اس لیے فون کا عوامی پتہ بدلنے سے اسٹریم پر کچھ اثر نہیں ہوتا۔ اکاؤنٹ سے محدود عنوان اپنی وجوہات کی بنا پر پھر بھی ناکام ہو سکتا ہے، اور Google کاسٹنگ کی شرائط نیٹ ورک راستے کے بجائے ایپ اور آلے کی مطابقت کو محیط ہیں۔ ٹیلی ویژن کو خود ٹنل سے گزارنا اپنے پالیسی سوالات والی الگ ترتیب ہے۔
دو اشارے ان طریقوں کو الگ کرتے ہیں۔ فون کی اسکرین لاک ہونے کے بعد بھی چلنے والی کاسٹ ایپ کی ہدایت والی ہوتی ہے، کیونکہ ریسیور خود لاتا ہے؛ بھیجنے والے کی اسکرین لاک ہونے پر رکنے والا آئینہ فون سے آنے والا مسلسل اسٹریم ہے۔ جب دریافت اور کنٹرول کامیاب ہوں مگر پلے بیک رک جائے، تو اس کے بجائے ریسیور کے Wi-Fi لنک اور اس کے انٹرنیٹ راستے کو دیکھیں، کیونکہ فون پر رفتار کا امتحان فون بیان کرتا ہے، ٹیلی ویژن نہیں۔
استثنا واپس لیں اور دوبارہ پرکھیں
ہر عارضی تبدیلی کے لیے واپسی کا راستہ چاہیے، اور ترتیب اہم ہے۔ LAN استثنا ہٹائیں، ٹنل دوبارہ جوڑیں تاکہ کلائنٹ اپنی پالیسی دوبارہ لاگو کرے، پھر دریافت کا مرحلہ دہرائیں اور لکھیں کہ ریسیور دوبارہ غائب ہوتا ہے یا نہیں۔ یہ ترتیب بتاتی ہے کہ استثنا کام کر رہا تھا یا درمیان میں کچھ اور بدلا۔
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'بعد میں تینوں مراحل الگ الگ جانچیں، کیونکہ ایک کی کامیابی باقی کے بارے میں کچھ نہیں بتاتی۔ پھر دیکھیں کہ غیر متعلقہ فون ایپس اب بھی مطلوبہ راستے پر چلتی ہیں، کیونکہ خاموشی سے مکمل بائی پاس بن گیا مقامی استثنا ایک اضافی چھونے والے کاسٹ سے بدتر نتیجہ ہے۔