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

سه هویت در یک اتصال

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

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

فیلدهای بومی را بر اساس وظیفه‌شان بخوانید

در پیکربندی بومی مدیریت‌شده IKEv2، ارجاع بار کاربردی اپل مقادیر را جدا می‌کند و روش احراز هویت تعیین می‌کند کدام ترکیب لازم است:

FieldIdentifiesCommon misreading
AuthNameUsername for the configured arrangementAssuming it is the certificate subject
LocalIdentifierIKEv2 client identifierAssuming it must equal the username
PayloadCertificateUUIDReferenced credential payloadAssuming any installed certificate will do

یک گواهی و یک ورود EAP می‌توانند در همان اتصال نقش‌های متمایزی داشته باشند. هر فیلد را مجبور نکنید همان متن را نگه دارد فقط به این دلیل که یکی از آن‌ها چنین می‌کند، و تصور نکنید تغییر یکی بقیه را باطل می‌کند. یک برنامه VPN شخص ثالث ممکن است مدلی کاملاً متفاوت ارائه دهد؛ از انتخاب هویت مستند آن استفاده کنید نه اینکه نام فیلدهای بومی را به آن منتقل کنید.

گواهی سرور هویت کلاینت نیست

گواهی‌ای که دروازه را اعتبارسنجی می‌کند لنگر اعتماد است. اثبات می‌کند به سروری رسیده‌اید که انتظار داشتید. هویت کلاینت شیء دیگری است: شامل دسترسی به کلید خصوصی‌ای است که اثبات می‌کند طرف متصل همان کسی است که ادعا می‌کند. تغییر نام یک حساب نمایشی نمی‌تواند یکی را به دیگری تبدیل کند.

اینجاست که یک اصلاح خیرخواهانه اشتباه می‌شود. واردکردن گواهی CA دروازه به مخزن کلاینت هیچ کاری برای احراز هویت کلاینت نمی‌کند و برچسب زدن آن ورودی با نام کاربر آن را به هویت کاربر تبدیل نمی‌کند. این دو شیء در بخش‌های متفاوت نمایه زندگی می‌کنند و به پرسش‌های متفاوتی پاسخ می‌دهند.

اصل را تا نگاشت دروازه دنبال کنید

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

سپس خود اعتبارنامه را مقایسه کنید، نه برچسب را. صادرکننده، شماره سریال و اثر انگشت به شما و مدیر اجازه می‌دهد تأیید کنید درباره همان شیء صحبت می‌کنید. نام‌های نمایشی قابل ویرایش و اغلب تکراری‌اند، و همین آن‌ها را در هنگام یک رخداد بدترین شناسه ممکن می‌کند.

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

لایه‌ای را که صاحب این ناسازگاری است تعمیر کنید

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

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

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

مقالات مرتبط