عدم تطابق MAC در IKE یعنی بررسی کلید مشترک شکست خورده است

گزارش Cloud VPN شما تلاشی با کلید مشترک را نشان می‌دهد که پس از آن MAC mismatched آمده است، و اولین واکنش معمولاً جست‌وجوی مشکل آدرس است. در این شاخه MAC کد احراز اصالت پیام است: مقداری که روی تبادل با کلید توافق‌شده محاسبه می‌شود. همتا محاسبه خود را با مقدار دریافت‌شده مقایسه کرد و آن‌ها متفاوت بودند. هیچ کارت شبکه‌ای درگیر نیست و هیچ تنظیم واسطی آن مقایسه را تغییر نمی‌دهد.

در عمل دو شرط آن را ایجاد می‌کند: رازهای دو طرف یک مقدار نیستند، یا هویت‌هایی که برای انتخاب راز به کار می‌روند با هم مطابقت ندارند. با خواندن جفت تصمیم بگیرید کدام است، نه تونل تنها.

این مرحله چه چیزی را اثبات می‌کند

بررسی پس از آن انجام می‌شود که هر دو طرف پارامترهای اولیه را مبادله و خود را معرفی کرده‌اند. برای هویت محلی و راه دور کلیدهای مشترک نامزد انتخاب می‌کند و می‌کوشد داده‌های احراز اصالت دریافتی را اعتبارسنجی کند؛ وقتی هیچ‌کدام معتبر نباشد، تشخیص صادر می‌شود. این ادعایی قوی درباره احراز اصالت و ضعیف درباره علت است، زیرا نمی‌گوید کدام طرف اشتباه است.

موفقیت پیشین به این بررسی منتقل نمی‌شود. یک IKE_SA_INIT کامل‌شده، یا بار کشف NAT که مقادیر مورد انتظار را برگردانده باشد، اثبات می‌کند که همتاها می‌توانند صحبت کنند. هیچ چیزی درباره اشتراک راز اثبات نمی‌کند.

دو خطای پیکربندی، یک پیام

نخستین، ناسازگاری واقعی راز است و معمولاً یک حادثه تأمین است: مقداری تولیدشده که روی یک کنسول نصب و روی دیگری بازتایپ شده، یک نویسه انتهایی که در یک طرف مانده، یا یک گیومه که همراه چسباندن آمده است. دومی ناسازگاری هویت است، جایی که راز درست است اما هویتی که همتا ارائه می‌دهد ورودی دیگری را انتخاب می‌کند، پس راز درست هرگز آزمایش نمی‌شود. هر دو یک خط تولید می‌کنند، به همین دلیل حدس زدن یک بعدازظهر هزینه دارد.

پیش از دست زدن به هر راز، جفت را مقایسه کنید. تونل، نقطه پایانی همتا، بازه زمانی و پیکربندی راه دور را تطبیق دهید، زیرا دو تونل افزونه می‌توانند رازهای متفاوت داشته باشند و صفحه‌ای که پیش روی شماست شاید همانی نباشد که شکست خورده است.

کشف NAT مرحله‌ای دیگر است

کشف NAT می‌پرسد بسته‌ها چگونه بازنویسی می‌شوند، نه اینکه همتا کیست. دروازه مشتری پشت NAT وقتی هویت پیکربندی‌شده‌اش همان باشد که همتا انتظار دارد همچنان درست احراز اصالت می‌شود، و مشکل NAT به صورت ناسازگاری پیشنهاد یا پورت ظاهر می‌شود نه مقایسه احراز اصالت ناموفق.

ادعایی قدیمی درباره یک نسخه فروشنده را به استقرار فعلی منتقل نکنید. آنچه عبور NAT در نسخه شما می‌خواهد به مستندات خودش تعلق دارد، و عبارت MAC mismatch شاهدی له یا علیه آن نیست.

از جفت تصمیم بگیرید، نه از صفحه

هر دو پیکربندی را کنار هم با راز پوشانده بخوانید، سپس سه پرسش بپرسید. آیا هویت در هر طرف دقیقاً همان چیزی است که طرف دیگر انتظار دارد، نویسه به نویسه؟ آیا دو طرف از همان نسخه IKE و همان روش احراز اصالت استفاده می‌کنند؟ آیا تونل شکست‌خورده با پیکربندی‌ای که می‌خوانید مطابقت دارد؟ «نه» به هر یک از آن‌ها تعمیر را بدون دست زدن به راز مشخص می‌کند.

اگر هر سه پاک باشند، راز را از طریق گردش‌کار تأییدشده جایگزین کنید، نه اینکه دور آن ویرایش کنید.

پس از احراز اصالت همتا

وقتی احراز اصالت موفق شود، سطح شکست بعدی انجمن امنیتی فرزند است: پیشنهادها و انتخاب‌گرهای ترافیک. چرخش رازی که پیش‌تر پذیرفته شده نمی‌تواند شکست فرزند را درست کند و قطعی را طولانی‌تر می‌کند. وضعیت فرزند را بخوانید، سپس انتخاب‌گرها و بازه‌های محافظت‌شده در دو طرف را، و راهنمای عیب‌یابی Cloud VPN را با مرحله‌ای که واقعاً شکست خورده تطبیق دهید.

گزارش‌های تازه دو طرف را به هم مرتبط کنید برای همان جفت و همان بازه. یک طرف به‌تنهایی بدون ورودی طرف دیگر حکم می‌دهد، و همین ابهام بود که در آغاز پیام را ساخت.

چه نتیجه‌ای نگیریم

پیام را همچون درخواست تغییر نشانی‌های MAC نخوانید و هنگام درخواست کمک راز مشترک را منتشر نکنید؛ گزیده‌ای که کلید دارد باید کلیدش حذف شود، نه اینکه گزارش نگه داشته شود. فرض نکنید خطای مسیریابی هم هست، زیرا همتاهایی که به یکدیگر نمی‌رسند هیچ مقایسه احراز اصالتی تولید نمی‌کنند. و محدودیت مستند یک خانواده محصول را به هر پیاده‌سازی IPsec تعمیم ندهید.

جفت شکست‌خورده، وضعیت تونل پیش و پس، و اینکه کدام یک از دو شرط را تغییر دادید ثبت کنید. همین ثبت، رخداد بعدی را به بررسی پنج‌دقیقه‌ای تبدیل می‌کند.