كيف تُشغّل قواعد النطاق في Apple VPN On Demand النفق
قاعدة النطاق لا تقرر إلا متى يُفتح النفق. كيف يعمل فحص DNS عند الحاجة إلى الاتصال، ولماذا ما زالت المسارات تختار الحركة، وكيف تختبر ملف التعريف.
يُفتح النفق عند طلب اسم داخلي واحد ويظل مغلقًا عندما يحتاجه التطبيق التالي بالقدر نفسه. هذا ليس خللًا في التطبيق؛ بل هو شكل قاعدة النطاق. تصف إعدادات on-demand من Apple شروط إنشاء الاتصال، والصيغة النطاقية لهذه الشروط تسأل مُحلِّل النظام سؤالًا قبل أن تتحرك حزمة واحدة. هناك سؤالان يختلطان دائمًا: متى ينبغي أن يرتفع النفق، وما الذي يحمله النفق بعد وجوده. الأول مُشغِّل، والثاني سياسة مسار ومُحلِّل، وغالبًا يضبط ملف تعريف واحد الاثنين في الحمولة نفسها، ولهذا قد تتركك قاعدة نطاق صحيحة على الشبكة الخطأ.
المُشغِّل واختيار الحركة في طبقتين مختلفتين
تعيش قاعدة on-demand في قاموس on-demand داخل حمولة VPN: قائمة مرتبة من القواعد، لكل منها إجراء ومجموعة شروط مطابقة. يقيّمها النظام عند تغيّر الاتصال أو عندما يحاول شيء الوصول إلى الشبكة، ويقرر الإجراء ما إذا كان النفق يُرفع أو يُقيَّم أو يُقطع أو يُتجاهل. يحدث كل ذلك في طبقة الشبكات في المنصة، قبل أن يحصل تطبيقك على مقبس.
ما يحدث بعد ذلك مجموعة منفصلة من المفاتيح: إعدادات IPv4 وIPv6 للنفق، ومساراته المضمّنة والمستبعدة، وعناوين خوادم DNS، وعلى iOS وiPadOS ربط التطبيقات الذي يقرر أي التطبيقات يجوز لها استخدام النفق أصلًا. يمكن لملف التعريف أن يقرن مُشغِّلًا واسعًا بمسار ضيق، أو مُشغِّلًا ضيقًا بمسار افتراضي. اقرأ نصفًا واحدًا فقط وسيبدو النصف الآخر كعطل.
أحتفظ بملف تعريف مختبري يتصل كلما طُلب أي شيء تحت نطاق داخلي، لكنه يوجّه شبكة /16 واحدة فقط إلى النفق. إنه يفعل بالضبط ما تقوله حمولته، وهو أيضًا نوع ملفات التعريف التي تولّد تذاكر الدعم: يفترض الناس أن النفق المتصل يعني أن حركتهم داخله.
ما تسأله قاعدة النطاق فعليًا للمُحلِّل
الصيغة النطاقية للقاعدة، التي تُسمّى غالبًا connect-if-needed، لا تفحص حمولات الحزم ولا تراقب عناوين URL. عند تحليل اسم، يقارنه النظام بالنطاقات في القاعدة، وعند المطابقة يسأل عمّا إذا كان ذلك الاسم قابلًا للتحليل عبر خوادم DNS التي يوفرها النفق. إذا أجاب مُحلِّل النفق، يُعدّ الاسم داخليًا ويبدأ الاتصال. وإذا أجاب المُحلِّل المحلي بدلًا من ذلك، يُعامل الاسم كخارجي ولا يظهر أي نفق. يصف نظرة Apple العامة على النشر ذلك بأنه كشف الشبكة ثم تقييم الاتصال.
تتبع نتيجتان. يجب أن يسمّي ملف التعريف خوادم DNS داخل النفق؛ فقاعدة نطاق بلا مُحلِّل نفق ليس لديها ما تقارنه، لذا لا يمكن للتقييم أن ينتج المطابقة التي تتوقعها. ويجب أن يصل البحث إلى مُحلِّل النظام. التطبيق أو المتصفح الذي يشغّل DNS مشفّرًا خاصًا به، أو الإضافة التي تجيب محليًا، أو الاتصال بعنوان حرفي، لا ينتج أبدًا تحليل الاسم الذي كانت القاعدة تنتظره. انتهى أحد أطول أيامي بعد الظهر عندما اكتشفت أن العميل أمام النفق كان يستخدم DNS over HTTPS.
يزيل التخزين المؤقت المُشغِّل أيضًا. قد يُجاب عن اسم موجود أصلًا في ذاكرة التخزين المؤقت دون الفحص الذي كان سيبدأ النفق، لذا تفشل قاعدة عملت أمس بعد إعادة تشغيل، أو بعد بقاء النفق مفتوحًا فترة. على macOS يعيد sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ضبط الحالة؛ وعلى iOS يمنحك تبديل وضع الطيران أو إعادة تشغيل الجهاز بداية نظيفة مماثلة.
نطاق المطابقة: الأسماء والتطبيقات والشبكات
مطابقة النطاق نوع واحد بين عدة أنواع. يمكن للقاعدة أيضًا أن تطابق نوع الواجهة (Wi-Fi أو الخلوية أو Ethernet) وSSID محددًا، وتربط إدخالات التطبيق أو نطاق Safari نفقًا بسير عمل واحد. يفسّر هذا الربط التجربة الغريبة التي يتصرف فيها تطبيق واحد فقط بشكل مختلف عن كل شيء آخر: التطبيقات الأخرى خارج نطاق النفق، لذا تظل تستخدم المسار المحلي حتى بينما تقول أيقونة النفق إنه متصل.
الترتيب أهم مما يتوقع الناس. تُقيَّم القواعد بالتتابع وأول قاعدة تطابق هي التي تقدّم الإجراء، لذا قاعدة واسعة مثل الاتصال على أي Wi-Fi موضوعة فوق قاعدة نطاق ضيقة ستفوز بصمت وتجعل قاعدة النطاق غير قابلة للاختبار. قبل إعادة كتابة قائمة النطاقات، تأكد من أن أية قاعدة سابقة لم تكن قد طابقت بالفعل.
لهذا أيضًا ليس always-on مجرد قاعدة on-demand أكثر صرامة. فرض always-on وضع نشر منفصل له متطلبات إشراف وإدارة خاصة به؛ فهو يبقي النفق مفتوحًا بدلًا من التفاعل مع اسم. إذا كنت تحتاج نفقًا لا ينقطع أبدًا، فقاعدة النطاق هي الأداة الخطأ.
أنماط فشل تحاكي قاعدة معطوبة
تقع معظم التقارير عن عدم عمل قاعدة نطاق في واحد من خمسة مواضع، وآخرها فقط هو نص القاعدة.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
تستحق بوابات الالتقاط سطرًا خاصًا، لأن شبكات Wi-Fi في الفنادق والمطارات تعترض البحث نفسه الذي تعتمد عليه القاعدة. وإلى أن تقبل البوابة الجهاز، يكون خادم DNS الخاص بالنفق غير قابل للوصول، ويفشل الفحص، ويبدو الفشل كنطاق مكتوب خطأً. المصادقة هي الحالة الصامتة الأخرى: قد تنطلق القاعدة، وقد يبدأ النفق بالاتصال، ويموت الاتصال بسبب شهادة منتهية أو مطالبة تظهر على شاشة أخرى.
يسبب IPv6 نسخة يسهل تشخيصها خطأً. قد يُجاب عن اسم يحمل عائلتي عناوين من سجل AAAA أولًا، بينما تحمل قائمة مسارات النفق IPv4 فقط. ينجح متصفح ويفشل آخر، وقائمة النطاقات بريئة تمامًا.
اختبر بطلب حقيقي، بهذا الترتيب
اقرأ السياسة قبل التخمين. على macOS يطبع sudo profiles show -type configuration ملفات التعريف المثبتة بما فيها حمولة VPN، ويعرض scutil --nc list حالة الخدمة، ويطبع scutil --nc show <service> قاموس on-demand الذي يستخدمه النظام. على iPhone أو iPad خاضع للإدارة تصل الحمولة نفسها من وحدة تحكم الإدارة أو تقرير MDM. تتوفر سجلات الشبكات مع log stream --predicate 'subsystem == "com.apple.networkextension"' على macOS، وعبر وحدة تحكم الجهاز عند توصيل الهاتف.
ثم اختبر باسم مضيف لم يُستعلم عنه سابقًا في الجلسة. اختر اسمًا في نطاق DNS الخاص بالنفق تعرف أنه يُحلَّل داخليًا، واطلبه مرة واحدة، وراقب ما إذا كان النفق يظهر. شغّل البحث نفسه مرتين: التمريرة الثانية تمارس مسار ذاكرة التخزين المؤقت، والفرق بينهما يخبرك ما إذا كان المُشغِّل هو التحليل أم التوجيه.
بعد أن يرتفع النفق، تحقق من الطبقتين بشكل منفصل. يعرض netstat -rn -f inet وnetstat -rn -f inet6 أين تشير كل بادئة، ويعرض scutil --dns ترتيب المُحلِّلات وأي واجهة تملك كل مُحلِّل، ويعرض nettop -m route الواجهة التي حملت البايتات. إذا كان النفق مرفوعًا والمُحلِّل صحيحًا لكن المورد لا يزال يفشل، فتوقف عن تحرير القاعدة؛ افحص التخويل من جهة الخادم ومسار العودة.
عندما تكون القاعدة ملكًا لشخص آخر
إذا ظهر النفق من جديد بعد قطعه، فالقاعدة عادة تنتمي إلى ملف تعريف لا إلى تطبيق: إعداد مدفوع عبر MDM، أو ملف تعريف شخصي متبقٍ، أو ملف تعريف ثبّته عميل آخر. يضيّق sudo profiles show -type configuration مع بحث عن مفاتيح on-demand الأمر، ومسار الإزالة هو ملف التعريف، لا المفتاح في شريط القوائم. حذف إدخال الخدمة أو التطبيق يترك القاعدة خلفه، والتثبيت التالي يرثها مرة أخرى.
يحسم اختبار واحد الملكية: اقطع الاتصال، انتظر، اطلب الاسم الداخلي مرة أخرى. إذا عاد النفق، فالمُشغِّل يعمل كما صُمم والسؤال المفتوح هو من يديره وما إذا كان ذلك النطاق هو ما تريده.
قبل تسجيل هذا كخلل، اعمل عبر الفحوص الخمسة نفسها: عناوين مُحلِّل النفق موجودة في الحمولة، واسم لم يُخزَّن مؤقتًا، ولا قاعدة سابقة طابقت بالفعل، ومسار AAAA تغطيه قائمة المسارات، والتطبيق داخل نطاق النفق. عندما تصح الخمسة جميعًا، فالقاعدة تؤدي عملها والخطأ في مكان أبعد على المسار.