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 صرفاً در مسیر دور انداخته نمی‌شود. بسته دورانداخته‌شده مهلت می‌گذراند؛ رد ایجاد نمی‌کند.
چه چیزی را تا وقتی کار می‌کند ثبت کنید
نوع شناسه، مقدار آن، نسخه فرم‌ور و آدرس طرف مقابلی را که هنگام آخرین بالا آمدن تونل برقرار بودند یادداشت کنید. به‌روزرسانی فرم‌ور می‌تواند پیش‌فرض را دوباره تغییر دهد، و شکست بعدی دقیقاً شبیه ناسازگاری کلید دیده می‌شود. وقتی شناسه کنار کلید و آدرس طرف مقابل ذخیره شود، نفر بعدی از بررسی‌های ارزان شروع می‌کند.
این ثبت همچنین تنها راه دانستن این است که آیا راه‌حل موقت پس از ارتقای بعدی هنوز لازم است یا نه.