وكيل لكل ملف متصفح: DNS والمصادقة وحالات الفشل

يستخدم هذا الدليل سلوك شبكة Chromium الموثق مرجعاً. وقد تتخذ المتصفحات والمنتجات الأخرى خيارات مختلفة، كما قد يضيف مدير المتصفح وسيط شبكة محلياً حول Chromium. تحقق من سلوك البنية الدقيقة التي تشغّلها.

ابدأ بأربعة أسئلة مستقلة

يتضمن سجل الوكيل عادةً مخططاً ونقطة نهاية ومنفذاً وأحياناً مرجع مصادقة. ويترك ذلك السجل أربعة أسئلة سياسة منفصلة:

1. التغطية: ما طلبات المتصفح والبروتوكولات المعينة لهذا الوكيل؟
2. حل الأسماء: هل يحل الجهاز أو الوكيل اسم مضيف الوجهة؟
3. المصادقة: أي مخططات عميل ووكيل تعمل معاً، وأين تُخزن بيانات الاعتماد؟
4. الفشل: هل يوقف خطأ الاتصال الطلب أو يجرب وكيلاً آخر أو يعود إلى مسار مباشر؟

يؤدي التعامل معها كمفتاح «تشغيل الوكيل» واحد إلى معظم المفاجآت. توثق Chromium اختيار الوكيل على أنه حل على مستوى URL: إذ ينتج URL قائمة مرتبة من خيارات الوكيل قبل حل الوجهة بالضرورة. وقواعد التجاوز والعودة جزء من ذلك القرار.

ما الذي يغطيه وكيل لكل ملف

تُطبق سياسة ProxySettings في Google على مستوى ملف Chrome. ويمكنها اختيار الوضع المباشر أو النظامي أو المكتشف تلقائياً أو خادم ثابت أو نص PAC، مع حقول صريحة للتجاوز وفرض PAC.

ذلك الحد أضيق من VPN أو مساحة شبكة نظام التشغيل. فهو يحكم الطلبات التي يعالجها سياق شبكة المتصفح. ولا يحكم تلقائياً:

• نداءات API الخاصة بمدير سطح المكتب؛
• تطبيقاً خارج العملية أو محدّث المتصفح؛
• DNS الخاص بنظام التشغيل وفحوص الاتصال؛
• تطبيقاً آخر شُغّل من ملف منزّل؛
• مساعداً أصلياً منفصلاً لإضافة؛
• خدمات محلية تصل إليها تجاوزات loopback الضمنية؛ أو
• حركة مرور تستخدم بروتوكولاً لا يستطيع مسار الوكيل المحدد حمله.

قد تملك بعض هذه المكونات دعم وكيل خاصاً بها. ويجب تحديد ذلك الدعم واختباره منفصلاً. وينبغي لعبارة منتج المتصفح مثل «تستخدم حركة مرور الملف هذا الوكيل» أن تحدد العمليات والبروتوكولات المشمولة بدلاً من الإيحاء بتوجيه على مستوى الجهاز.

اتبع طلب HTTPS واحداً

للتنقل العادي عبر HTTPS عدة خطوات.

1. اختر المسار

يقيّم المتصفح القواعد الثابتة أو نص الإعداد التلقائي للوكيل أو إعدادات النظام. وقد يختار تطابق التجاوز اتصالاً مباشراً. وقد تختار قائمة الوكلاء وكيلاً أساسياً تتبعه بدائل، بما في ذلك DIRECT إذا سمحت العودة المباشرة.

وتطبق Chromium أيضاً تجاوزات ضمنية للوجهات localhost وlink-local. يحمي ذلك المصادر المحلية من إعدادات وكيل يتحكم فيها الخارج، لكنه يعني أن وصف «كل حركة المرور» يحتاج إلى تأهيل.

2. حل الوكيل والوصول إليه

إذا كانت نقطة نهاية الوكيل اسماً لمضيف، فلا يزال الجهاز يحتاج إلى طريقة لحل ذلك المضيف والاتصال به. ولا يلغي DNS الخاص بالوجهة البعيدة عملية البحث الأولية هذه. ويختلف الفشل هنا عن وصول الوكيل مع عجزه عن حل الوجهة.

3. صادق الوكيل

يعيد وكيل HTTP الذي يتطلب بيانات اعتماد عادةً 407 Proxy Authentication Required مع تحدٍّ. يعرّف RFC 9110 هذا التبادل وحقلي Proxy-Authenticate وProxy-Authorization.

