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

ایک ساکٹ، ایک مالک

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

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

What you needMechanism that fitsWhat it cannot do
Periodic list of connected clientsStatus file written on an intervalDeliver events as they happen
Interactive prompts and session controlThe single management connectionServe two controllers at once
Multiple consumers of eitherOne owner process that fans outExist without you writing it

طے کریں کہ کون سا جزو کنٹرول کا مالک ہے

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

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

جمع کرنے والوں کے لیے اسٹیٹس اسنیپ شاٹس استعمال کریں

زیادہ تر مانیٹرنگ کو فہرست چاہیے، گفتگو نہیں۔ ایک وقتاً فوقتاً لکھی جانے والی اسٹیٹس فائل کنٹرول چینل کو چھوئے بغیر اس کا جواب دیتی ہے، اور GUI کے منسلک رہنے کے دوران بھی کام کرتی رہتی ہے۔

status /run/openvpn/server.status 10
management /run/openvpn/server.sock unix

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

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

فین آؤٹ ایک ڈیزائن ہے، موڈ نہیں

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

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

ساکٹ کو استحقاق سمجھیں، میٹرکس نہیں

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

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

متعلقہ مضامین