VPN مک، فیلتر محتوا یا Private Relay: کدام فعال است
سه لایه شبکه در مک در تنظیمات شبیه هم به نظر می‌رسند. با مسیر خروج، سیاست جریان و دامنه مرور، VPN، فیلتر محتوا و Private Relay را از هم جدا کنید.
مک شما می‌تواند هم‌زمان یک تونل VPN، یک فیلتر محتوا و iCloud Private Relay نصب داشته باشد و هیچ‌کدام اعلام نمی‌کند کدام یک یک اتصال مشخص را شکل می‌دهد. پنجره‌های تنظیمات شبیه هم به نظر می‌رسند، نمادها شبیه هم به نظر می‌رسند و تقریباً هر فروشنده‌ای محصول خود را امنیت شبکه می‌نامد. سه واقعیت آن‌ها را جدا می‌کند: اینکه ترافیک از یک نقطه پایانی راه‌دور که می‌توانید نامش را ببرید خارج می‌شود یا نه، اینکه یک موتور سیاست درباره جریان‌های تک‌تک تصمیم مجاز یا رد می‌گیرد یا نه، و اینکه حفاظت در Safari متوقف می‌شود یا نه. این سه را مرتب کنید و بیشتر پرسش‌های از نوع آیا VPN من روشن است خودشان جواب می‌دهند.
سه شرطی که آن جزء را شناسایی می‌کند
شرط اول خروج است. ارائه‌دهنده تونل بسته‌ها را به یک دروازه راه‌دور می‌سپارد، پس نشانی عمومی شما تغییر می‌کند و اگر پروفایل چنین بگوید، میزبان‌های پشت آن دروازه در دسترس می‌شوند. اگر نشانی هرگز تغییر نکند و هیچ زیرشبکه خصوصی باز نشود، شما به یک تونل کارکننده نگاه نمی‌کنید، هر چه نوار منو بگوید.
شرط دوم تصمیم است. فیلتر محتوا جریان‌ها را ارزیابی می‌کند و مجاز یا رد برمی‌گرداند. می‌تواند مسدودسازی یک دسته، قاعده‌ای برای هر برنامه یا سیاستی را که کارفرما فرستاده اجرا کند و می‌تواند حکم را ثبت کند. چیزی که خودبه‌خود نمی‌تواند انجام دهد این است که به ترافیک جایی برای رفتن بدهد.
شرط سوم دامنه است. Private Relay بخش مشخصی از مرور را حفاظت می‌کند نه کل دستگاه را، و کارش جدا کردن این است که شما کیستید از آنچه بازدید می‌کنید، نه قرار دادن شما در شبکه‌ای دیگر.
این سه را کنار هم بگذارید و مرزها سخت از چشم دور می‌مانند:
| Layer | Question it answers | Evidence to look for | What it does not do |
|---|---|---|---|
| VPN tunnel provider | Where does my traffic emerge, and which private networks can I reach? | Changed public address, a connected service, a default route through a utun interface | Enforce per-app content policy |
| Content filter | May this flow proceed, and who decided? | A filter extension in Network Extensions, drop verdicts, an MDM profile | Supply a different public exit |
| iCloud Private Relay | Can the local network see which sites Safari loads? | A relay egress address in Safari only, the relay toggle in iCloud settings | Cover other apps or grant access to a private subnet |
فیلتر محتوا یک موتور سیاست است، نه یک خروج
در macOS فیلتر به‌صورت یک Network Extension می‌آید که بر پایه کلاس ارائه‌دهنده داده فیلتر اپل، NEFilterDataProvider ساخته شده است. در استقرار مدیریت‌شده، MDM آن را هل می‌دهد، به‌عنوان افزونه سیستم نصب می‌شود و یک بار در System Settings > General > Login Items and Extensions تأیید می‌شود. از آن پس جریان‌های TCP و در برخی پیکربندی‌ها UDP را هم می‌بیند و درباره هرکدام حکمی برمی‌گرداند.
شیوه شکست چیزی است که مردم را گیج می‌کند. فیلتری که جریانی را رد می‌کند، یک پایان مهلت، یک دست‌دادن TLS متوقف‌شده یا یک بازنشانی تولید می‌کند که دقیقاً شبیه تونلی است که بالا آمده اما نمی‌تواند ترافیک را عبور دهد. نشانی عمومی هرگز تغییر نکرد، چون هرگز خروجی نبود که آن را تغییر دهد.
کارخواه‌های تجاری اغلب هر دو نقش را یکجا می‌آورند. یک نصب‌کننده هم ارائه‌دهنده تونل را می‌آورد هم فیلتر را، فیلتر مسدودسازی می‌کند و تونل مسیریابی. پس نام برنامه هیچ چیزی درباره اینکه کدام جزء اتصال را رد کرده به شما نمی‌گوید. فهرست افزونه‌ها، سپس سرویس متصل، سپس گزارش کارخواه را به همین ترتیب بررسی کنید.
Private Relay سافاری را می‌پوشاند، نه کل ماشین را
Private Relay مروری را که می‌پوشاند از میان دو رله که طرف‌های جداگانه اداره‌شان می‌کنند می‌فرستد، پس هیچ اپراتور واحدی هم هویت شما و هم مقصدهای شما را ندارد. این یک طراحی حریم خصوصی است، نه تونل: دروازه‌ای برای ورود نیست، زیرشبکه خصوصی نیست و راهی برای میخ‌کردن یک نشانی خروج در کشوری که خودتان انتخاب می‌کنید وجود ندارد.
دامنه‌اش عمداً باریک است و مرور Safari را همراه با جست‌وجوهای DNS و بارگذاری‌های ناامن HTTP که با آن می‌آیند می‌پوشاند. نشست ترمینال، کارخواه ایمیل، برنامه گفت‌وگو و راه‌انداز بازی بیرون آن می‌مانند. اگر بررسی‌ای در ترمینال هنوز نشانی شبکه دسترسی شما را نشان دهد در حالی که Safari نشانی رله را نشان می‌دهد، این نتیجه مورد انتظار است، نه نصبی خراب.
دسترس‌پذیری مشروط است. به طرح iCloud+ نیاز دارد، در هر منطقه ارائه نمی‌شود و یک شبکه مدیریت‌شده می‌تواند دسترسی رله را مسدود کند، که در آن صورت Safari به اتصال مستقیم برمی‌گردد. مرور کلی Private Relay از اپل مرجع دامنه کنونی است. وقتی پروفایل VPN متصل است و آن ترافیک را می‌برد، رله روی آن سوار نمی‌شود؛ مسیر را پروفایل تعیین می‌کند.
شواهد را به ترتیب درست بخوانید
با وضعیت سرویس شروع کنید، چون ارزان‌ترین نشانه است. scutil --nc list سرویس‌های VPN پیکربندی‌شده و اینکه هرکدام متصل است یا نه را چاپ می‌کند. یک پروفایل می‌تواند سال‌ها بی‌آنکه هرگز متصل شود آنجا بماند و مردم مرتب آن را تونل به حساب می‌آورند.
سپس به رابط‌ها و مسیرها نگاه کنید. ifconfig رابط‌های utun را نشان می‌دهد، اما حضورشان به‌تنهایی چیز زیادی اثبات نمی‌کند، چون macOS از utun برای چند منظور جز VPN هم استفاده می‌کند. آنچه اهمیت دارد این است که مسیر پیش‌فرض به یکی از آن‌ها اشاره کند، که route -n get default گزارش می‌کند.
برای حل نام، scutil --dns حل‌کننده‌هایی را فهرست می‌کند که سیستم واقعاً استفاده خواهد کرد و یک ارائه‌دهنده پراکسی DNS هم آنجا دیده می‌شود. مقایسه dig +short example.com با dig +short example.com @1.1.1.1 حل‌کننده‌ای که پاسخ می‌دهد را از حل‌کننده‌ای که رهگیری می‌شود جدا می‌کند.
فعالیت افزونه‌ها به گزارش یکپارچه می‌رسد: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. شما دنبال این هستید که کدام افزونه شروع شد و آیا فیلتری درباره جریانی که برایتان مهم است حکمی گزارش کرد، نه دنبال خطی برای حفظ کردن.
پیش از غیرفعال کردن هر چیزی، نشانه را باریک کنید
نخست شکست را دسته‌بندی کنید. نامی که حل نمی‌شود، اتصالی که بی‌درنگ رد می‌شود و اتصالی که تا پایان مهلت معلق می‌ماند سه مشاهده متفاوت با سه مسئول متفاوت‌اند. حل نام به یک حل‌کننده یا پراکسی DNS اشاره دارد. رد بی‌درنگ به یک قاعده فیلتر اشاره دارد. سکوت معمولاً به مسیریابی اشاره دارد، یا به تونلی که بالاست اما فرستادن را انجام نمی‌دهد.
روی مک مدیریت‌شده فرض کنید فیلتر متعلق به سازمان است. غیرفعال کردنش برای آزمودن VPN همان جزئی را برمی‌دارد که می‌خواستید مشاهده کنید و MDM اغلب در بررسی بعدی آن را برمی‌گرداند. پیش از هر تغییری نام سیاست را از مدیر بخواهید و با همان برنامه‌ای که شکست خورده آزمایش کنید، نه با کل سیستم.
یک تله دیگر: خاموش کردن Private Relay برای آزمودن VPN هیچ چیزی درباره ترافیک خارجی نمی‌گوید، چون رله هرگز آن ترافیک را نمی‌پوشاند. هر لایه باید در برنامه‌ای آزموده شود که واقعاً بر آن حکومت می‌کند.
این فهرست را جلو ببرید و در نخستین موردی که شکست می‌خورد بایستید:
- آیا
scutil --nc listسرویسی را که انتظار دارید متصل نشان می‌دهد؟ - آیا نشانی عمومی که از ترمینال دیده می‌شود با نشانی‌ای که شبکه دسترسی شما داده تفاوت دارد؟
- آیا افزونه فیلتری نصب است و آیا درباره جریان شکست‌خورده حکمی ثبت کرد؟
- آیا شکست فقط در Safari است؟ اگر چنین است، پیش از متهم کردن تونل، دامنه رله را بررسی کنید.
اگر هر چهار مورد بگذرند و برنامه همچنان شکست بخورد، مشکل بالاتر از لایه شبکه است: تنظیمات پراکسی، اعتماد به گواهی یا فهرست مجاز در سطح برنامه.