VPN برای هر برنامه یا split tunnel؟ یک مسیر Mac چه چیزی را می‌تواند تعیین کند

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

انتخاب‌کننده یک مقصد است، هرگز یک فرایند نیست

هر تصمیم مسیریابی با یک نشانی مقصد آغاز می‌شود و با یک رابط پایان می‌یابد. هسته هرگز نمی‌پرسد کدام برنامه بسته را فرستاده است، و در macOS pf نیز بر پایه فرایند مسیریابی نمی‌کند، بنابراین یک قاعده دیوار آتش نمی‌تواند یک برنامه را روی مسیر دیگری بگذارد. به همین دلیل همان سرور، چه از مرورگر و چه از ابزار گزارش‌گیری، برای هر دو یک مسیر دارد. بنابراین جداسازی در سطح برنامه باید از چیزی جز مسیر بیاید: یک افزونه VPN که سوکت را در اختیار دارد، یک پروکسی که اتصال را به نام برنامه برمی‌دارد، یا یک پشته شبکه جداگانه. هیچ‌یک از این‌ها تغییر مسیریابی نیست.

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

split tunnel معمولی در عمل چه می‌دهد

split tunnel مسیرهایی برای پیشوندهای خصوصی نصب می‌کند و همه چیز دیگر را روی مسیر فیزیکی می‌گذارد. معمولاً منظور درخواست همین است: رسیدن به سرور اداری از طریق تونل و مستقیم نگه داشتن مرور عمومی. ساده است، هر کلاینت رایجی از آن پشتیبانی می‌کند و با همان سازوکاری که هر مسیر دیگری اعمال می‌شود. مقصد مشخص را با route -n get بررسی کنید نه با خواندن مسیر پیش‌فرض، زیرا split tunnel اغلب مسیر پیش‌فرض را دست‌نخورده می‌گذارد.

ویرایش دستی مسیر پیش‌فرض تبدیل شدن به چیزی نیست. با بازگردانی مسیرهای خود کلاینت می‌جنگد و در کلاینت‌هایی که سیاست حفاظتی نصب می‌کنند می‌تواند دستگاه را در وضعیتی بگذارد که نه شما و نه کلاینت انتظارش را ندارید. به جای آن split tunnel را در تنظیمات پشتیبانی‌شده کلاینت پیکربندی کنید.

VPN هر برنامه در macOS چه می‌خواهد

VPN واقعی برای هر برنامه در macOS یک ویژگی Network Extension است که با یک نمایه پیکربندی هدایت می‌شود. یک بار مدیریتی برنامه‌های انتخاب‌شده را به یک پیکربندی VPN نگاشت می‌کند و سیستم سپس ترافیک آن برنامه‌ها را بر همان اساس مسیریابی می‌کند. این یک استقرار مدیریت‌شده است، یعنی MDM، نمایه امضاشده و مدیری که هر دو را در اختیار دارد.

نصب دستی کلاینت آن نگاشت را ایجاد نمی‌کند و پنل تنظیمات معمولی برنامه‌ها را به صورت جداگانه قابل انتخاب نمی‌کند. یک فروشنده می‌تواند قاعده‌های برنامه خود را ارائه کند و آن‌ها از مستندات او پیروی می‌کنند نه از یک قاعده کلی.

سه راه برای جداسازی در سطح برنامه بدون MDM

جایی که مدیریت در دسترس نیست، پروکسی پاسخ عملی است. پیکربندی پروکسی خود برنامه را تنظیم کنید یا از یک فایل PAC استفاده کنید که فقط برای همان برنامه بر پایه مقصد و پروتکل انتخاب می‌کند.

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

درخواست را طوری بنویسید که پاسخ روشن باشد

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

مورد برنامه استثناشده را صریح بگنجانید. کلاینتی که وقتی مسیر محافظت‌شده‌اش در دسترس نیست برنامه‌ای را متوقف می‌کند، رفتاری متفاوت از کلاینتی دارد که اجازه می‌دهد به رابط فیزیکی بازگردد، و کاربران آن تفاوت را فوراً متوجه می‌شوند. انتظار را در تیکت نام ببرید. سپس روی دستگاه واقعی بررسی کنید، زیرا همان محصول در macOS اغلب متفاوت از Windows رفتار می‌کند و مستندات macOS آن تنها منبع قابل اعتماد درباره کاری است که تنظیماتش می‌کنند.