VPN لاگ اِن انتباہات: انہیں اصل میں کون سا واقعہ متحرک کرنا چاہیے؟
تصدیق کی کامیابی، قائم شدہ ٹنل اور RADIUS accounting Start تین مختلف دعوے ہیں۔ وہ دعویٰ منتخب کریں جس پر آپ کا وصول کنندہ عمل کر سکے، پھر انہیں باہم منسلک کریں۔
تصدیق کی کامیابی، قائم شدہ ٹنل اور RADIUS accounting Start تین مختلف دعوے ہیں، اور لاگ اِن ای میل کا مطلب تب ہی ہوتا ہے جب آپ ان میں سے ایک منتخب کریں۔ زیادہ تر VPN انتباہی ڈیزائن تینوں کو ملا دیتے ہیں اور ایسا اِن باکس بناتے ہیں جس پر کوئی بھروسا نہیں کرتا۔ فیصلہ اس بات پر منحصر ہے کہ انتباہ کون پڑھتا ہے اور اگلے پانچ منٹ میں وہ کیا کر سکتا ہے۔ اگر یہ غلط ہو تو انتباہ ایسا شور بن جاتا ہے جو اُس واحد واقعے کو چھپا دیتا ہے جس کی آپ کو ضرورت تھی۔
تین سوال محرک کا تعین کرتے ہیں
پوچھیں کہ یہ کس کو ملے گا، وہ کیا کرے گا، اور کارروائی کتنی تیزی سے ہونی چاہیے۔ اسناد کے غلط استعمال پر نظر رکھنے والی سکیورٹی ٹیم ایک اکاؤنٹ سے چند منٹوں میں ناکامی اور پھر کامیابی کا نمونہ چاہتی ہے۔ صلاحیت پر نظر رکھنے والی آپریشنز ٹیم لاگ اِن نہیں بلکہ سیشن کی مدت اور منقطع ہونے کی وجوہات چاہتی ہے۔ ہیلپ ڈیسک سیشن کی شناخت چاہتا ہے تاکہ اسے ٹکٹ سے ملا سکے۔
یہ جوابات مختلف واقعات کی طرف اشارہ کرتے ہیں، اور کوئی ایک قاعدہ تینوں کو پورا نہیں کرتا۔ اگر وصول کنندہ کی کارروائی «صارف کو فون کرو» ہے تو تصدیق کافی ہے۔ اگر کارروائی «لائسنس جاری کرو» یا «تصدیق کرو کہ ٹنل نے ٹریفک منتقل کیا» ہے تو صرف قیام یا accounting Start کارآمد ہوگا۔ اگر کارروائی «وقت کا بل بناؤ» ہے تو آپ کو لاگ اِن کے بجائے Stop ریکارڈز درکار ہوں گے۔
کچھ بھی کنفیگر کرنے سے پہلے جواب ایک جملے میں لکھیں۔ «یہ ای میل آن کال انجینئر کو بتاتی ہے کہ اکاؤنٹ X نے وقت Z پر نیٹ ورک Y سے ٹنل کھولی، تاکہ وہ جانچ سکے کہ دیکھ بھال کی ونڈو استعمال ہوئی یا نہیں۔» اگر آپ ہر خانہ نہیں بھر سکتے تو محرک ابھی منتخب نہیں ہوا۔
واقعے کو اُس دعوے سے ہم آہنگ کریں جو آپ کر رہے ہیں
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
جدول ایک انحصار چھپاتا ہے: ہر قطار تب ہی قابلِ اعتماد ہے جب گیٹ وے اسے قابلِ اعتماد طریقے سے جاری کرے اور آپ کا جمع کنندہ مطلوبہ فیلڈ محفوظ رکھے۔ آپ جو عین ورژن چلا رہے ہیں اُس کے لیے واقعے کی تعریف پڑھیں، کیونکہ «سیشن قائم ہوا» نام ورژنوں کے درمیان بدلتا ہے اور مفہوم نام سے زیادہ بار بدلتا ہے۔ جب تعریف مبہم ہو تو لیبل سے اندازہ لگانے کے بجائے سیشن کیپچر طلب کریں۔
Access-Accept کو اس کے بعد آنے والی ہر چیز کی تکمیل سمجھنا سب سے عام غلطی ہے۔ یہ اسناد کے بارے میں فیصلہ ہے، سیشن نہیں۔ اُلٹی غلطی پالیسی کی مطابقت کو اجازت کا ثبوت پڑھنا ہے، جبکہ قاعدہ مطابقت رکھ سکتا ہے اور اگلا مرحلہ پھر بھی ناکام ہو سکتا ہے۔
ایک سیشن، ایک اطلاع
ایک اکاؤنٹ، کئی آلات، دوبارہ ارسال اور دوبارہ اتصال: ہر واقعے پر ایک ای میل دونوں سمتوں میں غلط ہوگی، ایک سیشن کی نقل کرے گی اور دوسرے کو تقسیم کرے گی۔ اطلاع کی کلید گیٹ وے کے ساتھ سیشن شناخت کنندہ پر رکھیں، اور اکاؤنٹ کے نام کو کلید نہیں بلکہ خصوصیت سمجھیں۔ لیپ ٹاپ اور فون رکھنے والا صارف بیک وقت دو ٹنل رکھ سکتا ہے، اور دونوں اپنی الگ سطر کے حقدار ہیں۔
دوبارہ ارسال شدہ اکاؤنٹنگ ریکارڈز معمول ہیں، اس لیے پیغام دکھانے سے پہلے سیشن آئی ڈی اور ٹائم اسٹیمپ پر نقول ہٹائیں۔ ایک ہی ڈیوائس کے مسلسل سیشن الگ رہنے چاہئیں، اور دیکھ بھال کی ونڈو کے دوران دوبارہ اتصال پچھلے میں ضم ہونے کے بجائے نظر آنا چاہیے۔ اگر آپ کا جمع کنندہ حصول کے وقت ٹائم اسٹیمپ دوبارہ لکھتا ہے تو نقول محفوظ فیلڈز کی بجائے اصل ریکارڈ کے فیلڈز کی بنیاد پر ہٹائیں۔
Stop ریکارڈ کا نہ ہونا غیر یقینی صورتحال ہے، مستقل سیشن نہیں۔ گیٹ وے کی ری بوٹ، جمع کنندہ کی خرابی اور UDP کا ضیاع سب خلا چھوڑتے ہیں، اس لیے انتباہ کو ایسا مصالحتی راستہ درکار ہے جو کسی کے یہ نتیجہ اخذ کرنے سے پہلے کہ ٹنل اب بھی چل رہی ہے، زندہ سیشن جدول سے پوچھے۔
آڈٹ اور اطلاع کو الگ رکھیں
آڈٹ اسٹریم اور انتباہی اسٹریم کے کام مختلف ہیں۔ خام ریکارڈز محفوظ رکھیں، بشمول اکاؤنٹ، گیٹ وے، سیشن آئی ڈی، ٹائم اسٹیمپ اور اختتام کی وجہ، حتیٰ کہ جب معمول کی ای میلیں گروپ کی جائیں، دبائی جائیں یا چھوٹی آن کال فہرست پر بھیجی جائیں۔ شدت کی حد ترسیل کا فلٹر ہے، اُس زندگی چکر کے واقعے کا انتخاب نہیں جس کا آپ اعلان کرنا چاہتے تھے۔
محفوظ ریکارڈ تلاش کرنے کے لیے وصول کنندہ کو درکار کم سے کم سیاق بھیجیں۔ اکاؤنٹ کے نام، داخلی پتے اور سیشن کی تفصیلات حساس ہیں، اور جو ای میل اچھی طرح فارورڈ ہوتی ہے وہی اچھی طرح لیک ہوتی ہے۔
پھر اسے شروع سے آخر تک ثابت کریں۔ معمول کا لاگ اِن اور لاگ آؤٹ، ایک دوبارہ اتصال، بیک وقت دو سیشن اور ایک جبری ترسیلی ناکامی چلائیں، اور گیٹ وے سے جمع کنندہ کے ذریعے پہنچائے گئے پیغام تک ایک واقعہ کا سراغ لگائیں۔ اگر ای میل سیشن آئی ڈی کے بغیر آئے تو معاہدہ نامکمل ہے۔ اگر دو ای میلیں ایک سیشن بیان کریں تو باہمی تعلق ٹوٹا ہوا ہے۔ جب آپ صرف یہ جانچیں کہ میل کی ترسیل کام کرتی ہے تو یہ دونوں مسائل ظاہر نہیں ہوتے۔