Cisco ASA إلى Azure VPN: أزواج محدِّدات حركة المرور

يرتفع النفق، ويبدو IKE سليمًا، ولا شيء يعبره. هذا هو الشكل المعتاد لمشكلة محدِّدات ASA إلى Azure، ولهذا أكتب العقد قبل لمس أي من الطرفيتين. العقد أربعة أشياء: الكائنات التي تحدد كل نظير، ونموذج الاتصال، وأزواج البادئات الدقيقة، والتحقق الذي يثبت كل زوج. أخطئ في هذه وكل أمر لاحق سيشخّص إعدادًا لم يكن ينبغي أن تبنيه. دليل التشغيل هذا هو الترتيب الذي أتبعه، مع الأوامر التي تُظهر أي كائن هو الخاطئ فعلًا.

اكتب الكائنات الأربعة قبل أن تبدأ الإعداد

ابدأ بإصدار ASA والمنصة، ونقطة النهاية العامة، ونوع بوابة Azure VPN وSKU، وبوابة الشبكة المحلية التي تمثل جهتك. هذه الأسماء الأربعة هي المفردات لكل ما يلي، ولكل منها مالك مختلف عندما يتعطل شيء.

إذا كان اثنان منها لا يزالان تخمينًا، فتوقف. قائمة بادئات خاطئة في بوابة الشبكة المحلية ليست مشكلة ضبط.

اختر نموذج اتصال واحدًا وتوقف عن خلط القوالب

تصميم خريطة التشفير وتصميم واجهة النفق إعدادان مختلفان، وقالب أحدهما لا يصبح صالحًا للآخر بتعديل عنوان النظير. سجّل أيّهما تبني قبل أن تلصق أي شيء، لأن عدم التطابق يظهر لاحقًا كمشكلة محدِّدات لا كخطأ إعداد. يغطي دليل التشغيل البيني لـ ASA من Microsoft النمطين ويحدد نموذج بوابة Azure الذي يفترضه كل منهما. إذا لم تذكر ملاحظاتك النموذج، فليس لديك تصميم بعد.

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

حدود الإصدارات تنتمي إلى العقد أيضًا. تقرير ميداني قديم عن سقف في نطاقات التشفير هو نقطة بيانات عن إصدارات معينة، وليس خاصية دائمة لكل ASA.

عدّد أزواج البادئات، لا التجميعات

اكتب المصفوفة. من المحلي A وB إلى Azure X وY أربعة أزواج، ويحتاج كل زوج إما إلى تغطية أو إلى استبعاد صريح. دمج A وB في تجميع واحد يضم أيضًا كل ما يقع بينهما، وهكذا ينشأ ثقب في التصميم بهدوء.

تحقق مما تفاوض عليه النظيران لا مما حفظته. قائمة الشبكات المحلية والبعيدة على ASA هي النية؛ أما CHILD SAs فهي النتيجة.

عندما يكون زوج مفقودًا، فالإصلاح عادةً سطر في قائمة الوصول أو مدخل محدِّد، لا نفق جديد.

تحقق بأوامر تسمّي الكائن

على ASA، أكّد جلسة IKE، ثم IPsec SAs، ثم أزواج المحدِّدات. كل أمر يجيب عن سؤال مختلف، وتشغيل الأول فقط هو ما يحوّل عبارة النفق قائم إلى استنتاج خاطئ. اقرأ المخرجات للنظير الذي أعددته فعلًا، لا لأي SA يصادف أنه الأول في القائمة. جانب Azure يجيب عن الأسئلة الثلاثة نفسها من وجهة نظره.

show crypto ikev2 sa detailed
show crypto ipsec sa peer 203.0.113.10
show run access-list AZURE-SELECTORS
packet-tracer input inside icmp 10.1.10.10 8 0 10.2.20.20 detailed

ثم اطلب من Azure حالة الاتصال باستخدام az network vpn-connection show --name <connection> --query connectionStatus. Connected مع صفر بايت في مسار البيانات مشكلة محدِّدات، لا مشكلة توجيه.

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

افصل نطاق التشفير عن إذن الوصول

المحدِّد الواسع ليس إذنًا. إذا كان التخطيط المدعوم أوسع من سياسة التطبيق، فأبقِ الخدمات الضيقة في قواعد الجدار الناري واترك نطاق التشفير حيث يجب أن يكون.

تُراجع مسارات أحمال عمل Azure ومسارات العودة المحلية بشكل منفصل. إعلانات BGP ونطاق الشبكة الثابت والمسارات المعرّفة من المستخدم يجب أن تصف جميعها المسار نفسه، ولا يجوز لأي منها التقاط نقل النظير بشكل متكرر.

التراجع وإثبات نجاحه

احتفظ بالإعداد التشغيلي السابق قبل تغيير المحدِّدات، واعرف الأمر الوحيد الذي يعيده. على ASA يعني ذلك نسخة محفوظة ومسار استعادة مطابق، لا ذكرى لما عدّلته. اكتب أمر الاستعادة في تذكرة التغيير بينما التغيير لا يزال افتراضيًا. ثم أعد تنفيذ الفحوص الثلاثة نفسها: حالة IKE، وأزواج IPsec SA، وتدفق مسموح واحد لكل زوج.

إذا ظل زوج يفشل بعد الاستعادة، فالتغيير لم يكن السبب، وقد وفّرت على نفسك انقطاعًا ثانيًا.