RADIUS اکاؤنٹنگ اور کامیاب لاگ اِن: ہر ایک کیا ثابت کرتا ہے

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

دو مختلف سوال

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

وہ ایک ہی پروٹوکول پر اور عام طور پر ایک ہی سرور تک جاتے ہیں، اور اسی لیے لوگ سمجھتے ہیں کہ ایک دوسرے کا مطلب ہے۔

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

تین ریکارڈ اقسام کیا دیتی ہیں

Start ریکارڈ سیشن کھولتا ہے، Interim-Update کھلا رہنے کے دوران سرگرمی بتاتا ہے، اور Stop اسے بند کرتا ہے۔ تینوں سیشن شناخت کنندہ رکھتے ہیں تاکہ وصول کنندہ انہیں ایک ہی خدمت واقعے سے جوڑ سکے۔

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

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

صارف نام سیشن کیوں نہیں ہے

ایک شخص صبح لیپ ٹاپ سے اور دوپہر فون سے جڑتا ہے، اور دونوں سیشن ایک ہی اکاؤنٹ نام رکھتے ہیں۔ مناسب Stop کے بغیر آنے والا Start، نام ڈھونڈ کر سب سے پرانی کھلی قطار چن کر بند نہیں کیا جا سکتا۔

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

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

PAM کہاں فٹ ہوتا ہے اور کہاں نہیں

OpenVPN کا تصدیقی پلگ اِن PAM کے تصدیق اور اکاؤنٹ انتظام کے مراحل کو کال کرتا ہے۔ اکاؤنٹ مرحلہ اہلیت جانچتا ہے؛ اس کے نام کا مطلب استعمال کی اکاؤنٹنگ نہیں، اور پلگ اِن PAM کے سیشن کھولنے اور بند کرنے کے ہک نہیں چلاتا۔

کچھ PAM RADIUS ماڈیول ان سیشن ہکوں کے ذریعے اکاؤنٹنگ ریکارڈ بھیج سکتے ہیں، اور یہ صرف اس وقت کام کرتا ہے جب ایپلیکیشن واقعی انہیں کال کرے۔

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

ایک قبولیتی دوڑ جو معاہدہ ثابت کرتی ہے

ایک عام کنکٹ اور ڈس کنکٹ جانچیں، پھر اسی اکاؤنٹ کے تحت دوبارہ کنکٹ، پھر ایسا کلائنٹ جو ڈس کنکٹ کیے بغیر غائب ہو جائے۔

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

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