قفل VPN على Mac عبر PF: سياسة موقع، لا ميزة قابلة للشحن
Packet Filter ليس واجهة برمجة مدعومة للمنتجات الموزعة. امنح مجموعة القواعد مالكًا، وسمِّ كل استثناء، واختبر الانتقالات.
إنه يعمل على جهاز Mac الخاص بك، فيبدو شيئًا يمكنك أن تسلّمه للمستخدمين. هذا الافتراض هو أول ما يجب التخلي عنه. تنص TN3165 من Apple صراحةً على أن Packet Filter ليس واجهة برمجة تطبيقات مدعومة للمنتجات الموزعة عمومًا، وهي تصف إدارة الموقع المميّزة والمنضبطة بأنها الحالة المعقولة. لذلك فإن قفل VPN المبني على PF هو سياسة تشغيلية محلية لها مالك، وليس ميزة يمكنك شحنها داخل تطبيق.
PF ليس سطح تحزيم
التمييز ليس نظريًا. المنتج الموزع الذي يعتمد على PF يرث كل تغيير تجريه Apple عليه، وكل تعارض مع أداة أخرى تكتب القواعد أيضًا، ولا يحصل على أي التزام دعم بأن الترتيب سيظل يعمل. أما الموقع الذي يدير أجهزته بنفسه فعلاقته مختلفة: يمكنه توثيق الاعتماد، واختباره مع كل إصدار من نظام التشغيل، وقبول أعمال الصيانة.
بعض نصائح التثبيت تتجاوز حدًا يستحق التسمية. الكتابة فوق مجموعة قواعد النظام بأكملها لتحميل مرساة واحدة، أو تعديل تكوين الإقلاع في نظام Apple، أو تعطيل System Integrity Protection ليست متطلبات مقبولة لوصفة قابلة لإعادة الاستخدام. وإذا كان دليل منشور يحتاج إلى أي منها، فهو يصف مختبرًا لا سياسة قابلة للنشر.
اكتب نية الخروج قبل الصيغة
قرِّر ما هو مسموح قبل اختيار كلمة مفتاحية واحدة. عادةً يجب أن توجد ثلاثة مسارات: نقل عميل VPN نفسه إلى خادمه، وحركة التطبيقات المحمية داخل النفق، وكل ما تحتاجه الإعدادات أو الخدمات المحلية فعلاً من مسار مباشر.
امنح كل استثناء مقترح وجهةً ونوع نقل ومالكًا. السماح بكل المنافذ إلى نقطة نهاية يسمح بأكثر بكثير من النقل الواحد الذي يستخدمه النفق، ويأتي التعرض الإضافي دون أن يقرر أحد أنه ينبغي أن يكون. والسماح بمُحلِّل عام هو الفخ نفسه في زي أرحب: فهو ينشئ مسار 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 بشكل منفصل، واختبر تحليل الأسماء، وأدرج تدفقًا كان قائمًا قبل الانتقال، لأن الاتصالات القائمة لا تتبع السياسة الجديدة دائمًا. المتصفح الذي يفشل والنفق متوقف نقطة بيانات واحدة، وليس دليلًا على أن كل مسار آخر محجوب.
أخيرًا، احتفظ بطريقة استرداد لا تعتمد على مسار الشبكة الذي تغيّره. فالتكوين السليم المعروف على تخزين محلي، وطريقة موثقة لتحميله، يحوّلان القفل إلى سياسة؛ وبدونهما، يحبس تعديل سيئ واحد المسؤول خارج الجهاز الذي كان يُفترض حمايته.