لا تستخدم Chromium اسم مستخدم وكلمة مرور مضمنين في إعدادات الوكيل اليدوية. وتقول وثائق الوكيل إن المصادقة تتبع بدلاً من ذلك تدفق بيانات الاعتماد العادي في المتصفح. لذلك يحتاج مدير الملفات إلى تكامل صريح للتحدي المدعوم، لا وعد بأن أي سلسلة user:password@host ستعمل.

4. أنشئ اتصال الوجهة

مع وكيل HTTP، تؤجل Chromium حل اسم الوجهة إلى الوكيل. وبالنسبة إلى وجهة HTTPS، يطلب المتصفح من الوكيل إنشاء نفق CONNECT ثم ينفذ TLS من الطرف إلى الطرف مع الوجهة عبر النفق.

لا يزال الوكيل يعرف اسم مضيف الوجهة وبيانات الاتصال. وعندما تستخدم وصلة العميل بالوكيل HTTP عادياً، لا يكون طلب CONNECT واسم المضيف محميين على تلك الوصلة. ويضيف وكيل HTTPS TLS بين المتصفح والوكيل، فيحمي تلك البيانات الوصفية من المراقبين بينهما. لكنه لا يجعل الوكيل نفسه عاجزاً عن رؤية الوجهة المطلوبة.

لا يستطيع الوكيل عادةً قراءة محتوى صفحة HTTPS داخل النفق. واعتراض TLS نموذج ثقة مختلف يثق فيه العميل بسلطة شهادات تسمح للوسيط بإنهاء TLS وإعادة إنشائه. ولا ينبغي الخلط بين ذلك وبين التمرير العادي.

تتغير ملكية DNS مع مخطط الوكيل

يختلف سلوك Chromium الموثق حسب نوع الوكيل:

المسار المحدد	حل اسم الوجهة في Chromium	الحد المهم
مباشر أو متجاوز	محلل الجهاز أو المتصفح	تغادر حركة الوجهة دون وكيل الملف
وكيل HTTP	جانب الوكيل	يكشف نقل HTTP العادي بين العميل والوكيل طلبات HTTP؛ ويستخدم HTTPS CONNECT
وكيل HTTPS	جانب الوكيل	يجب على العميل التحقق من شهادة TLS للوكيل
وكيل SOCKS4	جانب العميل	وجهة IPv4 فقط؛ لا تنفذ Chromium عودة SOCKS4a
وكيل SOCKS5	جانب الوكيل	تستخدمه Chromium لطلبات URL عبر TCP وتوثق عدم دعم مصادقة SOCKS5

يسمح RFC 1928 لطلب SOCKS5 بحمل اسم نطاق ويعرّف عدة معرّفات لطرق المصادقة. لكن قدرة البروتوكول لا تضمن تنفيذ العميل. ترسل Chromium حالياً أسماء الوجهات إلى وكيل SOCKS5، لكنها تقول إن عميل SOCKS5 المدمج يدعم أي طريقة مصادقة للوكيل. لذلك قد يحتاج مورد يوفر SOCKS5 باسم مستخدم وكلمة مرور إلى وسيط مدعوم أو مخطط وكيل آخر. أكد تنفيذ المتصفح قبل قبول السجل.

يضيف DNS-over-HTTPS طبقة أخرى. وتميز سياسة DnsOverHttpsMode في Chrome بين automatic الذي قد يعود إلى DNS غير الآمن وsecure الذي يفشل الحل عند فشل DNS الآمن. وتوثق السياسة نفسها على مستوى المتصفح، بينما تكون ProxySettings على مستوى الملف. ذلك التفاوت تحذير مفيد: كلمة «ملف» في إعداد واحد لا تعني أن كل ضابط DNS له النطاق نفسه.

قد ينشئ المنتج الذي يشغّل كل ملف في عملية متصفح منفصلة حدّاً فعلياً أضيق، لكن ذلك خيار تنفيذ. اختبره. وينبغي للأدلة التمييز بين:

• حل نقطة نهاية الوكيل؛
• حل الوجهة المطلوبة؛
• DNS المستخدم للطلبات المباشرة أو المتجاوزة؛
• بدء DNS الآمن والعودة منه؛ و
• DNS الذي تنفذه مكونات خارج سياق شبكة المتصفح للملف.

المصادقة مشكلة توافق وتعامل مع الأسرار معاً

