OpenVPN پر SSM: ایک ماخذ اور ایک گروہ کو شروع سے آخر تک ٹریک کرنا

ایک اسٹریم اور ایک وصول کنندہ چنیں، پھر multicast کو بطور زمرہ جانچنے کے بجائے اُس جوڑی کو ہر ہاپ سے گزاریں۔ ماخذ-مخصوص ڈیزائن ٹھیک چار میں سے ایک جگہ ناکام ہوتا ہے: وصول کنندہ کبھی شامل نہیں ہوا، راؤٹر نے پیکٹ کو اس کے واپسی راستے پر مسترد کر دیا، کرنل کے پاس کوئی حالت نہیں، یا ٹنل نے کبھی نقل نہیں پہنچائی۔ اسی ترتیب سے کام کرنا ہر ہاپ پر چند منٹ لیتا ہے اور بتاتا ہے کہ چار میں سے کون سی صورت واقعی آپ کے پاس ہے۔

پہلے ماخذ، گروہ اور وصول کنندہ طے کریں

کسی بھی ڈیوائس کو چھونے سے پہلے تین اقدار لکھیں: بھیجنے والے ماخذ کا پتہ، وہ گروہی پتہ جس میں وصول کنندہ شامل ہوگا، اور وہ ذیلی نیٹ ورک جہاں وصول کنندہ موجود ہے۔ ایک مثال IPv4 اسٹریم کے لیے، 10.50.0.10 ماخذ اور 232.20.30.40 گروہ وہ جوڑی ہے جو ماخذ-مخصوص ڈیزائن کے لیے موزوں ہے۔ ان تین اقدار سے زیادہ مبہم کسی چیز کی جانچ نہیں ہو سکتی۔

232/8 کی حد ماخذ-مخصوص multicast کے لیے مخصوص ہے، اور ماڈل RFC 4607 میں بیان کیا گیا ہے۔ اگر آپ کا گروہ اُس حد سے باہر ہے جبکہ آپ سمجھتے ہیں کہ آپ SSM چلا رہے ہیں، تو رُکیں اور تصدیق کریں کہ تعیناتی کا اصل مقصد کیا ہے، کیونکہ وصول کنندہ کا شامل ہونا اور راؤٹر کا آگے بھیجنے کا فیصلہ دونوں ماڈل کے مستقل ہونے پر منحصر ہیں۔

تصدیق کریں کہ وصول کنندہ ماخذ میں شامل ہوا ہے

صرف گروہ کے لیے رکنیت کی رپورٹ ماخذ-مخصوص شمولیت نہیں ہے۔ وصول کنندہ سے پوچھیں کہ اُس نے کون سا ماخذ طلب کیا، اور پہلی ہاپ کے راؤٹر پر گروہ کی حالت دیکھیں کہ ماخذوں کی فہرست ظاہر ہوتی ہے یا نہیں۔ اگر رپورٹ میں کوئی ماخذ نہ ہو، تو راؤٹر اُسے کسی بھی ماخذ سے شمولیت سمجھے گا اور پورا ڈیزائن خاموشی سے اُس چیز میں بدل جائے گا جس کی آپ نے منصوبہ بندی نہیں کی تھی۔

Linux وصول کنندہ پر جانچیں کہ ساکٹ نے واقعی کس چیز کی رکنیت لی اور کرنل نے کیا ریکارڈ کیا۔ ایپلیکیشن کی کنفیگریشن فائل ثبوت نہیں ہے؛ رکنیت جدول ثبوت ہے۔ اُسے اُس وقت پڑھیں جب وصول کنندہ واقعی چل رہا ہو، کیونکہ اُسے بنانے والے عمل کے ختم ہونے کے بعد بھی اندراج کچھ دیر رہ سکتا ہے۔ پچھلے امتحان کا پرانا اندراج جھوٹے اعتماد کا قابلِ اعتماد ماخذ ہے۔

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

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

ٹنل دیکھنے سے پہلے واپسی راستے کی تصدیق کریں

multicast راؤٹنگ واپسی راستے کی جانچ کرتی ہے، اور جو پیکٹ اُس انٹرفیس کے علاوہ کسی اور انٹرفیس پر آتا ہے جس کی طرف یونیکاسٹ راستہ اشارہ کرتا ہے، اُسے گرا دیا جاتا ہے۔ یہی سب سے عام وجہ ہے کہ واضح طور پر بھیجی جا رہی اسٹریم اگلی ہاپ تک کبھی نہیں پہنچتی، اور اس سے ایپلیکیشن کی سطح پر کوئی مفید خرابی پیدا نہیں ہوتی۔

