د 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 غوښتنه، بیا یوه اعلان شوې غوښتنه وازموئ. که لومړی کار وکړ او دویم نه، تونل روغ دی او کشف ټوله ستونزه ده.