GCP HA VPN يرفض FortiGate: عدم تطابق نوع المعرّف المحلي
تقارن Google المعرّف الذي يعلنه FortiGate، لا المفتاح المشترك المسبق وحده. معرّف محلي من نوع FQDN يفشل في ذلك الفحص بينما يظل السجل يقول إنه مصادقة.
عادةً ما يعيد AUTHENTICATION_FAILED الصادر من Google Cloud HA VPN الناس إلى المفتاح المشترك المسبق، والمفتاح صحيح في العادة. يتوقف النفق عند المرحلة 1 لأن Google تقارن شيئًا آخر أيضًا: المعرّف الذي يعلنه الطرف الآخر أثناء تبادل IKE. على FortiGate يمكن أن يتغيّر نوع ذلك المعرّف دون أن يحرّر أحد عنوانًا. اقرأ السجل على أنه عدم تطابق في المعرّف بعد أن يُعاد إدخال المفتاح مرتين.
فشل واحد، فحصان
يتحقق IKE من الطرف الآخر في خطوتين منفصلتين. يثبت المفتاح المشترك المسبق أن الطرفين يملكان السر نفسه، ويخبر المعرّف المُعلن المستجيبَ بمن يدّعي الطرف الآخر أنه هو. تفحص Google ذلك المعرّف مقابل الطرف الآخر الذي أُعدّت معه. وإذا تُرك الأمر، يرسل FortiGate معرّفًا قائمًا على العنوان مشتقًا من واجهته الصادرة، فتنجح المقارنة دون أن يلاحظ أحد أن ذلك حدث.
تقع كلتا الخطوتين في الدلو نفسه في السجل، وهذا يفسّر الحلقة المألوفة: إعادة كتابة المفتاح أربع مرات قبل أن يقرأ أحد حمولة المعرّف.
ما يضعه FortiGate في حمولة المعرّف
تبدأ المشكلة عندما يضبط أحدهم معرّفًا محليًا ليتوافق الطرفان. تصنّف إصدارات FortiOS الحديثة ذلك المعرّف كاسم نطاق مؤهّل بالكامل حتى عندما تكون القيمة المُدخلة عنوانًا منقّطًا. لذلك تتلقى Google معرّفًا من نوع FQDN وهي تتوقع عنوانًا، فترفض الجلسة. لا يذكر أي جزء من الرسالة أيّ الشقّين فشل، لذا يُقرأ التقرير على أنه فشل في المصادقة.
أعد إنتاج المشكلة مرة واحدة مع تمكين تنقيح IKE واقرأ حمولة المعرّف التي يُصدرها الجدار الناري فعليًا.
في المرور نفسه، تحقق من ثلاثة أمور رخيصة: إصدار IKE الذي يستخدمه الطرفان، والمفتاح بالضبط بما في ذلك الأحرف الخفية في نهايته، وعنوان الطرف الآخر الذي تتوقع Google أنه معدّ. إنها تجيب عن أسئلة منفصلة، والمفتاح المطابق لا يقول شيئًا عن المعرّف.
الخيارات، وما يكلّفه كل منها
كل مخرج يصلح طبقة مختلفة، وليس أي منها متاحًا لكل عملية نشر.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
تصحيح المعرّف على الجدار الناري هو أنظف جواب حين تتيح لك البرمجية الثابتة اختيار النوع مع الاحتفاظ بالقيمة. الحقل موجود في بعض الإصدارات ويملأ النوع خطأً في إصدارات أخرى، لذا اختبر إصدارك بدلًا من الوثوق بملاحظات الإصدار.
العنوان العام القابل للتوجيه على الواجهة المتفاوضة هو الحل البديل الموثّق، لأن المعرّف الافتراضي حينها يطابق ما تتوقعه Google ولا حاجة إلى تجاوز. وهو ما تنتهي إليه معظم عمليات النشر، إن كان الجدار الناري قادرًا على حمل عنوان كهذا أصلًا.
الإنهاء على طرف آخر يتحقق مما تنتجه هو تغيير في الطوبولوجيا. تعامله كقرار تصميم لا كحل بديل بوصف ألطف.
حين يزيل NAT أحد الخيارات
خلف NAT يختفي مخرج العنوان العام، وما يبقى يعتمد على سلوك البرمجية الثابتة الذي لا تتحكم فيه. وهذه هي النقطة التي تختار عندها بوعي بين الترقية، أو نقل الطرف الآخر، أو قبول نقطة نهاية سحابية مختلفة. تلك ميزانيات ثلاث مختلفة، واختيار واحدة بالمصادفة هو كيف يتحول حل بديل مؤقت إلى معمارية. اكتب الاختيار وسببه بجوار النفق.
قبل تفسير أي من هذا، تحقق من حالة النفق على جانب Google ومن أن IKE لا يُسقَط ببساطة في الطريق. الحزمة المُسقَطة تنتهي بمهلة؛ ولا تنتج رفضًا.
ما ينبغي تسجيله ما دام يعمل
سجّل نوع المعرّف وقيمته وإصدار البرمجية الثابتة وعنوان الطرف الآخر التي كانت سارية عند آخر صعود للنفق. تحديث البرمجية الثابتة قد يغيّر الافتراضي مرة أخرى، وسيبدو الفشل التالي تمامًا كعدم تطابق في المفتاح. ومع تخزين المعرّف بجوار المفتاح وعنوان الطرف الآخر، يبدأ الشخص التالي من الفحوص الرخيصة.
هذا السجل هو أيضًا الطريقة الوحيدة لمعرفة ما إذا كان الحل البديل لا يزال مطلوبًا بعد الترقية التالية.