آیا Meraki MX شما از Cisco Secure Client پشتیبانی می‌کند؟

دو رشته پشتیبانی درباره اینکه Meraki می‌تواند AnyConnect را انجام دهد یا نه با هم اختلاف دارند و هر دو به یک شکل با اطمینان اشتباه می‌کنند. پرسش این نیست که آیا MX به IKEv2 صحبت می‌کند، چون AnyConnect روی دستگاه یک سرویس TLS است نه IPsec. دو بررسی جداگانه پاسخ را تعیین می‌کنند و هیچ‌کدام مقایسه برند نیست. آن‌ها را به ترتیب انجام دهید تا به جای نظر، یک رکورد سازگاری داشته باشید.

اول مدل و نسخه

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

از مدلی مشابه در همان خانواده استدلال نکنید. فهرست به ازای هر مدل است و تفاوت‌ها واقعی‌اند.

AnyConnect یک سرویس SSL است، نه IPsec

Meraki AnyConnect روی MX را یک VPN مبتنی بر برنامه با TLS و DTLS توصیف می‌کند و آن را در کنار سرویس VPN کلاینت جداگانه L2TP/IPsec مستند می‌کند. این‌ها دو محصول‌اند که تصادفاً یک داشبورد مشترک دارند. مقایسه IKEv1 با IKEv2 درباره سرویس IPsec به شما می‌گوید و هیچ چیز درباره وجود سرویس TLS روی دستگاهتان. اگر مدرک شما جدول نسخه‌های IKE است، به پرسش دیگری پاسخ داده‌اید.

پیش از مقایسه کلاینت‌ها مشخص کنید دستگاه کدام سرویس را ارائه می‌دهد. پروفایل L2TP/IPsec کارآمد به این دلیل که به همان سازمان می‌رسد پروفایل AnyConnect نمی‌شود و این دو به پیکربندی کلاینت متفاوتی نیاز دارند.

MX واقعاً چه قابلیت‌هایی ارائه می‌دهد

فهرست قابلیت‌های ASA در Cisco فهرست قابلیت‌های MX نیست و کلاینتی که دوازده چیز را پشتیبانی می‌کند باعث نمی‌شود دروازه آن‌ها را پشتیبانی کند. کارکردهایی را که واقعاً نیاز دارید مقایسه کنید: روش احراز هویت، رفتار تونل تقسیم‌شده، مدیریت DNS و حقی که دستگاه لازم دارد. هر یک را از مستندات Meraki برای نسخه به‌کاررفته بردارید.

احراز هویت جایی است که این معمولاً گاز می‌گیرد. روشی که کلاینت ارائه می‌دهد و دستگاه نمی‌تواند پیکربندی کند، یک مورد پشتیبانی است که در انتظار رخ دادن است.

نسخه کلاینت و حق دسترسی

Cisco Secure Client نام کنونی همان خانواده کلاینت است، پس سندی که AnyConnect را ذکر می‌کند لزوماً کهنه نیست. آنچه مهم است نسخه‌ای است که سازمان شما به کار می‌گیرد و اینکه نسخه دستگاه در برابر آن اعتبارسنجی شده یا نه.

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

رکورد را با پنج فیلد بنویسید

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

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