ทำไมพร็อกซี่ PAC ใน VM ของเกสต์จึงล้มเหลวกับ URL ของโฮสต์

«โฮสต์ใช้ไฟล์ PAC นี้ ฉันจึงใส่ URL เดียวกันลงใน VM» เป็นประโยคที่สมเหตุสมผลและเป็นแผนที่ไม่สมบูรณ์ URL ของ PAC ชี้ไปที่สคริปต์นโยบาย ไม่ใช่พร็อกซี่ จนกว่าเกสต์จะดึงสคริปต์นั้นได้ ประเมินด้วยที่อยู่ของเกสต์เอง แล้วเข้าถึงพร็อกซี่ใดก็ตามที่สคริปต์ระบุ URL ก็เป็นเพียงสตริงในช่องการตั้งค่า ความสับสนส่วนใหญ่เกี่ยวกับนโยบายพร็อกซี่ในเครื่องเสมือนมาจากการมองบรรทัดเดียวว่าเป็นการกำหนดค่าทั้งหมด

URL ของ PAC คือสคริปต์ ไม่ใช่พร็อกซี่

ไฟล์มีฟังก์ชันที่รับ URL และโฮสต์ แล้วคืนค่าคำอธิบายพร็อกซี่หรือคำว่า DIRECT ไม่มีอะไรใน URL ที่บอกแอปพลิเคชันว่าจะส่งทราฟฟิกไปที่ไหน การตัดสินใจนั้นเกิดขึ้นตอนรันไทม์ ภายในสคริปต์ ด้วยข้อมูลที่สคริปต์ขอจากแพลตฟอร์ม กล่องโต้ตอบการตั้งค่าที่รับ URL ของ PAC กำลังรับตัวชี้ไปยังขั้นตอนการตัดสินใจ

ความแตกต่างนี้เองที่อธิบายว่าทำไมการคัดลอก URL จึงดูเหมือนได้ผล ช่องถูกกรอก การตั้งค่าถูกบันทึก และความล้มเหลวจะปรากฏเฉพาะภายหลัง เมื่อดึงสคริปต์ไม่ได้หรือเมื่อมันคืนพร็อกซี่ที่เกสต์เข้าถึงไม่ได้

สี่ขั้นตอนล้มเหลวต่างกันไป

ภายในเกสต์มีสี่สิ่งต้องเกิดขึ้นตามลำดับ และแต่ละอย่างมีลายเซ็นข้อผิดพลาดของตัวเอง เกสต์ดึงไฟล์ PAC แอปพลิเคชันประเมินสคริปต์สำหรับ URL ที่ร้องขอด้วยข้อมูลภายในเครื่อง พร็อกซี่ที่เลือกถูกแปลงชื่อและเข้าถึงได้ การพิสูจน์ตัวตนเกิดขึ้นหากพร็อกซี่ต้องการ

เริ่มด้วยการพิสูจน์การดึง เพราะทุกอย่างหลังจากนั้นไม่มีความหมายหากไม่มี ไฟล์ PAC บนเซิร์ฟเวอร์ส่วนตัวต้องมีเส้นทางที่ได้รับอนุญาตไปยังเซิร์ฟเวอร์นั้นก่อนที่กฎใดจะช่วยได้ และการเลือกพร็อกซี่ภายในสคริปต์ที่เข้าถึงไม่ได้ก็สร้างเส้นทางที่จะดึงมันมาไม่ได้:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

หากคำขอนั้นล้มเหลวจากเกสต์และทำงานได้จากโฮสต์ ปัญหาคือเส้นทางของเกสต์ไปยังเซิร์ฟเวอร์ PAC ไม่ใช่เนื้อหาของสคริปต์ หากมันคืนไฟล์ JavaScript ให้ไปยังขั้นตอนที่สองและค้นหาว่าสคริปต์ตัดสินใจอะไรสำหรับบริบทของเกสต์

สคริปต์เดียวกันตัดสินใจต่างออกไปภายใน VM

ฟังก์ชัน PAC สามารถตรวจสอบโฮสต์ที่ร้องขอและข้อมูลเกี่ยวกับเครื่องที่ทำการประเมินได้ กฎที่สร้างบนที่อยู่ของไคลเอนต์เอง เช่น กฎที่ตรวจสอบที่อยู่ของอินเทอร์เฟซหรือการเป็นสมาชิกของซับเน็ต จะเห็นที่อยู่ของเกสต์ ไม่ใช่ของโฮสต์ทางกายภาพ หลัง NAT ฝั่งโฮสต์สิ่งเหล่านี้เป็นที่อยู่ที่ต่างกัน ดังนั้นสคริปต์เดียวกันจึงอาจเลือกพร็อกซี่อื่นหรือถอยกลับไปใช้ DIRECT ภายใน VM

