Mac IKEv2 ECDSA: کدام نوع گواهی متعلق به کلاینت است؟
در Mac، مقدار ECDSA256 در تنظیمات IKEv2 گواهی هویت محلی را توصیف می‌کند، نه دروازه یا امضای صادرکننده را. پیش از انتخاب هر نقش را بخوانید.
در macOS، انتخاب ECDSA در تنظیمات کلاینت IKEv2 به پرسشی باریک پاسخ می‌دهد: کدام گواهی هویت Mac را اثبات می‌کند. این انتخاب گواهی دروازه، امضایی که گواهی کلاینت را صادر کرده، یا پیشنهاد رمزنگاری تونل را توصیف نمی‌کند. برخورد با این چهار نقش به‌عنوان یک پرسش سازگاری همان چیزی است که باعث می‌شود یک تنظیم محلی درست به گردن ناسازگاری سمت سرور بیفتد. تصمیم کوچک است، اما شواهدی که برای گرفتن آن به کار می‌رود باید دقیق باشد.
این فیلد یک گواهی را نام می‌برد: هویت محلی
Network Extension API اپل یک نوع گواهی برای اعتبارنامه کلاینت ارائه می‌دهد، از جمله NEVPNIKEv2CertificateType.ECDSA256 که به‌عنوان نوع گواهی ECDSA p-256 مستند شده است. این ویژگی به گواهی‌ای اعمال می‌شود که از طریق identityReference یا identityData تأمین می‌شود.
این یعنی تصمیم درباره گواهی‌ای است که Mac ارائه می‌دهد، به‌همراه کلید خصوصی همراهش. نوعی را انتخاب کنید که با کلید عمومی همان گواهی برگ مطابقت دارد و هویت را از طریق سازوکار پشتیبانی‌شده ارائه دهید. اگر Mac کلید خصوصی قابل استفاده‌ای برای هویت نداشته باشد، انتخاب نوع نمی‌تواند اتصال را نجات دهد.
پروفایل‌های مدیریت‌شده همین تصمیم را از طریق CertificateType در بار داده IKEv2 می‌گیرند، همراه با ارجاع گواهی مانند PayloadCertificateUUID. این فیلدها پیش‌نیازها و طرح‌واره‌ای برای نسخه سیستم‌عامل هدف دارند؛ مقدار نوع خالی که در یک پروفایل کپی شود قابل نصب نیست، و پنجره تنظیمات ممکن است هر گزینه API را نشان ندهد. پیش از استقرار، پیش‌نیازهای بار داده را برای همان نسخه بررسی کنید.
بر اساس نقش تصمیم بگیرید، نه برچسب گواهی
فیلدی را که می‌خواهید تغییر دهید بخوانید و بپرسید به کدام گواهی اشاره دارد. برچسب‌ها در نمایشگر گواهی، موضوع، صادرکننده و الگوریتم امضا را با هم می‌آمیزند و تنها یکی از آن‌ها به انتخاب هویت کلاینت مربوط است.
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
اگر نمایشگر گواهی امضای ECDSA از CA را نشان دهد، این کلید امضای صادرکننده را توصیف می‌کند. کلید خود کلاینت می‌تواند هنوز RSA باشد و فیلد نوع باید از کلید کلاینت پیروی کند، نه از سطر امضا. همین یک اشتباه توضیح‌دهنده بسیاری از گزارش‌های "ECDSA پیکربندی شده اما اتصال شکست می‌خورد" است. پیش از هر تغییری، نوع کلید در برگ را با نوع انتخاب‌شده در پروفایل مقایسه کنید.
وقتی برگ شناسایی شود تصمیم ساده‌تر می‌شود: ECDSA256 برای کلید کلاینت p-256، و نوع پشتیبانی‌شده دیگری برای کلیدی متفاوت. اگر گواهی کلاینت و کلیدش با هم نمی‌خوانند، پیش از تغییر پروفایل VPN آن جفت را درست کنید.
گواهی دروازه تصمیمی جداگانه است
دروازه گواهی خودش را ارائه می‌دهد و Mac آن را در برابر لنگر اعتماد و نام مورد انتظار اعتبارسنجی می‌کند. اینکه آن گواهی از ECDSA، RSA یا نوع کلید دیگری استفاده کند ویژگی سرور است، نه تنظیم هویت کلاینت.
پشتیبانی محلی از گواهی کلاینت ECDSA اثبات نمی‌کند که هر گواهی دروازه، هر منحنی یا هر پیکربندی احراز هویت سرور با هم کار خواهند کرد. هویت سرور، زنجیره آن و روش احراز هویت IKE را به‌عنوان ورودی‌های جداگانه بررسی کنید و با همان پروفایلی آزمایش کنید که واقعاً مستقر می‌شود.
اگر گواهی دروازه مشکل باشد، علامت معمولاً در هنگام اعتبارسنجی همتا ظاهر می‌شود، نه در انتخاب هویت. پیش از تغییر نوع کلاینت، مرحله شکست را بخوانید، زیرا شکست اعتماد و ناسازگاری کلید کلاینت راه‌حل مشترکی ندارند.
امضای صادرکننده و گروه توافق کلید نوع کلاینت نیستند
X.509 کلید عمومی موضوع و امضای صادرکننده را در فیلدهای جداگانه نگه می‌دارد. اطلاعات کلید عمومی موضوع، کلید موجود در گواهی را توصیف می‌کند؛ الگوریتم امضا کلید CA و عملیات امضا را توصیف می‌کند. تنها مورد اول با تنظیم نوع گواهی مطابقت دارد.
پیشنهادهای IKE و Child SA محور دیگری هستند. نوع گواهی ECDSA یک انتخاب رمزنگاری ESP نیست و تغییر گروه توافق کلید نوع گواهی را انتخاب نمی‌کند. یک پروفایل می‌تواند پیشنهادهای معتبر و نوع هویت نادرست داشته باشد، یا نوع هویت درست و پیشنهادی که همتا آن را رد می‌کند.
سه خط را در سابقه تغییر جدا نگه دارید: گواهی هویت و کلید، ورودی‌های اعتماد دروازه، و الگوریتم‌های پیشنهادها. یکی کردن آن‌ها در یک یادداشت "تنظیمات رمزنگاری" باعث می‌شود شکست بعدی قابل انتساب نباشد.
تصمیم را با همان فیلدهایی که پیکربندی کرده‌اید بررسی کنید
هویتی را که پروفایل واقعاً به آن ارجاع می‌دهد بررسی کنید، سپس تأیید کنید که گواهی در آن ارجاع کلید عمومی مورد انتظار و کلید خصوصی قابل استفاده دارد. نوع نمایش‌داده‌شده در رابط کاربری، گواهی ارجاع‌شده و کلید روی دستگاه باید هم‌خوان باشند.
سپس ورودی‌های دروازه را تأیید کنید: نام مورد انتظار سرور، لنگر اعتماد و روش احراز هویت IKE. در پایان متصل شوید و ببینید دست‌دادن کجا متوقف می‌شود. شکست پیش از تبادل هویت از این تنظیم دور است؛ شکست در اعتبارسنجی همتا به سمت دروازه اشاره می‌کند.
نوع انتخاب‌شده، ارجاع هویت و موضوع گواهی دروازه را در یادداشت‌های استقرار ثبت کنید. به‌روزرسانی بعدی پروفایل می‌تواند هر یک از آن‌ها را تغییر دهد و مقایسه سه مقدار نام‌دار سریع‌تر از تصویر یک صفحه تنظیمات است.