لا يستطيع curl قراءة ملف PAC: مرّر الوكيل بدلًا منه
ملف PAC سياسة JavaScript؛ أما curl فيريد نقطة نهاية. اسأل أي وكيل تختاره السياسة لعنوانك، ومرّره، وراقب NO_PROXY وTLS.
عنوان ملف PAC ونقطة نهاية الوكيل يبدوان قابلين للتبادل في ملف التهيئة، وهما ليسا كذلك. أحدهما برنامج سياسة يجب تقييمه لكل عنوان URL، والآخر مضيف ومنفذ يقبل الاتصالات. لا يفهم curl إلا الثاني. تمرير عنوان PAC إلى --proxy خطأ في التصنيف يفشل بطريقة مربكة، عادةً بعد مهلة CONNECT طويلة إلى خادم ويب.
ما هو كل واحد منهما في الواقع
| ما لديك | ما هو | ما يفعله curl به |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript يعيد وكيلًا أو اتصالًا مباشرًا لعنوان URL معيّن | يجلبه كملف ويتوقف عند ذلك |
http://proxy.corp.example:8080 | مستمع يقبل الطلبات المارّة عبر وكيل | يستخدمه، بما في ذلك CONNECT لأهداف HTTPS |
تذكر الأسئلة الشائعة حول curl ذلك بوضوح: لا يوفّر curl أي تفسير لـ JavaScript أو PAC. قد يوفّر غلاف واعٍ بـ PAC حول curl ذلك، لكن curl نفسه لا يفعله، ولا يوجد علم يحوّله إلى متصفح.
لماذا يعمل المتصفح ولا يعمل curl
يتكامل المتصفح مع إعدادات الوكيل في النظام، ويجلب ملف PAC ويشغّل قواعده على عنوان URL الذي تفتحه. هذا التقييم هو الخدمة التي يقدّمها ملف PAC، ويحدث داخل المتصفح لا داخل الطرفية.
تنزيل ملف PAC باستخدام curl يجلب نصه فقط. وهو لا يجعل curl ينفّذ السياسة، وقراءته يدويًا للعثور على وكيل هي نسخة يدوية من التقييم نفسه، مع الاحتمال نفسه لاختيار الفرع الخطأ. إن قرأته، فاقرأ عبارة return التي تطابق مضيفك بدلًا من أول اسم وكيل في الملف. تحتوي معظم ملفات PAC على عدة وكلاء، وفرع واحد فقط ينطبق عليك.
لوكيل HTTP معتمد وخدمة HTTPS معتمدة، هذا طلب توضيحي:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusالعنوان الأول هو مستمع الوكيل، والثاني هو الخدمة التي تريدها. هذه نقاط نهاية أمثلة لا اختبار أجراه أحد، لذا استبدلها بمخطط مؤسستك ومنفذها وسير عمل المصادقة لديها.
اختر الوكيل المناسب لهذه الوجهة
اسأل المسؤول أي وكيل تختاره السياسة للعنوان الذي تحتاجه، لا أي وكيل تملكه المؤسسة. قد تعيد قواعد PAC نتائج مختلفة للخدمات الداخلية والمواقع العامة وحالات تجاوز الفشل، وقد تطابق قاعدة تناسب عنوانك اليوم عنوانًا آخر بعد تعديل.
إذا كان سير العمل يحتاج أكثر من طلب معروف واحد، فاستخدم إعدادًا ثابتًا تدعمه الإدارة أو تكاملًا معتمدًا واعيًا بـ PAC. تشفير عنوان منسوخ واحد يعمل إلى اليوم الذي تتغير فيه السياسة ولا يتذكر أحد لماذا اختير ذلك العنوان.
ثم انظر إلى ما يرثه curl. متغيرات بيئة الوكيل وNO_PROXY يمكن أن تتجاوز الوكيل الذي مرّرته أو تستبعده، واستبعاد يطابق هدفك يرسل الطلب مباشرة بصمت. حافظ على السياسة المقصودة بدلًا من حذف كل استبعاد أو إجبار كل شيء على المرور عبر عنوان واحد. نفّذ الطلب مرة واحدة مع -v وتحقق من العنوان الذي اتصل به فعليًا.
أبقِ هويتَي TLS منفصلتين
مع وكيل HTTPS، هناك اتصالا TLS قيد الاستخدام: اتصالك بالوكيل واتصال الوكيل بالوجهة. لكل منهما هويته الخاصة التي يجب التحقق منها، وتعطيل التحقق لأي منهما ليس إصلاحًا لـ PAC بل مشكلة ثانية تُضاف إلى الأولى.
أبقِ التحقق مفعّلًا واقرأ الفشل الذي تحصل عليه. تحدّي مصادقة الوكيل، ووكيل لا يمكن الوصول إليه، ورفض من الموقع، ثلاثة نتائج مختلفة، وأولها فقط يتعلق بالبيانات الاعتمادية. ما زال على VPN أن يوفّر مسارًا مسموحًا إلى وكيل خاص، بما في ذلك تحليل اسم مضيف الوكيل نفسه، قبل أن ينجح أي من هذا.
دوّن نقطة النهاية والمخطط والمنفذ وطريقة المصادقة والاستثناءات ومسار VPN إلى الوكيل. هذا السجل هو ما يجعل الطلب التالي قابلًا للتكرار، وهو الفرق بين معرفة وكيلك والتخمين فيه.