ترحيل VPN من IOS إلى ASA: ترجم الاتفاق لا واجهة الأوامر
خريطة التشفير ليست مجموعة أنفاق ASA. أي أجزاء الاتفاق تنتقل، وأيها يجب إعادة بنائه، والفحوص التي تثبت أن الخدمة تعمل.
يمثل إعداد IOS الذي يصل كمرجع لترحيل إلى ASA اتفاقاً ملفوفاً بصياغة منصة واحدة. عناوين الأقران والهويات والنطاقات المحمية هي الاتفاق. حلقة المفاتيح والملف وخريطة التشفير هي طريقة IOS في التعبير عنه، بينما تعبّر ASA عن النية نفسها عبر مجموعات الأنفاق وسماتها. نسخ الجزء الثاني لا ينجح أبداً، ونسخ الأول وحده يترك العمل نصف منجز.
اتبع الخطوات الخمس أدناه بالترتيب، وتوقف كلما وصفت المنصتان أشياء مختلفة لا كلمات مختلفة.
الخطوة 1: افصل الاتفاق عن الصياغة
اكتب التسليم كمتطلبات يتفق عليها المسؤولان. أربعة صفوف تغطي معظم ذلك: أين يوجد القرين وأي جانب يبدأ، وكيف يثبت كل جانب هويته، وما الحماية المقبولة، وأي التطبيقات يجب أن تصمد عبر النفق. ولا يذكر أي من هذه الصفوف أمراً.
احتفظ بالنص الأصلي كدليل لا كتعليمات. السطر الموجود على منصة دون الأخرى هو فرق في الصياغة حتى تتحقق مما إذا كان الشرط نفسه يمكن تلبيته بطريقة أخرى.
| Requirement | What must be agreed |
|---|---|
| Peer delivery | Outer endpoint, address family, NAT view, initiating side |
| Authentication | IKE version, expected identities, credential method and delivery |
| Data protection | Permitted suites, protected ranges, intentional translation |
| Application | Routes, return routes, resources beyond the tunnel |
الخطوة 2: سمِّ الكائنات على كل منصة
على IOS XE تغذي حلقة مفاتيح IKEv2 ملف IKEv2، ويُربط ذلك الملف عبر خريطة تشفير أو ملف IPsec. وعلى ASA تحتفظ مجموعة الأنفاق بملف الاتصال وسمات IPsec الخاصة به، وتشير خريطة التشفير إليه، كما يصف دليل ملف الاتصال ذلك. وهذه رسوم كائنات مختلفة بتوريث مختلف، ولهذا ينتج التطابق سطراً بسطر إعداداً يُحلَّل ولا يتصل.
ابنِ الكائنات الهدف من صفوف المتطلبات لا من أسطر المصدر. إن كانت الصفوف كاملة، فإعداد الهدف قرار تصميمي. وإن لم تكن، فلن توفر أي كمية من ترجمة الأوامر النية المفقودة.
الخطوة 3: انقل الهوية لا العناوين فقط
الهوية هي الجزء الذي ينكسر بهدوء. القرين الذي يصادق بالعنوان يتصرف بشكل مختلف عن الذي يصادق بموضوع الشهادة أو بالاسم المؤهل بالكامل (FQDN)، والمنصتان تسجلان هذا التوقع في موضعين مختلفين. حافظ على الهوية المقصودة وسلسلة الثقة بدلاً من استبدال سر مشترك لأنه أسهل في الاختبار.
أبعد السر المشترك مسبقاً عن ملاحظات المقارنة والتذاكر. سجّل من يملكه وكيف ينتقل عبر قناة معتمدة، وتذكّر أن عنصراً نائباً من مثال توثيقي ليس بيانات اعتماد العميل.
الخطوة 4: اتفق على الحماية قبل التحويل
لا تنقل إعدادات تشفير قديمة لأنها تظهر في النص المقدم. اتفق على تقاطع من المجموعات يدعمه القرينان المنشوران حالياً، وأكّده مع المسؤول الآخر قبل نافذة التغيير. وإن اختلف هذا التقاطع عما يتوقعه القرين الحالي، فهو تغيير منسق لا تعديل محلي.
اكتب المجموعة المتفق عليها. مسؤولان بذاكرتين مختلفتين لمكالمة هاتفية هو كيف يُنتج التحويل عدم تطابق في المرحلة الثانية.
الخطوة 5: تحقق من الخدمة لا من الصياغة
افحص الكائنات الفعلية للهدف أولاً، ثم الجمعية المقبولة، ثم تدفق تطبيق حقيقي وردّه. إدخال أمر دون خطأ يثبت الصياغة ولا شيء غيرها. النفق الذي يظهر ولا يحمل حركة مرور يعني عادةً أن النطاقات المحمية أو مسار العودة يخالف الجانب الآخر، وهذه مشكلة صف متطلبات لا مشكلة أمر. قارن النطاقات المحمية على الجانبين قبل أن تلمس خريطة التشفير مرة أخرى.
سجّل ما تحققت منه، وبأي عناوين، ومن أي جانب. هذا السجل يحوّل ادعاءً غامضاً بأن VPN يعمل إلى شيء يمكن للمسؤول الآخر فحصه باستقلال.
ما يجب إعادته
أرسل مصفوفة المتطلبات وملخصاً لإعداد الهدف ونتائج التحقق. اذكر صراحةً أي إعدادات مصدر لم تنقلها ولماذا. تلك القائمة أنفع من الإعداد المترجم، لأنها حيث سيبدأ الخلاف التالي.
احتفظ بالنص المصدر مع التذكرة أيضاً. فهو يوثق ما طُلب، بينما توثّق المصفوفة ما اتُّفق عليه.