VPN على Mac أو فلتر محتوى أو Private Relay: أيّها يعمل فعلاً؟
ثلاث طبقات شبكة على Mac تبدو متشابهة في الإعدادات. استخدم مسار الخروج وسياسة التدفق ونطاق التصفح للتمييز بين VPN وفلتر محتوى وPrivate Relay.
قد يكون على جهاز Mac لديك نفق 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 مبني على صنف موفّر بيانات الفلتر من Apple، NEFilterDataProvider. في النشر المُدار يُدفع عبر MDM، ويُثبَّت كامتداد نظام، ويُعتمد مرة واحدة ضمن إعدادات النظام، عام، عناصر تسجيل الدخول والامتدادات. من ذلك الحين يرى تدفقات TCP، وفي بعض التهيئات UDP أيضاً، ويعيد حكماً على كل واحد منها.
نمط الفشل هو ما يربك الناس. الفلتر الذي يُسقط تدفقاً يُنتج مهلة أو مصافحة TLS متوقفة أو إعادة تعيين، وهو ما يبدو تماماً كنفق قام لكنه لا يمرّر حركة المرور. لم يتغيّر العنوان العام أبداً، لأنه لم يكن هناك مخرج لتغييره.
غالباً ما تجمع العملاء التجاريون الدورين معاً. مثبّت واحد يشحن مزوّد نفق وفلتراً، فالفلتر يقوم بالحجب والنفق يقوم بالتوجيه. لذا لا يخبرك اسم التطبيق بشيء عن المكوّن الذي رفض الاتصال. افحص قائمة الامتدادات، ثم الخدمة المتصلة، ثم سجل العميل، بهذا الترتيب.
Private Relay يغطي Safari، لا الجهاز
يرسل Private Relay التصفح الذي يغطيه عبر مرحّلين يديرهما طرفان منفصلان، فلا يحتفظ مشغّل واحد بهويتك ووجهاتك معاً. ذلك تصميم للخصوصية، لا نفق: لا توجد بوابة يمكنك الوصول إليها، ولا شبكة فرعية خاصة، ولا طريقة لتثبيت عنوان خروج في بلد تختاره.
نطاقه ضيق عن قصد، ويغطي تصفح Safari مع استعلامات DNS وتحميلات HTTP غير الآمنة المرافقة له. جلسة طرفية وعميل بريد وتطبيق محادثة ومشغّل ألعاب تقع خارجه. إذا أظهر فحص في Terminal عنوان شبكة وصولك بينما يعرض Safari عنوان مرحّل، فذلك النتيجة المتوقعة، لا تثبيت معطوب.
التوفّر مشروط. يحتاج إلى خطة iCloud+، وهو غير متاح في كل منطقة، ويمكن لشبكة مُدارة أن تحجب الوصول إلى المرحّل، وفي هذه الحالة يعود Safari إلى اتصال مباشر. نظرة Apple العامة على 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. الرفض الفوري يشير إلى قاعدة في الفلتر. الصمت عادة يشير إلى التوجيه، أو إلى نفق قائم لكنه لا يمرّر.
على جهاز Mac مُدار، افترض أن الفلتر يخص المؤسسة. تعطيله لاختبار VPN يزيل المكوّن الذي كنت تحاول مراقبته، وغالباً ما يعيد MDM تثبيته عند تسجيل الوصول التالي. اطلب من المسؤول اسم السياسة قبل أن تغيّر أي شيء، واختبر بالتطبيق المحدد الذي فشل بدلاً من النظام كله.
فخ آخر: إيقاف Private Relay لاختبار VPN لا يخبرك شيئاً عن حركة المرور الأجنبية، لأن المرحّل لم يغطِّ تلك الحركة من الأصل. كل طبقة يجب أن تُختبر على التطبيق الذي تحكمه فعلاً.
اعمل عبر هذه القائمة وتوقف عند أول بند يفشل:
- هل يُظهر
scutil --nc listالخدمة التي تتوقعها كمتصلة؟ - هل يختلف العنوان العام الظاهر من Terminal عن العنوان الذي خصّصته شبكة وصولك؟
- هل امتداد الفلتر مثبّت، وهل سجّل حكماً على التدفق الفاشل؟
- هل الفشل في Safari فقط؟ إن كان كذلك، افحص نطاق المرحّل قبل لوم النفق.
إذا نجحت الأربعة جميعاً وظل التطبيق يفشل، فالمشكلة فوق طبقة الشبكة: إعدادات الوكيل، أو ثقة الشهادة، أو قائمة سماح على مستوى التطبيق.