ماخذ کی طرف دیکھنے والے راؤٹر پر، ماخذ کی طرف کے راستے کا موازنہ اُس انٹرفیس سے کریں جس پر پیکٹ واقعی آتے ہیں۔ وصول کنندہ کی طرف دیکھنے والے راؤٹر پر، وصول کنندہ کے اپنے ذیلی نیٹ کے لیے یہی کریں اور تصدیق کریں کہ باہر جانے والے انٹرفیسوں کی فہرست میں اُس کی طرف کا لنک شامل ہے۔ کسی بھی سمت میں عدم مطابقت RPF ناکامی ہے، رکنیت کی ناکامی نہیں۔

پھر تصدیق کریں کہ ماخذ کا TTL آپ کے ڈیزائن کردہ راؤٹ شدہ ہاپوں سے گزرنے کے لیے کافی بڑا ہے۔ پہلے راؤٹر پر چلنے والی اور دوسرے پر مر جانے والی اسٹریم اکثر TTL کا سوال ہوتی ہے، پالیسی کا نہیں۔

کنفیگریشن کے بجائے کرنل کی multicast حالت پڑھیں

کنفیگریشن بتاتی ہے کہ آپ نے کیا مانگا؛ کرنل بتاتا ہے کہ کیا ہو رہا ہے۔ ہر Linux ہاپ پر، multicast راؤٹنگ کے اندراجات پڑھیں اور تصدیق کریں کہ ماخذ اور گروہ کی عین جوڑی کے لیے آنے اور جانے والے انٹرفیسوں کی فہرست موجود ہے۔ وائلڈ کارڈ ماخذ والے گروہ کا اندراج الگ شے ہے، اور وہ ماخذ-مخصوص بہاؤ کی وضاحت نہیں کرے گا۔

ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10

راؤٹنگ ڈیمون اُس حالت پر اپنا نظریہ رکھتے ہیں، اور اُسے چھاپنے والا کمانڈ اس پر منحصر ہے کہ کون سی عمل درآمد نصب ہے۔ اصول مستقل ہے: ڈیمون سے جوڑی کے لیے اُس کا بالائی اندراج پوچھیں، پھر کرنل سے پوچھیں کہ آگے بھیجنے کا اندراج موجود ہے یا نہیں۔ جو ڈیمون سمجھتا ہے کہ وہ آگے بھیج رہا ہے جبکہ کرنل کے پاس کوئی اندراج نہیں، وہ اُس میزبان پر کنفیگریشن کے دائرے کا مسئلہ ہے۔

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

طے کریں کہ ٹنل واقعی کس طرح نقل بناتی ہے

یہیں VPN پر multicast معمول کا کام رہنا چھوڑ دیتا ہے۔ پوائنٹ ٹو پوائنٹ ٹنل پیکٹ کو دوسرے سرے پر موجود واحد ساتھی تک پہنچاتی ہے، اس لیے ایک نقل بالکل ایک کلائنٹ تک پہنچتی ہے۔ پل سے جڑا حصہ مشترکہ لنک کی طرح زیادہ برتاؤ کرتا ہے، کیونکہ ٹنل فریم لے کر چلتی ہے اور پل طے کرتا ہے کہ کس چیز کو سیلاب کرنا ہے۔ یہ مختلف ترسیلی ماڈل ہیں، اور جو ڈیزائن دوسرے کو فرض کرتا ہے جبکہ پہلا چلا رہا ہے، وہ ایک وصول کنندہ کے لیے کام کرتا دکھائی دے گا اور اگلے کے لیے ناکام ہو جائے گا۔

ملٹی پوائنٹ سرور کے ذریعے ایک سے زیادہ وصول کنندگان کے لیے، نقل کی صریح منصوبہ بندی کرنی ہوگی۔ گیٹ وے پر multicast راستہ نصب کرنا VPN سرور کو نہیں سکھاتا کہ کن ساتھیوں کو نقل ملنی چاہیے، اور کلائنٹ کی طرف کا کوئی راستہ وہ فیصلہ اُس کی بجائے نہیں لیتا۔ جہاں ضرورت بہت سے وصول کنندگان کی ہو، وہاں معاون نقل یا جان بوجھ کر چنا گیا متبادل استعمال کریں، اور لکھیں کہ آپ نے کون سا چنا۔

آخر میں، وصول کنندہ پر تنگ مشاہدے کے تحت تصدیق کریں: عین ماخذ، گروہ اور پورٹ، آپ کے متوقع انٹرفیس پر، جبکہ ایک مجاز وصول کنندہ شامل ہو۔ SSM بھیجنے والے کا انتخاب کرتا ہے، اور یہ انتخاب اُس بھیجنے والے کی توثیق نہیں ہے، نہ ہی دیگر multicast ٹریفک کے لیے اُسی پالیسی سے گزرنے کی اجازت ہے۔