مهاجرت VPN: مجوزها، قابلیت‌ها و سیاست در یک سند
یک نشست فعال روی دروازه قدیمی هیچ چیزی درباره دروازه جدید ثابت نمی‌کند. پیش از تغییر، پلتفرم، حق، قابلیت‌ها و سیاست اعمال‌شده را ثبت کنید.
نشست‌هایی که هنوز روی متمرکزکننده قدیمی کار می‌کنند، شبیه شاهدی بر این هستند که مهاجرت تقریباً تمام شده است. اما آن‌ها فقط یک قلم از فهرست دارایی‌ها هستند، و کم‌جذاب‌ترین قلم. آنچه تغییر به آن نیاز دارد سندی است که دروازه مقصد، کلاینت پشتیبانی‌شده، حق خریداری‌شده و سیاست پذیرش اعمال‌شده را در یک مصنوع واحد که کسی مالک آن است به هم پیوند دهد. بدون آن، مهاجرت رشته‌ای از فرض‌ها است که هر یک به‌تنهایی معقول به نظر می‌رسد.
چهار ستون، نه یک فهرست بازبینی
آنچه سخت‌افزار می‌تواند حمل کند، آنچه قرارداد اجازه می‌دهد و آنچه مجموعه قواعد می‌پذیرد سه پرسش جداست، و آمیختن آن‌ها طرحی می‌سازد که هیچ‌کس نمی‌تواند آن را بررسی کند. آن‌ها را در ستون‌های جدا نگه دارید و بگذارید هر یک منبع خود را ذکر کند. دستگاهی که اتصال را می‌پذیرد ثابت می‌کند که دستگاه می‌تواند متصل شود، و این هیچ چیزی درباره دامنه قابلیت‌ها یا مبنای شمارش توضیح نمی‌دهد. سه ستونی که با هم اختلاف دارند بسیار سودمندتر از یک بند هستند که مطمئن به نظر می‌رسد.
سند زمانی کامل می‌شود که هر چهار ستون را کسی پر کند که حق پر کردن آن‌ها را دارد. ستونی که مالک نادرست امضایش کرده، شایعه‌ای است با تاریخ روی آن.
پلتفرم و حق
دروازه پشتیبانی‌شده، سیستم‌عامل‌های کلاینت، مسیر احراز هویت و ابزارهای مدیریت را ثبت کنید. کلاینت منسوخ را فقط به این دلیل که نمایه قدیمی‌اش هنوز باز می‌شود زنده نگه ندارید، چون آن نمایه ادعای سازگاری است که فروشنده ممکن است دیگر آن را رعایت نکند. بیانیه پشتیبانی فعلی را با نسخه‌ای که قصد استقرارش را دارید بسنجید.
برای حق، محصول، نوع مجوز، مدت و مبنای شمارش را ثبت کنید و سپس آن را از طریق مالک حساب تطبیق دهید. استنتاج حقوق از یک شمارنده نشست تاریخی همان روشی است که سازمان کمبود را پس از تغییر کشف می‌کند، نه پیش از آن.
راهنماهای سفارش فروشندگان نشان می‌دهند چرا این تمایزها مهم‌اند. برای نمونه، راهنمای سفارش Secure Client از Cisco سطوح Advantage، Premier و VPN Only را جدا می‌کند، هر یک با سنجه و دامنه قابلیت خودش. از توافق فعلی استفاده کنید، نه اینکه برچسبی قدیمی را مکانیکی ترجمه کنید.
قابلیت‌ها و سیاست اعمال‌شده
توانمندی‌هایی را که استقرار واقعاً نیاز دارد فهرست کنید: حالت‌های مجاز تونل، ارزیابی دستگاه، یکپارچه‌سازی احراز هویت و هر ماژول دیگر. پشتیبانی و حق را برای هر یک جداگانه بررسی کنید، چون یک قابلیت می‌تواند پشتیبانی‌شده و بدون مجوز باشد، یا مجوزدار و در نسخه انتخاب‌شده پشتیبانی‌نشده. تنها ردیفی که به هر دو پرسش بله بگوید به حساب می‌آید.
وقتی مقصد یک ASA است، ستون قابلیت‌ها از خود دستگاه خوانده می‌شود نه از قرارداد، پس دروازه را پیش از روز تغییر ثبت کنید. show vpn-sessiondb summary فهرست نشست‌های زنده و شمارش‌هایی را می‌دهد که حق شما با آن سنجیده می‌شود، show vpn-sessiondb detail anyconnect نشان می‌دهد هر نشست نسبت‌داده‌شده در عمل از کدام نوع کلاینت و نمایه استفاده کرده است، و show running-config webvpn پیکربندی دروازه‌ای را ثبت می‌کند که آن نشست‌ها به آن وابسته‌اند، و این تنها بخشی از سند است که هیچ مدرک مجوزی نمی‌تواند در خود داشته باشد.
show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpnپس از تغییر، همان سه دستور را روی دروازه جدید اجرا کنید و با نسخه‌های ثبت‌شده مقایسه کنید. جابه‌جایی شمارش نشست‌ها انتظار می‌رود؛ نوع کلاینت یا بلوک webvpn که در یک سو پیدا شود و در سوی دیگر نباشد یافته است، و جای آن در سند با توضیح است نه در توضیح یک تیکت. هم ثبت خام و هم تفاوت‌ها را نگه دارید، چون بازبین بعدی می‌خواهد ببیند چه چیزی مقایسه شده است. نزد فروشنده دیگر، معادل همان جدول نشست و برون‌بری نمایه‌های آن پلتفرم است، در قالبی که هم‌تراز نخواهد شد، پس پرسش‌هایی را که از آن می‌پرسید مقایسه کنید نه متن را.
سپس کاربران و دستگاه‌ها را به قواعد مقصد، مجوزهای منابع و رفتار رد نگاشت کنید. مجوزی که قابلیتی را ممکن می‌کند پیکربندی‌ای نیست که آن را اعمال کند، و شکاف میان این دو جایی است که بیشتر غافلگیری‌های مهاجرت زندگی می‌کنند.
موارد رد را با همان دقتی بنویسید که موارد مجاز را. طرحی که تنها ثابت می‌کند یک مدیر می‌تواند متصل شود، آسان‌ترین مسیر را آزموده و هیچ‌یک از مرزها را نه.
در هر دو سوی تصمیم بپذیرید
پیش از تغییر، یک طرح پذیرش تأییدشده را روی انواع کلاینت موردنظر، روش‌های احراز هویت و منابع اجرا کنید. دستگاهی یا هویتی را بگنجانید که باید رد شود، و تأیید کنید کدام قاعده آن را برگزید و نشست حاصل به کجا می‌تواند برسد. موارد رد را پیش از باز شدن پنجره تغییر توافق کنید تا کسی نتواند آن‌ها را زیر فشار زمان بی‌صدا حذف کند. طرحی بدون مورد رد، مسیر خوش‌بینانه را آزموده و هیچ چیز دیگر.
مسیر بازگشت و مسیر مدیریتی را نگه دارید که به چیزی که مهاجرت می‌کند وابسته نباشد. پیکربندی و سوابق هویت را امن نگه دارید، و تنظیمات رمزنگاری منسوخ را پشت سر بگذارید نه اینکه با خود به جلو ببرید. هرگز شناسه‌های مجوز یا سوابق کاربران را در یادداشت‌های عمومی جای ندهید.
بگذارید مالک حق و نگاشت سیاست را با هم امضا کند. سند کامل به دو پرسش هم‌زمان پاسخ می‌دهد: سازمان برای استقرار چه چیزی مجوز دارد، و کدام قواعد در عمل کاربرانش را می‌پذیرند و محدود می‌کنند.