توثق Chromium Basic وDigest وNegotiate وNTLM لوكلاء HTTP. وتضيف وكلاء HTTPS قناة محمية بين العميل والوكيل وقد تدعم أيضاً شهادات العميل. أما مصادقة SOCKS4 وSOCKS5 فلا ينفذها عميل وكيل Chromium المدمج، رغم وجود طرق مصادقة في مواصفة SOCKS5.

حتى المخطط المتوافق قد يكون غير آمن مع النقل الخطأ. يوضح RFC 7617 أن بيانات اعتماد Basic مشفرة بـ Base64 فقط وتحتاج إلى قناة محمية مثل TLS. ويؤدي استخدام مصادقة Basic مع وكيل HTTP عادي إلى كشف كلمة مرور الوكيل لمن يستطيع مراقبة تلك الوصلة.

ينبغي لمدير الملفات إبقاء البيانات التالية منفصلة:

• بيانات نقطة النهاية غير السرية مثل المخطط والمضيف والمنفذ ووسم المورد؛
• مرجع سر تستخدمه خدمة دورة الحياة أو الشبكة؛
• قيمة بيانات الاعتماد في تخزين محمي؛
• حالة اتصال منقحة للواجهة ومسار التدقيق؛ و
• تفاصيل تشخيص لا تتاح إلا عبر مسار دعم مضبوط.

لا تحتاج الشاشات والسجلات وواجهات API والتصديرات ومخرجات الأتمتة العادية إلى كلمة مرور الوكيل. يحتاج المشغّل عادةً إلى معرفة فشل المصادقة والمخطط الذي تحدى به الوكيل ونقطة النهاية المعنية وهل حدثت عودة.

حالات الفشل وكيف تظهر

الفشل	العرض المحتمل	الحد الذي ينبغي التحقق منه
مخطط الوكيل خطأ	فشل مصافحة TLS أو البروتوكول	هل أُعلنت نقطة نهاية HTTPS كـ HTTP أو العكس؟
تعذر حل اسم مضيف الوكيل	يفشل الاتصال قبل الوصول إلى الوكيل	أي محلل أجرى البحث الأولي؟
منفذ الوكيل غير قابل للوصول	مهلة أو رفض اتصال	هل الوكيل الآخر أو DIRECT هو التالي في القائمة؟
تحدي المصادقة غير مدعوم	407 متكرر أو مطالبة دخول	هل ينفذ المتصفح المخطط المتحدى؟
بيانات الاعتماد خاطئة أو منتهية	407 بعد إرسال بيانات الاعتماد	هل حُل مرجع السر، وهل نُقح من المخرج؟
فشل شهادة وكيل HTTPS	رُفض الاتصال الآمن بالوكيل	هل التحقق من الشهادة سليم؟
لا يستطيع الوكيل حل الوجهة	فشل مضيف أو نفق خاص بالوكيل	هل تجنب العميل إعادة تجربة الوجهة مباشرة؟
رُفض CONNECT	فشل تنقل HTTPS للوجهة	هل عومل الرفض كسياسة لا كإذن للتحايل؟
ملف PAC غير متاح	يتوقف حل الوكيل أو يغير المسار	هل PAC إلزامي أم تستطيع Chromium استخدام DIRECT بصمت؟
نمط التجاوز واسع جداً	تتصل المواقع المحددة مباشرة	هل فُهم المضيف الفرعي والمنفذ والقواعد الضمنية الدقيقة؟
يستخدم WebRTC واجهة أخرى	يختلف مسار الوسائط عن حركة الصفحة	هل عُطل UDP غير المار عبر الوكيل للملف؟
تستمر وصلة قائمة بعد تغيير	يبقى المسار القديم نشطاً مؤقتاً	هل تُستنزف الوصلات أو يُعاد تشغيل الملف؟
التقاط التشخيص مفصل أكثر من اللازم	تدخل عناوين URL أو أسماء المضيفين أو الأسرار ملف دعم	أي وضع تنقيح وقاعدة احتفاظ ينطبقان؟

عودة Chromium ذات حالة. فقد يُعلَّم وكيل بفشل على مستوى الاتصال بأنه سيئ وينقل خلف إدخالات أخرى مدة من الزمن. وإذا كان DIRECT في القائمة، فقد تغادر الطلبات اللاحقة دون الوكيل. ويُعالج رفض CONNECT بصورة مختلفة لأنه قد يمثل سياسة وجهة مقصودة لا وكيلًا غير متاح.

