چرا چندپخشی بدون برنامه از VPN عبور نمی‌کند
قابلیت دسترسی موضوع یونیکست است. پیش از افزودن پل یا تکرارکننده، گروه، دامنه آن، وضعیت ارسال و یک مسیر از یک منبع به یک گیرنده را بررسی کنید.
دو سایت می‌توانند با یونیکست کاملاً به هم برسند و با این حال رفتاری داشته باشند که گویی یکی از آنها اعلان کشف چاپگر، جریان IPTV یا ضربان خوشه را نمی‌بیند. این یک تونل خراب نیست؛ این تفاوت میان یک مقصد و یک گروه است. تحویل چندپخشی به مدل عضویت، وضعیت ارسال در طول مسیر و رابطی نیاز دارد که حاضر به حمل ترافیک باشد، و هیچ یک از اینها از یک مسیر یونیکست به دست نمی‌آید. رفتن از گروه برنامه به یک گیرنده سالم کوتاه‌ترین راه به یک پاسخ است.
با گروه و برنامه آغاز کنید
بپرسید برنامه از کدام نشانی گروه استفاده می‌کند و ترافیک برای چه چیزی است. یک پروتکل کشف که سرویس‌ها را اعلام می‌کند، یک جریان پخش و بسته‌های سلام یک پروتکل مسیریابی سه مسئله متفاوت با سه پاسخ پذیرفتنی متفاوت‌اند. خود نشانی گروه دامنه را می‌گوید: نشانی‌های بلوک کنترل شبکه محلی برای ارسال خارج از پیوند توسط مسیریابی معمولی در نظر گرفته نشده‌اند و برنامه‌هایی که از آنها استفاده می‌کنند معمولاً یک دامنه پخش عمومی را فرض می‌کنند. جریان پخش روی گروهی با دامنه جهانی طراحی متفاوتی از پروتکل کشفی است که انتظار دارد هر دستگاه هر پرس‌وجو را بشنود، و تنها دومی به اندازه دامنه پخش عمومی اهمیت می‌دهد.
تصمیم بگیرید که نیاز، سرویس است یا سازوکار کشف، چون این دو پاسخ از نظر هزینه یک مرتبه بزرگی تفاوت دارند. یکی نشانی‌ای می‌خواهد که تغییر نمی‌کند؛ دیگری یک دامنه پخش عمومی گسترده‌شده روی یک پیوند شبکه گسترده می‌خواهد با هر چیزی که از آن نتیجه می‌شود.
کشف محلی قرار است متوقف شود
Multicast DNS که در RFC 6762 توصیف شده است پیرامون یک پیوند طراحی شده است: پرس‌وجوها به گروهی ثابت می‌روند، پاسخ‌ها به همان گروه فرستاده می‌شوند و پروتکل بر این تکیه دارد که هر مشارکت‌کننده همه را بشنود. مسیریاب‌ها آن ترافیک را به طور پیش‌فرض ارسال نمی‌کنند و این یک تصمیم طراحی است نه یک غفلت. این مرز وجود دارد تا دستگاهی در یک ساختمان نتواند به سادگی خود را در ساختمانی دیگر اعلام کند. تونلی که به نظر می‌رسد با حمل گروه در همه‌جا کشف را درست می‌کند، آن مرز را برای هر برنامه‌ای برداشته است، نه فقط برای برنامه‌ای که به کمک نیاز داشت.
تکرارکننده‌ها و بازتاب‌دهنده‌ها وجود دارند و سرویس‌های واقعی با پیامدهای واقعی‌اند: هر نامی که در یک سایت اعلام شود در سایت دیگر دیده می‌شود، از جمله نام دستگاه‌هایی که افراد یا تجهیزات را مشخص می‌کنند. اگر نیاز واقعی این است که یک سرویس خاص قابل یافتن باشد، یک رکورد سرویس منتشرشده در DNS معمولاً تغییر کوچک‌تری است و یک نام را آشکار می‌کند نه جریانی از نام‌ها.
سه چیزی که چندپخشی مسیریابی‌شده لازم دارد
چندپخشی مسیریابی‌شده به سه چیز نیاز دارد که با هم کار کنند: گیرنده‌هایی که به گروه می‌پیوندند، مسیریاب‌هایی که برای آن وضعیت ارسال نگه می‌دارند و تونلی که نشانی‌های گروه را ترافیکی برای حمل می‌داند. تونلی با سیاستی که فقط زیرشبکه‌های یونیکست را فهرست می‌کند ترافیک گروه را در مرز رمزنگاری دور می‌ریزد، و به همین دلیل نخستین نشانه اغلب سکوت است نه خطا. یک رابط مبتنی بر مسیر مانند تونل GRE یا VTI هر چه جدول مسیریابی به آن بفرستد حمل می‌کند و همین گروه را به محض وجود وضعیت چندپخشی قابل دسترس می‌کند.
قابلیت دسترسی منبع نیمه دوم است. پروتکل‌های مسیریابی چندپخشی مانند PIM درخت‌های توزیع را با بررسی اینکه مسیر بازگشت به منبع همان مسیر مورد انتظار است می‌سازند، پس مسیر یونیکستی که جای دیگری را نشان می‌دهد درخت را می‌شکند حتی وقتی عضویت گروه درست است. نصب یک مسیر برای گیرنده برای آن بررسی کاری نمی‌کند و این همان اشتباهی است که پینگ سالم و جریان ناسالم می‌سازد. نخست مسیر بازگشت منبع را بررسی کنید، سپس عضویت را اضافه کنید و تنها بعد به برنامه نگاه کنید.
ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20دو خط نخست نشان می‌دهند میزبان به چه چیزی پیوسته و هسته چه چیزی را ارسال می‌کند، خط سوم عضویت خود برنامه را نشان می‌دهد و خط آخر مسیر یونیکستی را که بررسی مسیر معکوس استفاده خواهد کرد. خواندن آنها با هم برنامه‌ای را که هرگز نپیوسته از شبکه‌ای که هرگز ارسال نکرده جدا می‌کند.
آن را با یک منبع و یک گیرنده ثابت کنید
پیش از دست زدن به یک پیکربندی تأیید کنید که برنامه در یک قطعه واحد کار می‌کند. اگر به صورت محلی شکست بخورد، مسیریابی چندپخشی مشکل نیست و هیچ تغییری در تونل کمکی نمی‌کند. سپس با یک گیرنده از طریق تونل تکرار کنید و بسته‌ها را در دو سوی مرز رمزنگاری ببینید.
tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'بسته‌هایی که درون تونل دیده می‌شوند اما بیرون آن غایب‌اند به کپسوله‌سازی یا سیاست اشاره می‌کنند؛ بسته‌هایی که در دو سو دیده می‌شوند اما برنامه پیشرفتی ندارد به عضویت گیرنده یا اتصال برنامه اشاره می‌کنند. ضبط‌ها را کوتاه و پالایش‌شده نگه دارید، چون ضبط گسترده چندپخشی در یک قطعه شلوغ بیشتر نویز است.
وقتی فقط به سرویس نیاز دارید، نشانی سرویس را ترجیح دهید
کشف برای یافتن چیزی که جابه‌جا می‌شود وجود دارد. سروری با نام پایدار به کشف نیاز ندارد و یک نشانی مستند در DNS خصوصی به پرسش واقعی کاربر پاسخ می‌دهد بدون اینکه دامنه پخش عمومی را روی پیوند شبکه گسترده بگستراند. همین استدلال برای چاپگرها، لوازم و سرویس‌های وب داخلی هم صادق است. یک نام در DNS از هر سایتی که به آن نیاز دارد قابل دسترسی است بی‌آنکه چیزی به سایت‌هایی که نیاز ندارند اعلام کند، و هنگامی که دستگاه با دستگاهی با نشانی متفاوت جایگزین شود به کار خود ادامه می‌دهد.
وقتی پروتکلی واقعاً به چندپخشی نیاز دارد، آن را به گروه و سایت‌هایی که نیاز دارند محدود کنید، دلیل را مستند کنید و هرگاه برنامه تغییر کرد تصمیم را بازبینی کنید. گستردن کشف به همه‌جا یک بار آسان است و پس از یک سال دستگاه‌هایی که بی‌صدا به آن وابسته‌اند دشوار.