چگونه یک کلاینت VPN مک برای دروازه‌ای که دارید انتخاب کنیم
SSL VPN یک خانواده محصول است، نه یک پروتکل. از صاحب دروازه کلاینت، پروفایل و روش ورود را بپرسید، سپس مسیرها و DNS را روی مک بررسی کنید.
شش اپلیکیشن VPN مک در یک صفحه دانلود ظاهر می‌شوند و هیچ‌کدام نمی‌گوید دروازه کارفرمای شما کدام را می‌پذیرد۔ این شکاف فروشگاه نیست؛ شکاف تحویل است۔ یک SSL VPN یک خانواده محصول است، نه یک پروتکل، بنابراین دو دروازه با صفحه‌های ورود یکسان می‌توانند کلاینت‌های متفاوتی بخواهند۔ ترتیبی که وقتی کسی یک مک و یک آدرس سرور به من می‌دهد به کار می‌برم این است: مشخص کنید دروازه چه می‌گوید، کلاینت سازگار با آن را انتخاب کنید، سپس پیش از سپردن کار به تونل مسیرها و DNS را بررسی کنید۔
از دروازه شروع کنید، نه از فروشگاه اپلیکیشن
برنامه روی مک شما اجرا می‌شود، اما چیز دیگری باید اتصال را بپذیرد و دسترسی بدهد: دروازه‌ای با گرداننده، آدرس، تنظیمات سازگار و راهی برای مجوز دادن به شما۔ یک کلاینت رایگان می‌تواند نرم‌افزار خوبی باشد و هیچ‌یک از این‌ها را نداشته باشد۔ دسترسی کاری، دروازه خانگی و خروج تجاری اینترنت سه نقطه شروع متفاوت‌اند که تصادفاً یک صفحه دانلود مشترک دارند۔
پیش از نصب یا جایگزینی هر چیزی، چهار پاسخ از کسی که سرویس را اداره می‌کند بگیرید:
حالت دسترسی: پورتال مرورگر، دسترسی به برنامه‌های انتخابی یا تونل کامل شبکه۔ این تعیین می‌کند آیا اصلاً کلاینت لازم دارید۔
خانواده دروازه و نسخه پشتیبانی‌شده: محصول، سرویس فعال و نسخه کلاینتی که هنوز بیلد macOS و سخت‌افزار مک شما را پشتیبانی می‌کند۔
احراز هویت: گذرواژه به‌همراه MFA، ورود از مرورگر، گواهی دستگاه یا بررسی وضعیت دستگاه۔ کلاینتی که جریان تأییدشده را ندارد وصل می‌شود و سپس رد می‌شود۔
مالکیت: منبع دانلود یا مدیریت مورد اعتماد، پروفایل مورد نظر و کسی که هنگام خرابی پشتیبانی می‌کند۔
مالکیت همان موردی است که مردم از آن می‌گذرند۔ روی مک مدیریت‌شده پروفایل اغلب از طریق سامانه مدیریت سازمان می‌آید و پیکربندی دست‌ساز در بررسی بعدی جایگزین می‌شود۔ پیش از جستجوی برنامه شخص ثالث بپرسید آیا انتظار می‌رود خودتان چیزی نصب کنید۔
SSL VPN یک برچسب خانوادگی است، نه پروتکل
TLS می‌تواند یک اتصال را محافظت کند، در حالی که تبادلی ویژه محصول در درون آن ورود، تخصیص نشست و ترافیک تونل را اداره می‌کند۔ همان تبادل درونی است که کلاینت باید پیاده‌سازی کند۔ مرورگری که به صفحه ورود HTTPS دروازه می‌رسد زنجیره گواهی و وب‌سرور را اثبات می‌کند؛ اثبات نمی‌کند که یک برنامه VPN بی‌ربط می‌تواند به همان ماشین تونل بسازد۔
OpenConnect روشن‌ترین نمونه‌ای است که می‌شناسم۔ مستندات پروژه آن حالت‌های پروتکل جداگانه را برای خانواده‌های مختلف دروازه فهرست می‌کند و هم‌کنش‌پذیری را از پشتیبانی رسمی فروشنده جدا می‌کند۔ اگر هر SSL VPN یک پروتکل حرف می‌زد، این حالت‌ها بی‌نیاز بودند۔
پروفایل OpenVPN همان محدودیت را برعکس دارد: قالب درون‌ریزی برای استقراری سازگار با OpenVPN است۔ اشتراک TLS به‌عنوان بلوک سازنده آن را به فایل پیکربندی برای یک دروازه سازمانی دلخواه تبدیل نمی‌کند۔ به همین دلیل ورود موفق در مرورگر یک مثبت کاذب است: دسترسی پورتال می‌تواند موفق شود در حالی که تونلی نیست، و تونلی که بالا می‌آید ممکن است بعداً با بررسی وضعیت دستگاه رد شود۔
کلاینت را با آنچه دروازه می‌گوید هم‌تراز کنید
وقتی خانواده معلوم شد، انتخاب سریع باریک می‌شود۔ این همان نگاشتی است که اول بررسی می‌کنم، و ستون آخر از هر امتیاز اپلیکیشن مهم‌تر است۔
| خانواده دروازه | کلاینت روی macOS | چه چیزی را زیر نظر بگیرید |
|---|---|---|
| IKEv2/IPsec، مستقل از فروشنده | کلاینت توکار macOS با پروفایل .mobileconfig | هویت سرور و پروفایلی که ممکن است مدیریت شود |
| OpenVPN 2.x | Tunnelblick یا خط فرمان openvpn | .ovpn به‌همراه اعتبارنامه؛ کلاینت خدمتی ارائه نمی‌دهد |
| WireGuard | کلاینت رسمی WireGuard یا wireguard-tools | پیکربندی همتا؛ دیده‌شدن wg show به کلاینت بستگی دارد |
| SSL VPN فروشنده (AnyConnect، Pulse، GlobalProtect، F5، Fortinet) | کلاینت فروشنده یا OpenConnect با --protocol صریح | ترکیب‌های پشتیبانی‌نشده، MFA و بررسی‌های وضعیت |
| فقط پورتال مرورگر | بدون کلاینت | دسترسی به برنامه‌ها تونل شبکه نیست |
دو سطر هشدار می‌خواهند۔ کلاینت توکار macOS پیاده‌سازی واقعی IKEv2 است، نه کلاینت عمومی SSL VPN: سرویسی که برای آن ساخته شده به پروفایل درست، هویت سرور مورد انتظار و اعتبارنامه نیاز دارد، و روی ماشین مدیریت‌شده آن پروفایل ممکن است قفل باشد۔ OpenConnect چند پروتکل فروشنده را از یک باینری پوشش می‌دهد، اما پروژه خودش پشتیبانی فروشنده را ادعا نمی‌کند؛ اسکن میزبان، قواعد تونل تقسیم‌شده که دروازه اعمال می‌کند یا جریان SSO خاص ممکن است فقط در کلاینت فروشنده وجود داشته باشد۔
WireGuard همین شکل را دارد۔ سرویس همتاها را می‌دهد، کلاینت تونل را، و پروفایل OpenVPN جایگزین نیست۔ یک نکته macOS: کلاینت App Store تونل‌هایش را درون یک افزونه شبکه نگه می‌دارد، بنابراین wg show از ابزارهای Homebrew ممکن است چیزی نشان ندهد در حالی که رابط فعال است۔ با مسیرها و ترافیک بررسی کنید۔
پیکربندی کنید، سپس با ترتیب ثابت بررسی کنید
یک کلاینت و یک پروفایل نصب کنید و یادداشت کنید چه چیزی را تغییر دادید۔ پیش از اتصال، یک خط پایه بگیرید تا بدانید تونل چه چیزی را عوض می‌کند:
scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dnsبا پروفایل داده‌شده وصل شوید و همان دستورها را تکرار کنید۔ در تونل کامل مسیر پیش‌فرض باید به رابط utun اشاره کند؛ با تونل تقسیم‌شده فقط پیشوندهای درونی مسیریابی می‌شوند و خروج عمومی شما باید بی‌تغییر به نظر برسد۔ DNS همان نیمه‌ای است که معمولاً خراب می‌ماند: scutil --dns حل‌کننده‌ها را به ترتیبی که سیستم استفاده می‌کند فهرست می‌کند، و یک حل‌کننده داخلی زیر یک حل‌کننده عمومی نام‌های داخلی را به سرور اشتباه می‌فرستد۔
برای سرویس OpenVPN، Tunnelblick کلاینت معقول و بی‌هزینه‌ای است و راهنمای خودش درباره نیمه غایب صریح است: خدمت VPN ارائه نمی‌دهد۔ روی .ovpn که گرفته‌اید دوبار کلیک کنید، بگذارید Tunnelblick نصبش کند، و نسخه را پیش از تکیه بر آن با نسخه macOS خود بسنجید۔
برای دروازه فروشنده اغلب از خط فرمان با OpenConnect آزمایش می‌کنم:
brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.comابزار گواهی دریافتی را چاپ می‌کند و پیش از اعتماد به زنجیره ناشناس صبر می‌کند؛ این پرسش یک ویژگی است و سنجاق کردن با --servercert pin-sha256:... بهتر از پذیرفتن هشداری است که نخوانده‌اید۔ Ctrl-C تونل را قطع می‌کند، چون openconnect پیش‌زمینه نه کلید توقف دارد نه منطق اتصال دوباره۔ این برای نشست تشخیصی خوب و به‌عنوان پیش‌فرض کار روزانه بد است۔
وقتی دروازه‌ای برای هم‌ترازی نیست
بعضی با مشکل معکوس می‌آیند: بی گرداننده، بی آدرس، بی سرویس۔ یک برنامه رایگان مک نمی‌تواند دسترسی ورودی روی یک روتر خانگی بسازد۔ اگر شبکه خودتان را از هتل می‌خواهید، کسی باید در خانه دروازه‌ای اداره کند، به‌روزش نگه دارد، آدرسش را منتشر یا حل کند و تصمیم بگیرد کدام دستگاه‌ها در دسترس باشند۔
اگر خروج اینترنت متفاوتی می‌خواهید نه دسترسی به شبکه خصوصی، سرویس را پیش از کلاینت انتخاب کنید۔ فهرست پروفایل خالی در یک کلاینت مستقل اغلب اشتراک رایگان خراب نیست؛ ممکن است اشتراک و سرور متصلی وجود نداشته باشد۔ هزینه‌ها را هم جدا نگه دارید: مجوز کلاینت، طرح سرویس و دروازه‌ای که خودتان اداره می‌کنید سه خرید متفاوت‌اند۔
مک کاری یک لایه سیاست اضافه می‌کند۔ یک برنامه بی‌هزینه حتی وقتی وصل می‌شود می‌تواند نادرست باشد، چون کلاینت تأییدشده ممکن است بررسی دستگاه یا جریان احراز هویتی را الزام کند که جایگزین ندارد۔ به‌جای کپی اعتبارنامه بین برنامه‌های بی‌ربط، جایگزین تأییدشده بخواهید و خاموش کردن حفاظت‌های پلتفرم را اصلاح سازگاری ندانید۔
نمایشگر دسکتاپ از راه دور هم محصول دیگری است۔ نشستی روی رایانه دیگر نشانتان می‌دهد؛ مسیر شبکه‌ای که تونل می‌دهد را به برنامه‌های محلی مک شما نمی‌دهد۔
فهرست کوتاه بررسی پیش از نخستین نشست واقعی
خانواده دروازه و حالت دسترسی را کتبی نام ببرید، فقط کلاینت سازگار نصب کنید و پروفایل استفاده‌شده را ثبت کنید۔ سپس سه چیز را با ترافیک واقعی تأیید کنید: مسیرهایی که تونل نصب کرده، ترتیب حل‌کننده‌ها و یک برنامه داخلی که با نام نه با IP به آن می‌رسید۔
اگر چیزی شکست خورد، هر بار یک متغیر را عوض کنید: کلاینت، پروفایل، جریان احراز هویت۔ پورتالی که بارگذاری می‌شود در حالی که تونل از شروع سر باز می‌زند، مشکل وب‌سرور را از مشکل سازگاری کلاینت جدا می‌کند۔ وقتی سرویس کاری پاسخ می‌دهد و مسیر عمومی مطابق انتظار رفتار می‌کند، یک چیدمان نام‌دار و پشتیبانی‌شده دارید نه توده‌ای از حدس۔