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

SettingWhat it decidesWhat it has to agree with
Remote addresswhere IKE packets are senta reachable name or address for the gateway
Remote Identifierwhich server identity is expectedthe gateway certificate name and the peer identity RouterOS presents
Local Identifierwho the phone claims to bethe client certificate name and the RouterOS identity entry
Certificate payloadtrust plus proof of key possessionthe issuing chain and a usable client private key

فیلدهای پروفایل را به ترتیبی که تبادل از آن‌ها استفاده می‌کند بررسی کنید

آدرس دور مقصد نخستین بسته IKE است و نه بیشتر. شناسهٔ دور آن چیزی است که تلفن انتظار دارد دروازه ثابت کند هست، و یک نام است نه یک مسیر. پر کردن هر دو با یک نام میزبان وقتی درست کار می‌کند که گواهی دروازه آن نام را داشته باشد، و وقتی ندارد به شکلی شکست می‌خورد که شبیه مشکل مسیریابی است. پروفایل را دنباله‌ای از ادعاها بخوانید نه فهرستی از فیلدها که باید پر شوند.

شناسهٔ محلی ادعای خود تلفن است و باید نامی باشد که ورودی هویت RouterOS برای گواهی مشتری که تلفن ارائه می‌دهد می‌پذیرد. اگر این دو سازگار نباشند، دروازه اتصال را پس از اعتبارسنجی خود گواهی رد می‌کند و گزارش شبیه مشکل مجوزدهی است نه مشکل نام‌گذاری.

شناسه‌ها را با آنچه دروازه ارائه می‌دهد بررسی کنید

ورودی همتای RouterOS که برای احراز هویت با گواهی تنظیم شده باشد، گواهی خودش را ارائه می‌دهد و هویت آن از همان گواهی گرفته می‌شود مگر اینکه خلاف آن را تنظیم کرده باشید. اگر شناسهٔ دور تلفن نام DNS دروازه را ذکر کند، گواهی دروازه باید آن نام را در جایی داشته باشد که تلفن بپذیرد، معمولاً در نام جایگزین موضوع. گواهی صادرشده برای یک نام مشترک دیگر حتی با کلید و زنجیرهٔ بی‌عیب هم اعتبارسنجی نمی‌شود.

پروفایل‌های مدیریت‌شدهٔ Apple هم می‌توانند محدودیت نام گواهی داشته باشند که علاوه بر فیلدهای شناسه ارزیابی می‌شود. محموله را بررسی کنید و نام اعتبارسنجی را از آنچه صفحهٔ تنظیمات نشان می‌دهد استنتاج نکنید، زیرا این دو یک تنظیم نیستند.

بررسی کنید که گواهی مشتری یک کلید است، نه فقط لنگر اعتماد

وارد کردن گواهی CA به تلفن چیزی می‌دهد که با آن دروازه را اعتبارسنجی کند. اما هویت مشتری به تلفن نمی‌دهد، و احراز هویت با گواهی به گواهی برگ مشتری و کلید خصوصی آن نیاز دارد که با هم از مسیر ثبت‌نام تأییدشده تحویل شوند. یک PKCS#12 که بدون کلید خصوصی ساخته شده باشد، پروفایلی تولید می‌کند که تمیز نصب می‌شود و هیچ چیزی را احراز نمی‌کند.

برگ مشتری هم به هویتی نیاز دارد که سمت RouterOS انتظار دارد، یعنی موضوع یا نام جایگزین موضوع باید با پیکربندی هویت متناظر هم‌تراز باشد. صدور گواهی مشتری و سرور از یک CA زنجیره را راحت می‌کند و دو برگ را قابل تعویض نمی‌کند.

بررسی کنید که سیاست RouterOS آن نام را می‌پذیرد

در دروازه، ورودی همتا حالت تبادل و روش احراز هویت را تعیین می‌کند و ورودی هویت، هویت دور پذیرفته‌شده را به یک گواهی و به سیاستی که پس از آن می‌آید گره می‌زند. در RouterOS v7 این جفت از طریق ورودی‌های همتا و هویت IPsec بیان می‌شود، برای نمونه یک همتای IKEv2 با auth-method=digital-signature. محتوای واقعی منو در نسخهٔ نصب‌شدهٔ خود را بررسی کنید نه راهنمایی که برای نسخهٔ قدیمی‌تر نوشته شده است.

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

پیش از ویرایش هر چیزی بررسی کنید که کدام مرحله شکست خورده است

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

هویت ارائه‌شده، هویت مورد انتظار، صادرکننده و شمارهٔ سریال گواهی و نام سیاست مربوطه را ثبت کنید و کلیدهای خصوصی و رازهای پروفایل را بیرون از آن نگه دارید. وقتی احراز هویت موفق شد، یک سرویس خصوصی و پاسخ آن را آزمون کنید، زیرا تخصیص آدرس، انتخابگرها، DNS و سیاست دسترسی هنوز باید پس از پایان تبادل IKE کار کنند.

مقالات مرتبط