SonicWall VPN روی Mac: کلاینت SSL یا L2TP بومی؟
کلاینت Mac را بر اساس سرویس دسترسی از راه دوری که دروازه واقعاً اجرا می‌کند انتخاب کنید. یک ورودی L2TP بومی هرگز به نقطه پایانی SSL VPN نمی‌رسد، هر برندی که باشد.
از Mac شروع کنید و سپس به بیرون حرکت کنید، زیرا تصمیم کلاینت را فایروال می‌گیرد و فقط روی دسکتاپ بازتاب می‌یابد. تنظیمات سیستم را باز کنید، ببینید چه پیکربندی VPN از قبل وجود دارد، و پیش از تایپ رمز عبور یک پرسش از مدیر بپرسید. پاسخ، سرویس دسترسی از راه دور فعال است، نه مدل دستگاه در صفحه ورود. دو کلاینت می‌توانند روی یک لپ‌تاپ باشند و هیچ‌کدام هم درست نباشد.
از دروازه بپرسید کدام سرویس روشن است
دو سرویس دسترسی از راه دور زیر یک نام محصول ظاهر می‌شوند و رفتاری کاملاً متفاوت دارند. یکی SSL VPN است که با کلاینت فروشنده به آن می‌رسند، و دیگری IPsec یا L2TP است که کلاینت داخلی macOS می‌تواند شماره‌گیری کند. آن‌ها در پورت‌ها، احراز هویت و تخصیص نشانی متفاوت‌اند، پس پروفایل یکی برای دیگری بی‌فایده است. انتخاب تنها از سمت Mac حدسی است که لباس پیکربندی پوشیده است.
سه چیز را همزمان بخواهید: سرویسی که دارای مجوز و فعال است، کلاینت و نسخه‌ای که آن سرویس روی macOS پشتیبانی می‌کند، و جریان احراز هویتی که انتظار دارد. هر چیز کمتری شما را در شکست بعدی به حدس زدن وا می‌دارد.
مسیر L2TP بومی را طی کنید
اتصال بومی روی Mac هر زمان که پروفایلی افزوده شده باشد وجود دارد، و پنجره تنظیمات آن را کنار Wi-Fi و Ethernet نشان می‌دهد. اگر فهرست خالی باشد، دستگاه هیچ پیکربندی VPN ندارد و مشکل در تأمین است، نه در اتصال. دستور زیر آنچه سیستم واقعاً نگه می‌دارد را چاپ می‌کند، از جمله پیکربندی‌هایی که رابط ممکن است پنهان کند.
پیش از افزودن هر چیزی خروجی را بخوانید، زیرا پروفایل قدیمی با نامی آشنا دلیل رایجی است که پیکربندی جدید نادیده گرفته شود. سپس نشانی سرور را با نشانی‌ای که مدیر به شما داده مقایسه کنید، نه با نشانی یک تیکت قدیمی. هر دو بررسی یک دقیقه طول می‌کشند و دو بن‌بست معمول را برمی‌دارند.
scutil --nc list
networksetup -listallnetworkservicesیک ورودی L2TP بومی همچنین به راز مشترک، نام کاربری و رمز عبور، و دروازه‌ای نیاز دارد که آن سرویس را روی پورت‌های مورد انتظار ارائه دهد. وقتی هر یک از این‌ها نباشد، Mac خطای احراز هویت یا خطای پاسخ ندادن سرور را گزارش می‌کند، و هیچ‌یک از این دو پیام راز اشتباه را از سرویسی که هرگز فعال نشده تشخیص نمی‌دهد. وقتی یادداشت‌ها را با مدیر مقایسه می‌کنید، هر سه مقدار را کنار هم نگه دارید.
مسیر کلاینت SSL را طی کنید
کلاینت SSL VPN از طریق TLS به یک درگاه وب متصل می‌شود، سپس تونل خودش و سیاست نشانی خودش را اجرا می‌کند. به نشانی درگاه، یک حساب و عامل دومی که استقرار الزام می‌کند نیاز دارد، و معمولاً نخستین بار که اجرا می‌شود یک افزونه شبکه نصب می‌کند. پروفایلی که برای یک کلاینت صادر شده به‌ندرت در کلاینت دیگر وارد می‌شود، حتی وقتی هر دو در زیر IPsec حرف می‌زنند. هیچ‌یک از این‌ها تا تأیید افزونه در فهرست VPN تنظیمات سیستم دیده نمی‌شود.
دو کلاینت SSL که کنار هم نصب شده‌اند می‌توانند بر سر یک افزونه شبکه رقابت کنند، و کلاینتی که اول بارگذاری شده معمولاً برنده می‌شود. پیش از نصب کلاینت تأییدشده کلاینت بی‌استفاده را حذف کنید، سپس دوباره راه‌اندازی کنید تا فهرست افزونه‌ها بازسازی شود.
نسخه macOS را با بیانیه پشتیبانی فعلی فروشنده بسنجید پیش از نصب، و انتظار داشته باشید که نصب‌کننده در حریم خصوصی و امنیت درخواست تأیید کند. افزونه مسدودشده دقیقاً مانند اتصالی است که هرگز شروع نمی‌شود.
اطلاعیه تغییر برند را درست بخوانید
نام کلاینت‌ها جابه‌جا می‌شوند، و تغییر نام تغییر پروتکل نیست. اطلاعیه فروشنده که Mobile Connect در حال تبدیل شدن به NetExtender است برندسازی را توصیف می‌کند، بنابراین یک بیانیه قدیمی درباره پشتیبانی از سکوهای دسکتاپ را نمی‌توان به هر برنامه‌ای که نام جدید را دارد منتقل کرد.
کلاینتی را که واقعاً نصب کرده‌اید با شناسه بسته و نسخه شناسایی کنید، نه با برچسب روی آیکون. همین تمایز تعیین می‌کند کدام ماتریس پشتیبانی برای Mac شما اعمال می‌شود.
اگر سرویس فعال و کلاینت پشتیبانی‌شده Mac هیچ همپوشانی نداشته باشند، گزینه‌های صادقانه یک سرویس جایگزین تأییدشده یا یک تغییر برنامه‌ریزی‌شده در دروازه است. بازنویسی یک سیاست مشترک برای راضی کردن یک لپ‌تاپ، یا خرید یک برنامه چون پاسخی در انجمن آن را ذکر کرده، مسئله سازگاری را دقیقاً همان‌جا که شروع شده بود رها می‌کند.