قفل VPN با PF در Mac: یک سیاست سایت، نه قابلیتی قابل عرضه
Packet Filter یک API پشتیبانی‌شده برای محصولات توزیع‌شده نیست. به مجموعه قواعد یک مالک بدهید، هر استثنا را نام ببرید و گذارها را آزمایش کنید.
روی Mac شما کار می‌کند، پس به نظر چیزی می‌رسد که می‌توانید به کاربران بسپارید. همین فرض نخستین چیزی است که باید از دست بدهید. سند TN3165 اپل صریحاً می‌گوید Packet Filter یک API پشتیبانی‌شده برای محصولات عموماً توزیع‌شده نیست، و مدیریت ممتاز و کنترل‌شده سایت را حالت منطقی می‌داند. بنابراین قفل VPN ساخته‌شده بر PF یک سیاست عملیاتی محلی با مالک است، نه قابلیتی که بتوانید درون یک برنامه عرضه کنید.
PF سطح بسته‌بندی نیست
این تمایز دانشگاهی نیست. محصول توزیع‌شده‌ای که به PF وابسته است، هر تغییری را که اپل در آن می‌دهد، هر تعارضی با ابزار دیگری را که آن هم قاعده می‌نویسد، و هیچ تعهد پشتیبانی‌ای که این ترتیب به کار ادامه دهد به ارث می‌برد. سایتی که دستگاه‌های خودش را مدیریت می‌کند رابطه دیگری دارد: می‌تواند وابستگی را مستند کند، آن را در برابر هر نسخه سیستم‌عامل آزمایش کند و نگهداری را بپذیرد.
برخی توصیه‌های نصب از خطی عبور می‌کنند که ارزش نام بردن دارد. بازنویسی کل مجموعه قواعد سیستم برای بارگذاری یک لنگر، ویرایش پیکربندی راه‌اندازی سیستم اپل، یا غیرفعال کردن System Integrity Protection الزامات قابل‌قبولی برای یک دستورالعمل قابل استفاده مجدد نیستند. اگر راهنمای منتشرشده‌ای به هر یک از این‌ها نیاز دارد، در حال توصیف یک آزمایشگاه است، نه سیاستی قابل استقرار.
قصد خروج را پیش از دستور بنویسید
پیش از انتخاب حتی یک کلمه کلیدی تصمیم بگیرید چه چیزی مجاز است. معمولاً سه مسیر باید وجود داشته باشد: انتقال خود کلاینت VPN به سرور خود، ترافیک برنامه محافظت‌شده درون تونل، و هر آنچه راه‌اندازی یا سرویس‌های محلی واقعاً به مسیر مستقیم نیاز دارند.
به هر استثنای پیشنهادی یک مقصد، یک انتقال و یک مالک بدهید. مجاز کردن همه پورت‌ها به یک نقطه پایانی بسیار بیشتر از تنها انتقالی که تونل استفاده می‌کند اجازه می‌دهد، و مواجهه اضافه بدون آنکه کسی تصمیم گرفته باشد باید وجود داشته باشد می‌آید. مجاز کردن یک resolver عمومی همان تله در لباس دوستانه‌تر است: مسیر مستقیم DNS ایجاد می‌کند حتی وقتی تونل قطع است، پس جستجوی نام‌ها همچنان نشت می‌کند.
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
آزمون سودمند یک استثنا این است که آیا می‌توانید شخصی را که آن را خواسته و خرابی‌ای را که از آن جلوگیری می‌کند نام ببرید. اگر هیچ‌یک از این دو پاسخ وجود ندارد، قاعده احتمالاً راهی میان‌بر برای پیکربندی نادرستی است که در غیر این صورت نادیدنی می‌ماند.
شماره‌های utun هویت نیستند
MacOS رابط‌های تونل را به‌صورت دستگاه‌های utun می‌سازد، و شماره‌ای که به VPN شما داده می‌شود پایدار نیست در طول راه‌اندازی‌های مجدد، اتصال‌های دوباره یا حضور کلاینت دیگری. قاعده‌ای که چند شماره حدس‌زده را فهرست می‌کند سیاست نیست؛ عکسی از یک بعدازظهر است.
قاعده را به چیزی لنگر کنید که ارائه‌دهنده موردنظر را شناسایی کند: طرح آدرسی که تونل تخصیص می‌دهد، فرآیندی که مالک رابط است، یا پیکربندی‌ای که خود کلاینت VPN نگه می‌دارد. سپس ثبت کنید آن شناسایی چگونه کار می‌کند، چون کسی که یک سال بعد قاعده را بازبینی می‌کند تاریخچه شل شما را نخواهد داشت.
سیاست بارگذاری‌شده را قابل انتساب کنید
نام لنگر قواعد را سازمان می‌دهد؛ ثابت نمی‌کند که سیاست مؤثر همان چیزی است که قصد داشتید. اولویت میان لنگرها، قواعدی که نرم‌افزار دیگر بارگذاری کرده و وضعیت موجود همه می‌توانند نتیجه را تغییر دهند. مجموعه مؤثر را با هر کس دیگری که PF را روی آن دستگاه دارد بازبینی کنید و مالکیت را در همان جایی مستند کنید که پیکربندی هست. دو مالک که لنگرهای مختلف را با فرض‌های مختلف ویرایش می‌کنند راه معمول ایجاد سوراخ در یک قفل است.
مجموعه قواعد را در مسیر پیکربندی پشتیبانی‌شده سایت نگه دارید، آن را نسخه‌بندی کنید و یادداشت کنید کدام نسخه‌های macOS آزمایش شده‌اند. تغییری که دستی اعمال شود و یک نفر به یاد بسپارد زیرساخت نگهداری‌شده نیست، هرچه سرصفحه فایل بگوید.
گذارها را آزمایش کنید، نه وضعیت متصل
تصویر صفحه‌ای که هنگام بالا بودن تونل گرفته شده تقریباً هیچ چیز را ثابت نمی‌کند. به‌جای آن وضعیت‌ها را طی کنید: راه‌اندازی پیش از هر اتصال، تونلی کارکننده، تونلی که بدون هشدار می‌افتد، قطع عمدی، و گذار از Wi-Fi به هات‌اسپات. هر وضعیت پاسخ خودش را دارد و موارد جالب شکست‌ها هستند نه مسیر خوش.
در هر وضعیت ثبت کنید چه چیزی عمداً در دسترس است. IPv4 و IPv6 را جداگانه بررسی کنید، تجزیه نام را آزمایش کنید و جریانی را بگنجانید که پیش از گذار برقرار شده بود، چون اتصال‌های موجود همیشه از سیاست جدید پیروی نمی‌کنند. مرورگری که وقتی تونل قطع است شکست می‌خورد یک نقطه داده است، نه شاهدی بر مسدود بودن هر مسیر دیگر.
در پایان، روش بازیابی‌ای نگه دارید که به مسیر شبکه‌ای که تغییر می‌دهید وابسته نباشد. پیکربندی شناخته‌شده سالم روی حافظه محلی و روشی مستند برای بارگذاری آن، قفل را به سیاست تبدیل می‌کند؛ بدون آن‌ها، یک بازبینی بد مدیر را از دستگاهی که قرار بود محافظت شود بیرون می‌بندد.