یک پیکربندی IOS که به‌عنوان مرجع مهاجرت به ASA می‌رسد، توافق‌نامه‌ای را توصیف می‌کند که در نحو یک پلتفرم پیچیده شده است. آدرس‌های همتا، هویت‌ها و محدوده‌های محافظت‌شده همان توافق‌نامه‌اند. حلقه کلید، پروفایل و زنجیره نقشه رمزنگاری شیوه بیان IOS است، در حالی که ASA همان قصد را از طریق گروه‌های تونل و ویژگی‌هایشان بیان می‌کند. کپی کردن بخش دوم هرگز کار نمی‌کند و کپی کردن تنها بخش اول کار را نیمه‌کاره می‌گذارد.

پنج گام زیر را به ترتیب طی کنید و هر جا دو پلتفرم چیزهای متفاوت و نه واژه‌های متفاوت را توصیف می‌کنند توقف کنید.

گام 1: توافق‌نامه را از نحو جدا کنید

تحویل را به‌صورت الزاماتی بنویسید که هر دو مدیر بر آن توافق دارند. چهار ردیف تقریباً همه چیز را پوشش می‌دهد: همتا کجاست و کدام طرف آغاز می‌کند، هر طرف چگونه هویت خود را اثبات می‌کند، چه محافظتی پذیرفتنی است و کدام برنامه‌ها باید از تونل عبور کنند. هیچ‌یک از این ردیف‌ها به فرمانی اشاره نمی‌کند.

متن اصلی را به‌عنوان مدرک نگه دارید، نه دستورالعمل. خطی که روی یک پلتفرم هست و روی دیگری نیست، تا زمانی که بررسی نکنید همان الزام به شیوه دیگری برآورده می‌شود، تفاوت نحوی است.

RequirementWhat must be agreed
Peer deliveryOuter endpoint, address family, NAT view, initiating side
AuthenticationIKE version, expected identities, credential method and delivery
Data protectionPermitted suites, protected ranges, intentional translation
ApplicationRoutes, return routes, resources beyond the tunnel

گام 2: اشیاء را روی هر پلتفرم نام‌گذاری کنید

در IOS XE یک حلقه کلید IKEv2 پروفایل IKEv2 را تغذیه می‌کند و آن پروفایل از طریق نقشه رمزنگاری یا پروفایل IPsec متصل می‌شود. در ASA یک گروه تونل پروفایل اتصال و ویژگی‌های IPsec آن را نگه می‌دارد و نقشه رمزنگاری به آن اشاره می‌کند، همان‌طور که توصیف می‌کند راهنمای پروفایل اتصال. این‌ها نمودارهای شیء متفاوت با وراثت متفاوت‌اند و به همین دلیل نگاشت خط‌به‌خط پیکربندی‌ای می‌دهد که تجزیه می‌شود و متصل نمی‌شود.

اشیاء هدف را از ردیف‌های الزامات بسازید، نه از خطوط منبع. اگر ردیف‌ها کامل باشند، پیکربندی هدف یک تصمیم طراحی است. اگر نباشند، هیچ میزان ترجمه فرمان قصد گمشده را تأمین نمی‌کند.

گام 3: هویت را منتقل کنید، نه فقط آدرس‌ها را

هویت همان بخشی است که بی‌صدا می‌شکند. همتایی که با آدرس احراز هویت می‌کند رفتاری متفاوت از همتایی دارد که با موضوع گواهی یا FQDN احراز هویت می‌کند، و دو پلتفرم آن انتظار را در جاهای متفاوتی ثبت می‌کنند. هویت موردنظر و زنجیره اعتماد را حفظ کنید، به‌جای جایگزین کردن یک راز مشترک چون آزمایش آن آسان‌تر است.

راز مشترک از پیش تعیین‌شده را از یادداشت‌های مقایسه و بلیت‌ها دور نگه دارید. ثبت کنید که مالک آن کیست و چگونه از کانال تأییدشده عبور می‌کند، و به یاد داشته باشید که یک جای‌نگهدار از یک مثال مستندات، اعتبارنامه مشتری نیست.

گام 4: پیش از تغییر، محافظت را توافق کنید

تنظیمات رمزنگاری قدیمی را فقط به این دلیل که در متن ارائه‌شده آمده‌اند منتقل نکنید. بر اشتراک مجموعه‌هایی توافق کنید که هر دو همتای مستقر اکنون از آن پشتیبانی می‌کنند و آن را پیش از پنجره تغییر با مدیر دیگر تأیید کنید. اگر آن اشتراک با آنچه همتای موجود انتظار دارد متفاوت باشد، تغییری هماهنگ‌شده است نه ویرایش محلی.

مجموعه توافق‌شده را بنویسید. دو مدیری که خاطره‌های متفاوتی از یک تماس تلفنی دارند، دلیل آن است که تغییر، ناسازگاری فاز دوم تولید می‌کند.

گام 5: سرویس را بررسی کنید، نه نحو را

ابتدا اشیاء مؤثر هدف را بررسی کنید، سپس انجمن پذیرفته‌شده، سپس یک جریان واقعی برنامه و پاسخ آن. وارد کردن فرمان بدون خطا نحو را اثبات می‌کند و هیچ چیز دیگر. تونلی که بالا می‌آید و ترافیکی حمل نمی‌کند معمولاً یعنی محدوده‌های محافظت‌شده یا مسیر بازگشت با طرف دیگر هم‌خوان نیست، و این مشکلی در ردیف الزامات است نه در فرمان. پیش از دست زدن دوباره به نقشه رمزنگاری، محدوده‌های محافظت‌شده را در دو طرف مقایسه کنید.

ثبت کنید چه چیزی را با کدام آدرس‌ها و از کدام طرف بررسی کردید. آن سابقه ادعای مبهم درباره فعال بودن VPN را به چیزی تبدیل می‌کند که مدیر دیگر می‌تواند مستقل بررسی کند.

چه چیزی را برگردانید

ماتریس الزامات، خلاصه پیکربندی هدف و نتایج بررسی را بفرستید. صریحاً بگویید کدام تنظیمات منبع را منتقل نکردید و چرا. آن فهرست از پیکربندی ترجمه‌شده سودمندتر است، چون اختلاف بعدی از آنجا شروع می‌شود.

متن منبع را هم همراه بلیت نگه دارید. مستند می‌کند چه خواسته شد، در حالی که ماتریس مستند می‌کند بر چه چیزی توافق شد.

مقالات مرتبط