failback في ASA: ما الذي يتحرك فعلا عند عودة المسار
عودة المسار إلى الأساسي لا تعني أن التدفقات القديمة انتقلت. راقب الرابط العلوي والنفق وجدول الاتصالات ونتيجة التطبيق معا.
في جهاز ASA ذي رابطين علويين، لا يمثل failback العملية العكسية لـ failover. يتغير المسار نحو النظير، ثم على المنصة أن توفق بين ثلاث آلات حالة منفصلة: جدول التوجيه، وارتباطات الأمان IKE وIPsec، وجدول الاتصالات. وقد يتخلف كل منها عن الآخر، وهذا التخلف هو ما يصفه معظم الناس بنفق لا يعود.
ما الذي يغيره failback فعلا
البحث في جدول التوجيه هو الجزء المرئي. وعندما يتعافى الكائن المراقب يعود المسار المراقب إلى العنوان الخارجي للنظير، وتتبع الحزمة التالية التي يرسلها ASA الرابط الأساسي مرة أخرى. وكل ما يأتي بعد ذلك يتوقف على ما إذا كانت الحالة القائمة تتفق مع المسار الجديد.
ARP وNAT هما الاعتمادان الصامتان. تحتاج القفزة التالية الجديدة إلى بوابة قابلة للحل وإلى ترجمة ما زالت تطابق الطرف البعيد، وإلا ذهبت الحزم الأولى بعد failback إلى لا مكان وبدا المسار سليما بينما لا شيء يعمل.
أربع زوايا على خط زمني واحد
سجل الأمور الأربعة نفسها قبل الانتقال وأثناءه وبعده، لأن لقطة واحدة لا تستطيع أن تخبرك أي طبقة تحركت.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
المسار الذي لم يتغير قط والمسار الذي تغير بينما احتفظ اتصال أقدم بحالة إعادة توجيهه ينتجان الشكوى نفسها ودليلا مختلفا تماما.
لماذا تبقى الاتصالات القديمة على المسار الاحتياطي
لا يهدم ASA تدفقا لأن مسارا تغير. تحتفظ الاتصالات القائمة بقرار إعادة التوجيه الذي أنشئت به، وتعرض المنصة ضوابط منفصلة لمدة السماح بذلك: مهلة الاتصال العائم و holddown الاتصال. ويتعامل دليل إعدادات الاتصال في ASA 9.24 من Cisco معهما كسؤالين منفصلين، وهذا بالضبط سلوكهما. أحدهما يحكم بقاء تدفق قائم، والآخر يحكم متى يجوز للتدفقات الجديدة استخدام المسار المفضل.
اقرأ القيم الفعالة لإصدارك قبل تغيير أي منهما. خفضهما يغلق جلسات ما زال الناس يستخدمونها. ورفعهما يجعل failback يبدو كأنه لم يحدث، لأن الاتصالات الجديدة تظل تسلك المسار القديم طوال المدة.
النفق لا يعيد توليد المفاتيح لأن مسارا عاد
تحمل ارتباطات أمان IPsec عمرا متفاوضا عليه خاصا بها، وهي تصمد أمام تغير المسار الذي حملها. لذلك يمكن أن يبقى النفق قائما عبر failback بينما لا تعود عنونته الخارجية تطابق المسار المستخدم، وهذا هو حجة DPD والتصاميم التي تثبت عنوان النظير بدل تعويمه.
تصاميم crypto-map وVTI تتصرف هنا بشكل مختلف، ويصف توثيق 9.24 VTI من Cisco الخيار المعتمد على المسار. والادعاء القديم الشامل بأن ASA لا يستطيع تشغيل شبكات VPN المعتمدة على المسار لا يصح في الإصدارات المدعومة.
اقرأ الأدلة بهذا الترتيب
ابدأ بمستوى التحكم: show route للمسار المختار، وshow interface لحالة الرابط، وعدادات مراقب SLA للكائن المراقب. ثم اقرأ show crypto ikev2 sa، أو ما يعادله في IKEv1، لمعرفة أي نظير حي، يليه show crypto ipsec sa للتدفقات المحمية. ثم ضيق جدول الاتصالات بـ show conn address <host> وقارن عمود الواجهة بين المدخلات القديمة والجديدة. اكتب المخرجات مع الطوابع الزمنية، لأن ترتيبها هو التشخيص.
اختم باختبار للتطبيق: تدفق كان قائما بالفعل، وتدفق أنشئ بعد عودة المسار. إذا فشل التدفق القديم ونجح الجديد، فلديك قصة حالة اتصال. وإذا فشل الاثنان، فالنفق أو السياسة خطأ وجدول الاتصالات مجرد تشتيت.
أبق هذا السجل بالشكل نفسه في المراحل الثلاث، ودون الإصدار بدقة. وعندما يظل الخط الزمني يشير إلى انتقال واحد، أرسل السجل إلى الدعم بدل التخمين في معرف خطأ.