رابطان WAN لكل موقع يبدوان كتكرار احتياطي حتى تحاول إثبات أي زوج عناوين استخدمه تدفق معين فعليًا. على SRX، تحمل بوابة IKE واحدة واجهة خارجية واحدة وعنوانًا محليًا واحدًا؛ وقائمة المرشحين البعيدين لا تنشئ مصدرًا محليًا ثانيًا. لهذا تبدأ هذه الجولة بمصفوفة الأزواج لا بالإعداد، لأن Junos يقبل بسهولة تصميمًا يغطي نصف التوليفات المقصودة فقط. واجهت هذا على جهازي SRX345s: نفق الاحتياط صعد بنظافة ومع ذلك أسقط الجلسة عند العودة.

اتبع الخطوات بالترتيب: عدّد الأزواج التي يجب دعمها، وابنِ بوابة واحدة لكل مصدر محلي، وأكّد أي اقتران حمل الحركة، وبعد ذلك فقط قرر ما يمكن لكل نوع من الأعطال تغييره.

ارسم الأزواج قبل لمس الـ CLI

إذا كان الموقع A يستطيع الإرسال من A1 أو A2 والموقع B يستطيع الاستقبال على B1 أو B2، فلديك أربعة أزواج عناوين خارجية. تحتاج معظم التصاميم إلى اثنين منها باستمرار وتعتبر الآخرين اختياريين. اكتب المصفوفة وعلّم كل صف، لأن كل صف تَعِده سيكلفك لاحقًا بوابة وواجهة نفق وقرار توجيه.

Local sourceRemote candidateRequired?
A1, ISP1 addressB1steady state
A1, ISP1 addressB2decide explicitly
A2, ISP2 addressB1decide explicitly
A2, ISP2 addressB2backup path

كل زوج مطلوب يحتاج ثلاثة أشياء في وقت واحد: شبكة نقل أساسية قابلة للوصول بين هذين العنوانين بالتحديد، وقبول متبادل لهوية الطرف وعنوان المصدر في الطرفين، ومسار عودة محمي. الزوج الذي يعمل في اتجاه واحد فقط سيظهر نفقًا على أي حال، وسيظهر العطل لاحقًا كحركة تطبيق أحادية الاتجاه.

بوابة واحدة لكل مصدر محلي، لا لكل موقع بعيد

قائمة العناوين البعيدة تنتمي إلى بوابة، وكذلك المصدر المحلي. مرجع بوابات IKE يحتفظ بالعناوين البعيدة والواجهة الخارجية والعنوان المحلي وكشف الطرف الميت كإعدادات منفصلة، وهذا هو بيت القصيد: مصدران محليان يعنيان بوابتين على وحدتي st0. مشاركة سياسة IKE بينهما أمر مقبول؛ أما الإبقاء على بوابة واحدة والأمل بأن تختار مصدرًا آخر بنفسها فليس كذلك.

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

ثم اربط الأنفاق وأعطِ البادئة البعيدة قفزتين تاليتين، واحدة لكل نفق:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

هل تستطيع بوابة واحدة حمل تعليمتين من نوع address يتوقف على الإصدار وعلى أي عملية IKE يشغّلها الجهاز. إصدارات Junos الأقدم المبنية على kmd تقبل عنوانًا بعيدًا واحدًا لكل بوابة؛ أما البنيات الأحدث فتتعامل مع عدة مرشحين لكنها تضيف قيودها الخاصة، وعناقيد التوافر العالي مكان شائع يضيق فيه هذا الدعم. راجع ملاحظات الإصدار الخاص ببنيتك الدقيقة قبل نسخ هذا من هيكل أقدم.

أكّد أي اقتران حمل الحزمة

وجود SA اثنين ونفقين لا يخبرك أيهما مرّر الجلسة. اسأل الجهاز مباشرة وقارن الحقول بالزوج الذي كنت تقصده:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

يذكر الإخراج المفصل البوابة المحلية والبعيدة لكل اقتران، وهو أسرع طريقة لرصد نفق تفاوض من مصدر لم تتوقعه. ثم راقب عدادات الحزم لكل وحدة على st0.1 و st0.2 أثناء تمرير الحركة؛ النفق الذي لا يحمل شيئًا يحتفظ بـ SA الخاص به ويبدو سليمًا في عرض موجز.

أعطِ كل نوع عطل كاشفه الخاص

حيوية الطرف، وفقدان وصلة الرفع المحلية، وسحب المسار المحمي، وتعطل التطبيق أحداث أربعة مختلفة. يجيب DPD على الأول فقط، لذلك اضبطه بفاصل وعتبة تستطيع الدفاع عنهما بدل ترك القيمة الافتراضية والافتراض بأنها تغطي الباقي:

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

مراقبة النفق التي تختبر وجهة داخل الشبكة الفرعية البعيدة تغطي الحالة التي لا يراها DPD: IKE حي، والبوابة تجيب، والبادئة المحمية غير قابلة للوصول رغم ذلك. اختر أيهما يجب أن يسحب الأفضلية، لأن تفعيل الاثنين معًا ينتج عاصفة تغييرات بدل تحويل نظيف.

لا تنسَ الطرف البعيد. المسار المفضل الذي يبقى مثبتًا في الموقع البعيد يظل يشير إلى نفق تخلّيت عنه بالفعل، ولا يصلح أي مؤقت محلي ذلك. انشر منطق الأفضلية نفسه على الطرفين، وسجّل ما إذا كان بإمكان وصلة مستعادة استعادة الحركة تلقائيًا أم يجب تبديلها يدويًا.

أعد عنونة رابط واحد دون لمس الآخر

عندما يمنحك المزود كتلة جديدة، غيّر علاقة واحدة في كل مرة. حدّث address أو local-address على الطرفين لذلك الزوج، ثم نفّذ commit، وامسح الاقترانات المتأثرة فقط بالفهرس بدل مسح كل الـ SAs على الجهاز. المسح الشامل يزيل النفق السليم أيضًا ويحوّل نافذة صيانة إلى انقطاع.

احتفظ بتدفق فاشل واحد وتفاصيل جلسته كدليل قبل أن تنظف أي شيء، ثم أعد تشغيل الفحوصات أعلاه على زوج العناوين الجديد. استعادة رابط قرار توجيه، لذا عامل العودة كخطوة مختبَرة مستقلة بدل افتراض أن الأفضلية القديمة تعود من تلقاء نفسها.

أغلق التغيير بقائمة تحقق قصيرة

يكتمل تصميم نفق ثنائي WAN عندما تستطيع تسمية الزوج وراء كل جلسة، لا عندما يصعد كلا الـ SA. راجع القائمة أدناه على الجهاز الذي غيّرته فعليًا:

  • لكل زوج موعود بوابة ووحدة st0 ومدخل مسار.
  • شوهد كل نفق وهو يحمل حزمًا، لا مجرد إمساك SA.
  • يتفق الطرفان على الكشف وعلى أي جانب يستعيد الأفضلية.
  • مسار العودة لكل زوج مكتوب بجوار مساره الأمامي.

إذا فشل أحد الأسطر، أصلح ذلك الزوج قبل إضافة التالي؛ تكديس نفقين يعملان نصف عمل يجعل العدادات بلا معنى وسلوك التحويل غير قابل للتنبؤ.

مقالات ذات صلة