SSM روی OpenVPN: دنبال کردن یک منبع و یک گروه از ابتدا تا انتها

یک جریان و یک گیرنده را انتخاب کنید، سپس آن جفت را از هر گام عبور دهید، به‌جای آزمایش multicast به‌عنوان یک دسته. طراحی مخصوص منبع دقیقاً در یکی از چهار جا شکست می‌خورد: گیرنده هرگز عضو نشد، مسیریاب بسته را در مسیر بازگشت رد کرد، هسته هیچ حالتی ندارد، یا تونل هرگز نسخه‌ای تحویل نداد. کار کردن با این ترتیب برای هر گام چند دقیقه هزینه دارد و به شما می‌گوید کدام یک از آن چهار مورد را واقعاً دارید.

ابتدا منبع، گروه و گیرنده را تثبیت کنید

پیش از لمس هر دستگاهی سه مقدار را بنویسید: نشانی منبعی که ارسال خواهد کرد، نشانی گروهی که گیرنده به آن می‌پیوندد، و زیرشبکه‌ای که گیرنده در آن قرار دارد. برای یک جریان نمونه IPv4، منبع 10.50.0.10 و گروه 232.20.30.40 همان نوع جفتی است که به طراحی مخصوص منبع می‌خورد. هر چیزی مبهم‌تر از این سه مقدار قابل آزمایش نیست.

محدوده 232/8 برای multicast مخصوص منبع رزرو شده است و مدل در RFC 4607 توصیف شده است. اگر گروه شما بیرون از آن محدوده است در حالی که گمان می‌کنید SSM اجرا می‌کنید، بایستید و تأیید کنید که استقرار واقعاً چه قصدی دارد، چون عضویت گیرنده و تصمیم ارسال مسیریاب هر دو به سازگار بودن مدل بستگی دارند.

بررسی کنید که گیرنده به منبع پیوسته است

گزارش عضویت تنها برای گروه، عضویت مخصوص منبع نیست. از گیرنده بپرسید کدام منبع را درخواست کرده است، و در مسیریاب گام اول وضعیت گروه را ببینید تا ببینید فهرست منبع ظاهر می‌شود یا نه. اگر گزارش هیچ منبعی نداشته باشد، مسیریاب آن را عضویت از هر منبعی می‌پندارد و کل طراحی بی‌سروصدا به چیزی که برنامه‌ریزی نکرده بودید تنزل می‌یابد.

روی گیرنده لینوکس بررسی کنید سوکت واقعاً مشترک چه شده و هسته چه ثبت کرده است. فایل پیکربندی برنامه مدرک نیست؛ جدول عضویت مدرک است. آن را زمانی بخوانید که گیرنده واقعاً در حال اجراست، چون یک ورودی ممکن است اندکی پس از خروج فرآیندی که آن را ساخته باقی بماند. ورودی کهنه از آزمایشی قبلی منبع مطمئنی برای اعتماد کاذب است.

ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'

اگر عضویت با منبع مورد انتظار وجود دارد، به مسیریاب‌ها بروید. اگر غایب است، هیچ پیکربندی تونلی کمک نمی‌کند، چون چیزی برای ارسال وجود ندارد.

پیش از نگاه به تونل، مسیر بازگشت را بررسی کنید

مسیریابی multicast یک بررسی مسیر بازگشت انجام می‌دهد و بسته‌ای که روی واسطی جز آنکه مسیر unicast نشان می‌دهد برسد، دور ریخته می‌شود. این رایج‌ترین دلیل آن است که جریانی که آشکارا ارسال می‌شود هرگز به گام بعدی نمی‌رسد، و هیچ خطای سودمندی در سطح برنامه تولید نمی‌کند.

روی مسیریاب رو به منبع، مسیر به سمت منبع را با واسطی که بسته‌ها واقعاً روی آن می‌رسند مقایسه کنید. روی مسیریاب رو به گیرنده، همین کار را برای زیرشبکه خود گیرنده انجام دهید و تأیید کنید که فهرست واسط‌های خروجی پیوند به آن را شامل می‌شود. ناهمخوانی در هر جهت یک شکست RPF است، نه شکست عضویت.

