Chromecast اور DLNA کی دریافت کبھی روٹ شدہ VPN کو عبور نہیں کرتی

کاسٹ بٹن کچھ بھی فہرست نہیں کرتا، VLC DLNA خالی رہتا ہے، اور دوسرے سرے کی مشین بغیر شکایت ping کا جواب دیتی ہے۔ یہ امتزاج بینڈوڈتھ کا مسئلہ نہیں اور فائر وال کا معمہ بھی نہیں۔ ان پروٹوکولز میں دریافت مقامی سیگمنٹ پر گروپ تبادلہ ہے، اور روٹ شدہ سرنگ گروپ ایڈریس والی ٹریفک نہیں لے جاتی۔ جو سیشن آپ شروع کرنے کی کوشش کر رہے ہیں وہ کبھی پیش نہیں کیا جاتا۔

رسائی ٹھیک ہے۔ دریافت غائب ہے۔

افسانہ: سرنگ کو ایک سیٹنگ یا زیادہ صلاحیت درکار ہے

عام تجاویز یہ ہیں کہ ہم مرتبہ سے ہم مرتبہ ٹریفک فعال کریں، MTU بڑھائیں، یا سرنگ کے آلے کی قسم بدلیں۔ ان میں سے کوئی بھی نشریاتی ڈومین نہیں جوڑتا۔ Multicast سوئچز اور مقامی نیٹ ورک اسٹیک کے ذریعے پہنچایا جاتا ہے، اور پوائنٹ ٹو پوائنٹ TUN انٹرفیس کے پاس بھرنے کے لیے کوئی گروپ ایڈریس نہیں ہے۔

سیٹنگز بدلنے سے ناکامی زیادہ بلند ہو سکتی ہے۔ لیکن یہ ایسا اعلان ظاہر نہیں کر سکتی جو پروٹوکول نے کبھی نہ بھیجا ہو۔

دریافت کا تبادلہ دراصل کیا ہے

آپ کو ملنے والی تقریباً ہر چیز تین نمونوں میں آ جاتی ہے۔ mDNS 224.0.0.251 کو UDP 5353 پر بھیجتا ہے، SSDP 239.255.255.250 کو UDP 1900 پر بھیجتا ہے، اور پرانی SMB براؤزنگ فہرستیں ذیلی نیٹ کے نشریاتی پتے پر جاتی تھیں۔ ہر ایک میزبان کے بجائے گروپ کو مخاطب ہے، اور ہر ایک اسی سیگمنٹ پر سامع کی توقع کرتا ہے۔ روٹ شدہ سرنگ کے پار وصول کنندہ اس سیگمنٹ پر نہیں ہے، اس لیے کچھ نہیں پہنچتا۔

یہاں تک کہ منتقل شدہ اعلان بھی پے لوڈ لے کر چلتا ہے: عام طور پر بھیجنے والے کا LAN پتہ اور پورٹ، جہاں دور دراز ناظر کو پھر پہنچنا ہوتا ہے۔

سرنگ بدلنے سے پہلے کیپچر پڑھیں

ایپ اسکین کرتے وقت سرنگ انٹرفیس پر کیپچر کریں۔ خالی کیپچر کا مطلب ہے کہ اعلان نے کبھی حد پار نہیں کی، اور سرنگ کی کوئی ٹیوننگ اسے نہیں بدلتی۔ وہ پیکٹ جو ایپ کے ابھی کچھ نہ دکھانے کے باوجود آتے ہیں عام طور پر اس بات کا مطلب ہیں کہ اعلان کردہ پتہ ناظر کے لیے ناقابل رسائی ہے — یہ دریافت کے بھیس میں روٹنگ کا مسئلہ ہے۔

دو منٹ کی کیپچر پورٹس کے بارے میں ایک گھنٹے کے اندازے کی جگہ لیتی ہے: tcpdump -ni tun0 udp port 5353 or udp port 1900۔

تین حل، سب سے سستا پہلے

کلائنٹ کو براہ راست سروس کے پتے کی طرف اشارہ کریں۔ DLNA، SMB اور سادہ میڈیا سرورز کے لیے یہ دریافت کو مکمل طور پر چھوڑ دیتا ہے اور ثابت کرتا ہے کہ پے لوڈ کا راستہ کام کرتا ہے، جو اسے بہترین پہلا امتحان اور قابل استعمال متبادل بھی بناتا ہے۔ Chromecast استثناء ہے، کیونکہ وصول کنندہ مخاطب ہونے کے بجائے ملنے کی توقع کرتا ہے۔

گیٹ وے پر پروٹوکول منتقل کریں۔ mDNS منعکس کرنے والا سرنگ اور LAN کے درمیان اعلانات دہراتا ہے، اور Avahi ایک منعکس کنندہ حصہ دیتا ہے جو واضح انٹرفیس فہرست لیتا ہے۔ منتقلی کو تنگ رکھیں، اور تصدیق کریں کہ اعلان کردہ پتہ دونوں طرف سے قابل رسائی ہے، ورنہ جواب اب بھی ایسے ذیلی نیٹ کی طرف اشارہ کرتا ہے جہاں ناظر روٹ نہیں کر سکتا۔

روٹنگ کے بجائے پل بنائیں۔ وہ TAP سیگمنٹ جس میں سرور tap آلے کو LAN پر پل کرتا ہے دونوں سروں کو ایک نشریاتی ڈومین میں رکھتا ہے، اس لیے اعلانات بغیر تبدیلی کے گزرتے ہیں۔ یہ سب سے مہنگا آپشن بھی ہے، کیونکہ ایک ذیلی نیٹ کا مطلب ایک ناکامی ڈومین ہے اور LAN کی ہر multicast سروس اب ہر ساتھی تک پہنچتی ہے۔

کیا مدد نہیں کرتا، چاہے کتنی بار تجویز کیا جائے

پل کے بغیر dev tun کو dev tap میں بدلنے سے اب بھی روٹ شدہ TAP آلہ رہ جاتا ہے، اس لیے رویہ نہیں بدلتا۔ client-to-client ہم مرتبہ کے درمیان unicast کی اجازت دیتا ہے اور نشریات نہیں بھرتا۔ دریافت کی پورٹ کو ایک میزبان پر بھیجنے سے گروپ ایڈریس والی ٹریفک نہیں پہنچتی۔ ایک پتے سے بندھا میڈیا سرور اسی پتے پر جواب دیتا رہتا ہے جب تک اس کی اپنی ترتیب VPN انٹرفیس درج نہ کرے۔

ایک براہ راست unicast درخواست آزمائیں، پھر ایک اعلان شدہ درخواست۔ اگر پہلی کام کرے اور دوسری نہ، سرنگ صحت مند ہے اور دریافت ہی پورا مسئلہ ہے۔