کلاینت VPN مک: Network Extension در برابر System Extension
Network Extension یک توانایی است و System Extensions یک سازوکار تحویل: آنها را جدا کنید تا مرحله تأیید macOS و لاگ خواندنی را انتخاب کنید.
دو اصطلاح اپل طوری به کار میروند که گویی یک چیز را نام میبرند، و این سردرگمی مردم را به پنل تنظیمات اشتباه میفرستد. Network Extension یک توانایی را توصیف میکند: روشی پشتیبانیشده برای پیادهسازی تونلهای VPN، پروکسیها و فیلترها. System Extensions سازوکار تحویل و تأیید برای افزونههای فضای کاربر را توصیف میکند. یک کلاینت مدرن VPN در مک معمولاً به هر دو نیاز دارد، به همین دلیل هیچکدام از دو برچسب بهتنهایی یک نشانه را توضیح نمیدهد. جدا کردن این دو پاسخ میدهد کدام مؤلفه را بررسی کنید و کدام مرحله تأیید را انتظار داشته باشید.
دو پرسش، نه یک برچسب
پیش از پرسیدن اینکه مؤلفه چگونه نصب میشود بپرسید چه کاری انجام میدهد. توانایی تعیین میکند کدام کلاس ارائهدهنده وجود دارد و در نتیجه کدام کد بستههای شما را پردازش میکند. سازوکار تحویل تعیین میکند فایل دودویی چگونه میرسد، چگونه تأیید میشود و وضعیت آن کجا ثبت میشود. یک محصول میتواند تونل بسته را بدون ارائه افزونه سیستم در نسخههای قدیمیتر پیادهسازی کند، و میتواند افزونه سیستمی ارائه دهد که چیزی جز تونل را پیادهسازی میکند.
افزونههای هسته سومین اصطلاحی هستند که مردم با آن اشتباه میکنند. آنها روش قدیمیتر اجرای کد شبکهای ممتاز بودند، تأییدهای متفاوتی لازم داشتند و اپل سالهاست توسعهدهندگان را از آنها دور میکند. اعمال دستور تأیید افزونه هسته بر یک کلاینت مدرن، زمان را در پنجرهای تلف میکند که هرگز ظاهر نخواهد شد.
یادداشتهای استقرار فروشنده را برای نسخه macOS که اجرا میکنید بخوانید به جای پستی در انجمن از نسخهای قدیمیتر. معماری بیش از یک بار تغییر کرده است و دستورالعملها زود کهنه میشوند. یادداشتی که به تأیید افزونه هسته اشاره میکند، دوران دیگری از محصول را توصیف میکند.
Network Extension چه چیزی فراهم میکند
چارچوب انواع ارائهدهنده را برای کارهای رایج شبکه فراهم میکند: تونل بسته برای ترافیک VPN، پروکسی برنامه برای جریانهای هر برنامه، فیلتر محتوا برای بازرسی ترافیک و مدیریت پروکسی DNS برای رفتار تحلیلگر. نوع ارائهدهنده تعیین میکند افزونه چه کاری میتواند انجام دهد، و کلاینتی که دو ارائهدهنده ارائه میکند ممکن است دو کار متفاوت انجام دهد.
این در تشخیص اهمیت دارد چون همان نشانه اتصال میتواند از تونل، فیلتر یا پروکسی DNS بیاید. مسدود کردن یک وبسایت تصمیم فیلتر است، نرسیدن به یک زیرشبکه خصوصی معمولاً تصمیم تونل است، و حل کردن آدرس اشتباه معمولاً تصمیم تحلیلگر است. نام بردن نوع ارائهدهنده جستجو را پیش از خواندن هر لاگ محدود میکند.
هیچ چیز در چارچوب به موضع حریم خصوصی اشاره ندارد. افزونه فضای کاربر هنوز مجوزها، پیکربندی و اپراتوری پشت سر دارد، پس معماری را جزئیات پیادهسازی بدانید نه نشانه اعتماد. بپرسید چه کسی نقطه پایانی را اداره میکند و برای جمعآوری چه چیزی پیکربندی شده است.
System Extensions چه چیزی را تغییر میدهد
این سازوکار کد ممتاز را از هسته به فضای کاربر منتقل میکند و نحوه درخواست رضایت توسط سیستمعامل را تغییر میدهد. فعالسازی مرحلهای جدا از نصب است و کاربر یا یک نمایه MDM باید آن را مجاز کند. کلاینتی که نصب میشود اما هرگز فعال نمیشود در پوشه Applications حاضر به نظر میرسد و برای اتصال کاری انجام نمیدهد.
وضعیت را سیستم ثبت میکند نه برنامه، که مفید است چون میتوان آن را پرسید. دستور زیر افزونههایی را که سیستم میشناسد و وضعیت فعالسازی آنها را فهرست میکند.
systemextensionsctl list
scutil --nc list
دستور اول پاسخ میدهد آیا مؤلفه نصب و فعال شده است. دستور دوم پیکربندیهای VPN را که سیستم نگه میدارد فهرست میکند، که پرسش دیگری است و اغلب همان چیزی است که وقتی نمایه اتصال گم شده و نه خراب است اهمیت دارد.
برای یک نشانه مشخص کدام را بررسی کنیم
پیش از باز کردن پنل تنظیمات، نشانه را با لایه جور کنید. پیکربندی گمشده پرسش نمایه است، مؤلفه نصبشده اما غیرفعال پرسش تحویل است، و مؤلفه فعالی که نمیتواند ترافیک را عبور دهد پرسش توانایی است.
| Symptom | First place to look |
|---|---|
| No VPN entry at all | Configuration profile or scutil list |
| Client installed, nothing happens | Extension activation state |
| Tunnel up, private host unreachable | Tunnel provider routes and policy |
| One app blocked, others fine | Filter or app proxy provider |
جریان لاگ شاهد مشترک دو ردیف آخر است. خواندن زیرسیستم افزونه شبکه میگوید کدام ارائهدهنده جریان را پردازش کرده، و تصمیم فیلتر با شکست تونل متفاوت به نظر میرسد حتی وقتی کاربر هر دو را VPN خراب توصیف میکند.
log show --last 10m --predicate 'process == "nesessionmanager"'
نتیجه نگیرید که افزونهای فعال است چون نمادی در نوار منو هست. نمادها از فعالسازیهای ناموفق جان سالم به در میبرند، و نماد کهنه یکی از رایجترین دلایل شروع تماس پشتیبانی در جای اشتباه است. به جای آن وضعیت فعالسازی را بخوانید، چون سیستم همان را ثبت میکند.
تأیید، MDM و افسانه افزونه هسته
روی مکهای مدیریتشده مرحله تأیید متعلق به نمایه MDM است، و کاربری که در System Settings روی Allow کلیک میکند ممکن است هنوز توسط سیاستی که بهروز نشده مسدود شود. پیش از آنکه از کاربر بخواهید روی چیزی کلیک کند، از تیم رومیزی بپرسید کدام سازوکار افزونه را برای آن ناوگان تأیید میکند.
برای مک مدیریتنشده، اعلان تأیید یک بار ظاهر میشود و رد کردن میتواند تا نصب دوباره افزونه دائمی باشد. این رفتار دستگاهی را توضیح میدهد که کلاینت پیش از ارتقای سیستمعامل روی آن کار میکرد و اکنون اتصالی را گزارش میکند که هرگز برقرار نمیشود.
نوع ارائهدهنده، وضعیت فعالسازی و سازوکار تأیید را برای کلاینتی که مستقر میکنید یادداشت کنید. این سه واقعیت به بیشتر پرسشهای آینده درباره VPN مک پاسخ میدهد بدون باز کردن دوباره بحث توانایی در برابر تحویل.