OpenVPN multicast ہر کلائنٹ کو بھیجتا ہے، سبسکرائبرز کو نہیں

"multicast کی حمایت کرتا ہے" پروٹوکول کے سوال کا جواب دیتا ہے اور صلاحیت کے سوال کو اچھوتا چھوڑ دیتا ہے۔ عملی طور پر اہم یہ ہے کہ سرور ایک گروپ پیکٹ کے لیے کتنی نقلیں بھیجتا ہے اور کون سی ٹنلیں انہیں لے کر جاتی ہیں۔ اسٹریم وصول کرنے والی ایک سبسکرائب شدہ ایپلیکیشن صرف یہ ثابت کرتی ہے کہ ترسیل کہیں کام کرتی ہے۔ یہ ثابت نہیں کرتی کہ غیر دلچسپی رکھنے والے کلائنٹس کو بینڈوتھ بچ گئی۔

ایک فیچر کے دعوے کے اندر تین سوال

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

لنک کا حجم طے کرتے وقت انہیں الگ رکھیں۔ سرور کی طرف سے باہر جانے والا بجٹ صرف تیسرا سوال طے کرتا ہے۔

یوزر اسپیس سرور گروپ پیکٹ کے ساتھ کیا کرتا ہے

روایتی OpenVPN 2.6 یوزر اسپیس سرور میں، آنے والا براڈکاسٹ یا multicast پیکٹ TUN/TAP کے اندراجی راستے میں درجہ بند ہوتا ہے اور فی گروپ تلاش کے بجائے براڈکاسٹ پھیلاؤ کے معمول کو دیا جاتا ہے۔ وہ معمول کلائنٹ مثالوں سے گزرتا ہے، بھیجنے والے اور کسی بھی روکی گئی مثال کو چھوڑ دیتا ہے، جہاں VLAN ترتیب دیا گیا ہو وہاں اپنی جانچ لاگو کرتا ہے، اور باقی ہر کلائنٹ کے لیے ایک نقل قطار میں رکھتا ہے۔ اس لوپ کا کوئی بھی مرحلہ رکنیت کی میز سے نہیں پوچھتا۔ یہ براڈکاسٹ طرز کی نقل ہے، اور پورا طریقہ کار یہی ہے۔

اسے اس کوڈ راستے کی خصوصیت سمجھیں، عالمگیر قانون نہیں۔ تیز رفتار ڈیٹا راستے، دیگر نفاذ اور مختلف ورژن مختلف برتاؤ کر سکتے ہیں، اور ان میں سے کوئی بھی TAP کو ضرورت یا مرمت نہیں بناتا۔

کچھ ناپنے سے پہلے نقلوں کا بجٹ بنائیں

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

ip -s link show tun0

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

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

دو کلائنٹس کا ٹیسٹ جو دائرے کا سوال طے کرتا ہے

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

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

پھر کردار بدلیں۔ اگر نتیجہ گروپ کے بجائے وصول کنندہ کے پیچھے چلے، تو آپ رکنیت کو مدنظر رکھنے والی چیز دیکھ رہے ہیں، اور پہلے کا مفروضہ آپ کے حق میں غلط تھا۔

حدود ہٹانے کے بجائے محدود ڈیزائن چننا

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

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

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