کشف 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 پل می‌زند هر دو سر را در یک دامنه پخش قرار می‌دهد، پس اعلان‌ها بدون تغییر عبور می‌کنند. همچنین گران‌ترین گزینه است، چون یک زیرشبکه یعنی یک دامنه خرابی و هر سرویس multicast در LAN حالا به هر همتا می‌رسد.

چه چیزی کمک نمی‌کند، هر چند بار هم پیشنهاد شود

تغییر dev tun به dev tap بدون پل یک دستگاه TAP به جا می‌گذارد که هنوز مسیریابی می‌شود، پس رفتار تغییر نمی‌کند. client-to-client یونیکست همتا-به-همتا را مجاز می‌کند و پخش را سیل‌آسا نمی‌کند. هدایت یک پورت کشف به یک میزبان ترافیک با آدرس گروهی را تحویل نمی‌دهد. سرور رسانه‌ای که به یک آدرس مقید است تا زمانی که پیکربندی خودش رابط VPN را فهرست نکند همچنان روی همان آدرس پاسخ می‌دهد.

یک درخواست یونیکست مستقیم و سپس یک درخواست اعلام‌شده را بیازمایید. اگر اولی کار کند و دومی نه، تونل سالم است و کشف تمام مشکل است.