curl อ่านไฟล์ PAC ของคุณไม่ได้: ส่ง proxy แทน
PAC คือ JavaScript policy ส่วน curl ต้องการ endpoint ถามว่านโยบายเลือก proxy ใดสำหรับ URL ของคุณ ส่งค่านั้น และระวัง NO_PROXY กับ TLS
ที่อยู่ในไฟล์ PAC กับ endpoint ของ proxy ดูเหมือนใช้แทนกันได้ในไฟล์กำหนดค่า แต่ไม่ใช่ อย่างหนึ่งเป็นโปรแกรมกำหนดนโยบายที่ต้องประเมินสำหรับทุก URL อีกอย่างเป็นโฮสต์และพอร์ตที่รับการเชื่อมต่อ curl เข้าใจเฉพาะอย่างหลัง การส่งที่อยู่ PAC ไปยัง --proxy เป็นข้อผิดพลาดเชิงหมวดหมู่ที่ล้มเหลวอย่างสับสน โดยปกติหลังการหมดเวลา CONNECT ที่ยาวนานไปยังเว็บเซิร์ฟเวอร์
แต่ละอย่างคืออะไรจริง ๆ
| คุณมี | มันคืออะไร | curl ทำอะไรกับมัน |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript ที่คืนค่า proxy หรือการเชื่อมต่อโดยตรงสำหรับ URL ที่กำหนด | ดาวน์โหลดเป็นไฟล์แล้วหยุดอยู่แค่นั้น |
http://proxy.corp.example:8080 | ตัวรับฟังที่รับคำขอผ่าน proxy | ใช้มัน รวมถึง CONNECT สำหรับเป้าหมาย HTTPS |
สิ่งนี้บอกไว้อย่างชัดเจนใน คำถามที่พบบ่อยของ curl: curl ไม่มีการตีความ JavaScript หรือ PAC ใด ๆ ตัวห่อรอบ curl ที่เข้าใจ PAC ทำได้ แต่ curl เองไม่ และไม่มีแฟล็กใดเปลี่ยนให้เป็นเบราว์เซอร์
ทำไมเบราว์เซอร์ทำงานได้แต่ curl ไม่ได้
เบราว์เซอร์เชื่อมต่อกับการกำหนดค่า proxy ของระบบ ดาวน์โหลดไฟล์ PAC และรันกฎของมันกับ URL ที่คุณเปิด การประเมินนั้นคือบริการที่ไฟล์ PAC มอบให้ และเกิดขึ้นภายในเบราว์เซอร์ ไม่ใช่ในเทอร์มินัลของคุณ
การดาวน์โหลดไฟล์ PAC ด้วย curl ได้มาเพียงข้อความของมัน ไม่ได้ทำให้ curl รันนโยบาย และการอ่านด้วยมือเพื่อหา proxy คือเวอร์ชันทำมือของการประเมินเดียวกัน ด้วยโอกาสเดียวกันในการเลือกสาขาผิด หากคุณอ่านมัน ให้อ่านคำสั่ง return ที่ตรงกับโฮสต์ของคุณ แทนชื่อ proxy แรกในไฟล์ ไฟล์ PAC ส่วนใหญ่มีหลายตัว และมีเพียงสาขาเดียวที่ใช้กับคุณ
สำหรับ HTTP proxy ที่ได้รับอนุมัติและบริการ HTTPS ที่ได้รับอนุมัติ คำขอตัวอย่างคือ:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusที่อยู่แรกคือตัวรับฟังของ proxy ที่สองคือบริการที่คุณต้องการ สิ่งเหล่านี้เป็น endpoint ตัวอย่าง ไม่ใช่การทดสอบที่ใครทำ ดังนั้นแทนที่ด้วยสคีมา พอร์ต และขั้นตอนการพิสูจน์ตัวตนขององค์กรคุณ
เลือก proxy สำหรับปลายทางนี้
ถามผู้ดูแลระบบว่า proxy ใดที่นโยบายเลือกสำหรับ URL ที่คุณต้องการ ไม่ใช่ proxy ใดที่องค์กรเป็นเจ้าของ กฎ PAC อาจคืนผลต่างกันสำหรับบริการภายใน ไซต์สาธารณะ และสภาวะสลับเมื่อล้มเหลว และกฎที่ตรงกับ URL ของคุณวันนี้อาจตรงกับอีกอันหลังการแก้ไข
หากขั้นตอนการทำงานต้องการคำขอที่รู้จักมากกว่าหนึ่งรายการ ให้ใช้การตั้งค่าแบบคงที่ที่ผู้ดูแลระบบรองรับ หรือการผสานรวมที่เข้าใจ PAC ซึ่งได้รับอนุมัติ การฮาร์ดโค้ดที่อยู่เดียวที่คัดลอกมาจะใช้ได้จนถึงวันที่นโยบายเปลี่ยนและไม่มีใครจำได้ว่าทำไมจึงเลือกที่อยู่นั้น
จากนั้นดูว่า curl สืบทอดอะไร ตัวแปรสภาพแวดล้อม proxy และ NO_PROXY อาจแทนที่หรือยกเว้น proxy ที่คุณส่งไป และการยกเว้นที่ตรงกับเป้าหมายของคุณจะส่งคำขอโดยตรงอย่างเงียบ ๆ รักษานโยบายที่ตั้งใจไว้แทนที่จะลบทุกการยกเว้นหรือบังคับทุกอย่างผ่านที่อยู่เดียว รันคำขอหนึ่งครั้งด้วย -v แล้วตรวจสอบว่ามันเชื่อมต่อกับที่อยู่ใดจริง ๆ
แยกอัตลักษณ์ TLS ทั้งสองออกจากกัน
เมื่อใช้ proxy แบบ HTTPS มีการเชื่อมต่อ TLS สองรายการที่เกี่ยวข้อง: ของคุณไปยัง proxy และของ proxy ไปยังปลายทาง แต่ละรายการมีอัตลักษณ์ของตัวเองให้ตรวจสอบ และการปิดการตรวจสอบสำหรับรายการใดรายการหนึ่งไม่ใช่การแก้ไข PAC แต่เป็นปัญหาที่สองที่เพิ่มเข้าไปในปัญหาแรก
เปิดการตรวจสอบไว้และอ่านความล้มเหลวที่คุณได้รับ การท้าทายการพิสูจน์ตัวตนของ proxy, proxy ที่เข้าถึงไม่ได้ และการปฏิเสธจากเว็บไซต์เป็นผลลัพธ์ที่แตกต่างกันสามแบบ และมีเพียงแบบแรกที่เกี่ยวกับข้อมูลรับรอง VPN ยังต้องจัดหาเส้นทางที่ได้รับอนุญาตไปยัง proxy ส่วนตัว รวมถึงการแปลงชื่อสำหรับโฮสต์ proxy เอง ก่อนที่สิ่งใดจะสำเร็จ
จดบันทึก endpoint สคีมา พอร์ต วิธีการพิสูจน์ตัวตน การยกเว้น และเส้นทาง VPN ไปยัง proxy บันทึกนั้นคือสิ่งที่ทำให้คำขอครั้งต่อไปทำซ้ำได้ และเป็นความแตกต่างระหว่างการรู้จัก proxy ของคุณกับการเดาเกี่ยวกับมัน