سپس تأیید کنید که TTL منبع به‌قدر کافی بزرگ است تا از گام‌های مسیریابی‌شده‌ای که طراحی کرده‌اید جان سالم به در ببرد. جریانی که روی مسیریاب اول کار می‌کند و روی دومی می‌میرد غالباً پرسشی درباره TTL است نه پرسشی درباره سیاست.

وضعیت multicast هسته را بخوانید نه پیکربندی را

پیکربندی به شما می‌گوید چه خواسته‌اید؛ هسته به شما می‌گوید چه رخ می‌دهد. روی هر گام لینوکس، ورودی‌های مسیریابی multicast را بخوانید و تأیید کنید که برای جفت دقیق منبع و گروه فهرست واسط‌های ورودی و خروجی وجود دارد. ورودی برای گروه با منبع عام یک شیء دیگر است و جریان مخصوص منبع را توضیح نخواهد داد.

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

دیمن‌های مسیریابی دیدگاه خودشان را روی آن وضعیت نگه می‌دارند و فرمانی که آن را چاپ می‌کند به پیاده‌سازی نصب‌شده بستگی دارد. اصل ثابت است: از دیمن ورودی بالادستی‌اش را برای آن جفت بپرسید، سپس از هسته بپرسید آیا ورودی ارسال وجود دارد. دیمنی که گمان می‌کند ارسال می‌کند در حالی که هسته ورودی ندارد، مشکل دامنه پیکربندی روی آن میزبان است.

وقتی این دو ناهمخوان‌اند، میزبان را درست کنید نه VPN را. هیچ چیز در پایین‌دست نمی‌تواند گامی را جبران کند که جریانی را که پرسیدید ارسال نمی‌کند. تا زمانی که جریان کار می‌کند، جفت، واسط ورودی و فهرست خروجی را برای هر گام ثبت کنید. آن ثبت شکست بعدی را به مقایسه تبدیل می‌کند نه پژوهش تازه.

تصمیم بگیرید که تونل واقعاً چگونه تکرار می‌کند

اینجاست که multicast روی VPN از کار روزمره بیرون می‌آید. یک تونل نقطه‌به‌نقطه بسته را به تنها همتای آن سوی دیگر تحویل می‌دهد، پس یک نسخه دقیقاً به یک کارخواه می‌رسد. یک بخش پل‌شده بیشتر مانند یک پیوند اشتراکی رفتار می‌کند، چون تونل قاب را حمل می‌کند و پل تصمیم می‌گیرد چه چیزی را سیل‌آسا بفرستد. این‌ها مدل‌های تحویل متفاوتی هستند و طراحی‌ای که دومی را فرض می‌کند در حالی که اولی را اجرا می‌کند، برای یک گیرنده کار می‌کند و برای بعدی شکست می‌خورد.

برای بیش از یک گیرنده از طریق یک سرور چندنقطه‌ای، تکرار باید صریحاً طراحی شود. نصب یک مسیر multicast روی دروازه به سرور VPN نمی‌آموزد کدام همتاها باید نسخه بگیرند و هیچ مسیری در سمت کارخواه آن تصمیم را به‌جای آن نمی‌گیرد. جایی که نیاز به گیرنده‌های زیاد است، از تکرار پشتیبانی‌شده یا جایگزینی که آگاهانه انتخاب شده استفاده کنید و بنویسید کدام را برگزیدید.

در پایان، روی گیرنده با مشاهده‌ای محدود بررسی کنید: منبع، گروه و درگاه دقیق، روی واسطی که انتظار دارید، در حالی که یک گیرنده مجاز عضو است. SSM یک فرستنده را انتخاب می‌کند و انتخاب، احراز هویت آن فرستنده نیست و نه اجازه عبور ترافیک multicast دیگر از همان سیاست.