هشدارهای ورود 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 همگی شکاف باقی می‌گذارند، بنابراین هشدار به مسیری برای تطبیق نیاز دارد که پیش از آنکه کسی نتیجه بگیرد تونل هنوز برپاست، جدول نشست‌های زنده را پرس‌وجو کند.
حسابرسی و اعلان را جدا نگه دارید
جریان حسابرسی و جریان هشدار وظایف متفاوتی دارند. رکوردهای خام را نگه دارید، شامل حساب، دروازه، شناسه نشست، برچسب‌های زمان و دلیل خاتمه، حتی وقتی ایمیل‌های معمول دسته‌بندی، سرکوب یا به فهرست کشیک کوچکی ارسال می‌شوند. آستانه شدت یک فیلتر تحویل است، نه انتخاب رویداد چرخه حیاتی که می‌خواستید اعلام کنید.
حداقل زمینه‌ای را بفرستید که گیرنده برای یافتن رکورد محافظت‌شده لازم دارد. نام حساب‌ها، نشانی‌های داخلی و جزئیات نشست حساس هستند و ایمیلی که خوب ارجاع می‌شود ایمیلی است که خوب نشت می‌کند.
سپس آن را سرتاسر اثبات کنید. یک ورود و خروج عادی، یک اتصال دوباره، دو نشست همزمان و یک شکست تحویل اجباری اجرا کنید و یک رویداد را از دروازه تا جمع‌آورنده و تا پیام تحویل‌شده ردیابی کنید. اگر ایمیل بدون شناسه نشست برسد، قرارداد ناقص است. اگر دو ایمیل یک نشست را توصیف کنند، همبستگی شکسته است. هیچ‌یک از این دو مشکل زمانی ظاهر نمی‌شود که تنها چیزی که آزمایش می‌کنید این است که تحویل ایمیل کار می‌کند.