يحتاج فشل PAC إلى عناية خاصة. توثق Chromium أن ملف PAC غير المتاح قد يعود بصمت إلى الحل المباشر ما لم يُعلَّم PAC بأنه إلزامي. وتعرض سياسة ProxySettings في Chrome الحقل ProxyPacMandatory تحديداً لمنع تلك العودة المباشرة.

يحتاج WebRTC وUDP إلى قرار مستقل

قد يستخدم الموقع مسارات WebRTC لا تعادل طلبات URL العادية عبر HTTP وHTTPS. ويمكن لإعداد سياسة WebRtcIPHandling الافتراضي في Chrome استخدام كل الواجهات المتاحة. ويقصر وضعها disable_non_proxied_udp WebRTC على TCP في الواجهة العامة ما لم يدعم الوكيل المضبوط UDP.

توثق السياسة على مستوى الملف، ما يجعلها ذات صلة بوكيل الملف، لكنها تظل ضابطاً منفصلاً. وقد تقلل أداء الوسائط أو تكسر سير عمل يحتاج إلى UDP مباشر. اختر المقايضة واختبرها صراحةً. ولا تدّع احتواءً كاملاً للوكيل اعتماداً على فحص نجاح تحميل الصفحة فقط.

قرر سلوك النظام عند الفشل

قد تكون العودة المباشرة مشروعة لملف تصفح عام يعطي الأولوية للإتاحة. لكنها غير آمنة لسير عمل يعتمد تفويضه أو خصوصيته أو صحة اختباره الإقليمي على مسار خروج محدد.

تسمي سياسة الملف الجيدة السلوك المقصود:

• وكيل مطلوب: أوقف طلبات الشبكة المتأثرة عندما يتعذر استخدام المسار المحدد.
• مجموعة وكلاء معتمدة: جرّب بدائل مسماة ذات سياسة مكافئة فقط.
• العودة المباشرة مسموحة: أظهر أن المسار تغير وسجّل الحدث دون قيم سرية.
• تجاوز صريح: وثّق فئة الوجهة وسبب الحاجة إلى الوصول المباشر.

ينبغي للواجهة إظهار حالة المسار قبل التشغيل وبعد الفشل. ويحول التغيير الصامت من وكيل إلى مباشر خطأ شبكة إلى خطأ سلامة: قد يبدو سير العمل ناجحاً بينما يستخدم المسار الخطأ.

مصفوفة تحقق آمنة

اختبر باستخدام نقاط نهاية ومناطق DNS تملكها أو مخولاً بفحصها. سجّل النتائج المتوقعة قبل تشغيل الاختبار.

1. تحقق من مخطط الوكيل المعلن مقابل نقل نقطة النهاية الفعلي.
2. أكد نجاح سلوك HTTP وHTTPS وWebSocket وWebRTC المطلوب.
3. راقب عنوان الخروج في وجهة مضبوطة.
4. راقب أي محلل يتلقى بحث الوجهة وأي محلل يبدأ بحث اسم مضيف الوكيل.
5. أنهِ صلاحية بيانات اعتماد اختبار وأكد عدم ظهور أي قيمة خام في الواجهة أو السجلات أو مخرجات الأتمتة.
6. اجعل وكيل الاختبار غير قابل للوصول وأكد أن الوصول يُمنع أو أن النظام يعود بطريقة مضبوطة.
7. ارفض وجهة CONNECT مضبوطة واحدة وأكد ألا يتحول رفض السياسة إلى وصول مباشر.
8. اجعل PAC اختبار غير متاح وأكد السلوك الإلزامي.
9. نفذ حالات التجاوز الدقيقة والنطاقات الفرعية والمحلية وlink-local وIPv4 وIPv6 التي يحتاج إليها سير العمل.
10. غير الوكيل أثناء نشاط الاتصالات وتحقق من وقت سريان المسار الجديد.
11. التقط تفاصيل التشخيص اللازمة للاختبار فقط، ثم تحقق من الاحتفاظ والحذف.

تتعامل إرشادات NetLog في Chromium مع تسجيل الشبكة بوصفه مسألة خصوصية وأمان. وقد تحذف الأوضاع المنقحة حقولاً حساسة، بينما قد تتضمن الأوضاع المفصلة ملفات تعريف الارتباط أو رؤوس المصادقة. وينبغي التعامل مع ملف الدعم وفق وضع التقاطه الفعلي، لا وفق اسمه.