นี่ไม่ใช่ข้อบกพร่องในสคริปต์ สคริปต์ทำสิ่งที่เขียนไว้ให้ทำด้วยอินพุตที่ต่างออกไป และนั่นอธิบายรายงานที่ชวนสับสนซึ่งโฮสต์ใช้พร็อกซี่แต่เกสต์เชื่อมต่อโดยตรง ทำซ้ำการตัดสินใจแทนการคิดวิเคราะห์เกี่ยวกับมัน ตัวประเมิน PAC ที่รับที่อยู่และ URL หากดิสทริบิวชันของคุณมีอยู่ จะชี้ขาดคำถามด้วยคำสั่งเดียว มิฉะนั้นให้ทดสอบด้วยแอปพลิเคชันที่จะใช้จริง และอ่านบันทึกพร็อกซี่ของมันแทนการเดา

อย่าสรุปว่าเกสต์สืบทอดการตั้งค่าพร็อกซี่ของโฮสต์มาเพราะทราฟฟิกของมันผ่านการแปลที่ฝั่งโฮสต์ การแปลเครือข่ายส่งต่อแพ็กเก็ต มันไม่ได้คัดลอกการกำหนดค่าแอปพลิเคชัน และพร็อกซี่ของระบบคือการกำหนดค่าแอปพลิเคชัน

เครื่องมือที่ไม่เคยอ่าน PAC เลย

เครื่องมือบรรทัดคำสั่งเป็นขอบเขตแยกต่างหาก และนี่คือที่ที่เวลาจำนวนมากสูญเปล่า curl ไม่รันไฟล์ PAC ตามที่เอกสารพร็อกซี่ของมันระบุไว้อย่างชัดเจน การชี้ตัวแปรพร็อกซี่ไปที่ URL ดาวน์โหลด PAC ไม่ได้ทำให้สคริปต์กลายเป็นปลายทางพร็อกซี่ เครื่องมือจะพยายามพูด HTTP กับไฟล์ JavaScript และล้มเหลวในลักษณะที่ดูเหมือนปัญหาเครือข่าย

เช่นเดียวกันกับตัวจัดการแพ็กเกจจำนวนมาก รันไทม์ของภาษา และเครื่องมือสร้าง ที่เคารพเฉพาะตัวแปรพร็อกซี่ที่ระบุชัดเจนหรือการกำหนดค่าของตัวเองเท่านั้น หากการทดสอบที่คุณสนใจเป็นเครื่องมือ CLI ให้กำหนดค่าด้วยพร็อกซี่เฉพาะที่สคริปต์ PAC จะเลือก และบันทึกว่าคุณได้ตัวเลือกนั้นมาอย่างไรเพื่อให้คนถัดไปทำซ้ำได้

สำหรับแอปพลิเคชันเดสก์ท็อปบน Linux การตั้งค่าระบบต้องถูกตั้งเป็นโหมดอัตโนมัติและต้องได้รับ URL ด้วย URL ที่บันทึกไว้ในขณะที่โหมดยังเป็นแบบกำหนดเองไม่ทำอะไรเลย ตรวจสอบทั้งสองอย่าง และตรวจสอบภายในเกสต์:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT ก็เป็นการตัดสินใจ

ผลลัพธ์ PAC เป็น DIRECT หมายความว่าแอปพลิเคชันข้ามพร็อกซี่ HTTP ไม่ได้หมายความว่ามันหลุดออกจากเครือข่าย การเชื่อมต่อที่ได้ยังสามารถเดินตามเส้นทางของระบบปฏิบัติการผ่านอุโมงค์ หรือล้มเหลวด้วยเหตุผลที่ไม่เกี่ยวกับการใช้พร็อกซี่เลย ในทางกลับกัน ผลลัพธ์พร็อกซี่อธิบายคำขอของแอปพลิเคชันหนึ่ง ไม่ใช่ทุกโพรเซสในเกสต์

ดังนั้นจึงตรวจสอบในทิศทางที่ข้อกำหนดถูกเขียนไว้ หากข้อกำหนดคือ «แอปพลิเคชันนี้เข้าถึงไซต์ภายใน» ให้พิสูจน์ว่าแอปพลิเคชันนั้นเข้าถึง และบันทึกว่าพร็อกซี่หรือเส้นทางใดพามันไป หากข้อกำหนดคือ «VM อยู่ในเครือข่ายองค์กร» เบราว์เซอร์ที่ทำงานผ่านพร็อกซี่ที่เลือกคือหลักฐานสำหรับเบราว์เซอร์นั้นเท่านั้น

ซ่อมโซ่ภายในเกสต์แทนการปิดอุโมงค์ของโฮสต์หรือผ่อนนโยบายการส่งต่อเพื่อให้การทดสอบผ่าน โซ่มีสี่ข้อ และการเปลี่ยนแปลงที่ข้ามข้อใดข้อหนึ่งจะคงอยู่จนกว่าสคริปต์จะถูกอัปเดตหรือที่อยู่ของเกสต์เปลี่ยนในครั้งถัดไป