یک حساب VPN محلی را بدون از دست دادن مجوزهایش بچرخانید
حسابهای VPN محلی مجوزهایی دارند که حذف و ایجاد دوباره آنها را پاک میکند. چرخش درجا را با بازسازی مقایسه کنید، سپس بررسی کنید CHAP واقعاً چه چیزی را میتواند هش کند.
جایگزینی یک گذرواژه VPNِ کارآمد شبیه تغییری دوخطی به نظر میرسد، تا وقتی حساب بازسازیشده با مجوزهای پیشفرض بازمیگردد و تنها نشست مدیریت از دست رفته است. رویه امن به این بستگی دارد که اعتبارنامه کجا ذخیره میشود و کدام پروتکل آن را مصرف میکند، نه به اینکه کدام فرمان کوتاهتر است. پیش از دست زدن به دستگاه، دو رویکرد را مقایسه کنید. چرخش درجا شیء حساب را حفظ میکند؛ حذف و ایجاد دوباره آن را جایگزین میکند و هر چیزی که به آن اشاره میکرد با آن از میان میرود.
پیدا کنید کدام انبار واقعاً نشست را احراز هویت میکند
از پروفایل تونل یا اتصال شروع کنید، نه از پایگاه داده کاربران. پروفایل یک روش احراز هویت و اغلب یک گروه سرور را نام میبرد، و اگر آن گروه به RADIUS یا TACACS+ اشاره کند، نام کاربری محلی روی دستگاه فقط تزیین است. پیش از برنامهریزی برای هر چیزی، فهرست احراز هویت پروفایل و گروه AAA را که به آن ارجاع میدهد بخوانید. تنها وقتی پروفایل میگوید محلی، حساب روی دستگاه اهمیت دارد. این را اشتباه کنید و اعتبارنامهای را میچرخانید که هیچکس استفاده نمیکند، در حالی که ورودی واقعی دایرکتوری دقیقاً همانطور که بود میماند.
همان دستگاه معمولاً دو جمعیت را نگه میدارد: مدیرانی که به آن وارد میشوند و کاربران VPN که تونلی را پایان میدهند. آنها میتوانند یک انبار را شریک شوند و نباید فرض کرد که چنین میکنند.
بهروزرسانی درجا در برابر حذف و ایجاد دوباره
چرخش درجا یک ویژگی از یک شیء موجود را تغییر میدهد. سطح دسترسی، عضویت گروهی، ویژگیهای مجوز و هر سیاستی که به حساب ارجاع میدهد زنده میمانند، چون چیزی حذف نشده است. حذف و ایجاد دوباره شیء را از خط فرمان بازسازی میکند، پس هر فیلدی که تکرار نکردهاید با مقدار پیشفرض خود بازمیگردد. روی دستگاهی که ویژگیهای هر کاربر تخصیصهای تونل شکافته یا استخر نشانی را حمل میکند، همان تفاوت تمام خطر است.
بازسازی یک کاربرد مشروع دارد: وقتی خودِ قالب ذخیرهشده باید تغییر کند و پلتفرم هیچ تبدیلی ارائه نمیدهد. حتی در آن صورت، نخست ورودی موجود را ثبت کنید، چون پیکربندی در حال اجرا تنها فهرست دقیق چیزی است که حساب حمل میکرد. رونوشتی از آن پیکربندی که پیش از تغییر گرفته شده باشد از یک برنامه بازگردانی که از حافظه نوشته شده بهتر است.
چرا هشی که دارید ممکن است همان رازی نباشد که لازم دارد
قالبهای ذخیرهسازی به شکلی تفاوت دارند که پاسخ را تعیین میکند. هش یکطرفه میتواند گذرواژه را وقتی سرور آن را بهصورت واضح داخل تونل دریافت میکند تأیید کند، اما روش چالش-پاسخ برای محاسبه خلاصه به خودِ راز مشترک نیاز دارد. از اینرو تبدیل هر حساب به قویترین قالب یکطرفه میتواند CHAP یا MS-CHAP را دقیقاً برای کاربرانی بشکند که به آن وابستهاند.
بر اساس پروتکل تصمیم بگیرید، نه بر اساس شعار. جایی که روش به راز قابل بازیابی نیاز دارد، آن نیازمندی یک محدودیت در طراحی است و نه یک غفلت برای پاکسازی.
نشستهایی که از اعتبارنامه بیشتر عمر میکنند
تغییر یک اعتبارنامه نشستهایی را که پیشتر احراز هویت شدهاند پایان نمیدهد. همتایی با تونل برپاشده تا تجدید کلید، احراز هویت دوباره یا قطع اتصال صریح به کار ادامه میدهد.
آن بخش را جداگانه برنامهریزی کنید و پیش از تغییر برنامهریزی کنید. اگر اعتبارنامه نشت کرده باشد، زنده نگه داشتن نشستها چرخش را بیاثر میکند. اگر فقط کهنه شده باشد، وادار کردن هر همتا به آفلاین یک قطعی بود که به آن نیاز نداشتید. در حین کار یک مسیر مدیریت دوم باز نگه دارید، ترجیحاً مسیری که به حسابی که ویرایش میشود وابسته نباشد، چون حالت شکست اینجا دسترسی شما را دقیقاً وقتی لازمش دارید برمیدارد. سپس یک ورود تازه و منابعی را که میتواند به آنها برسد بررسی کنید.
ثابت کنید مجوزها زنده ماندند
بهعنوان کاربر چرخاندهشده وارد شوید و بررسی کنید نشست چه چیزی میدهد، نه فقط اینکه باز شده است. به منبعی برسید که به مجوزی نیاز دارد که حساب باید حمل کند، و یکی را امتحان کنید که نباید به آن برسد. ورود موفق با دسترسی تنگتر یا گستردهتر یک تغییر ناموفق است.
ویژگیهای مجوز در پیکربندی در حال اجرا را با رونوشتی که در آغاز گرفتید مقایسه کنید. به عضویت گروهی، استخر نشانی، تنظیمات DNS و تونل شکافته و هر شیء سیاستی که حساب را نام برده بود نگاه کنید. سپس سابقه محل زندگی آن اعتبارنامه را بهروز کنید، چون چرخش بعدی از همان یادداشت آغاز میشود. چرخشی که هیچکس نتواند از مستندات تکرارش کند فقط یک بار از سر گذرانده شده است.