การอ่านข้อผิดพลาด SO_ORIGINAL_DST ของ Squid

NF getsockopt(SO_ORIGINAL_DST) ชี้ไปที่การค้นหาปลายทางดั้งเดิม ในการตั้งค่าการดักจับ Squid ต้องกู้คืนว่าการเชื่อมต่อที่ถูกเปลี่ยนเส้นทางนั้นมุ่งไปที่ใดแต่เดิม

เบราว์เซอร์ที่กำหนดค่าไว้อย่างชัดเจนส่งคำขอไปยังพร็อกซีโดยเจตนา การเชื่อมต่อนั้นไม่ได้ได้มาซึ่งประวัติการดักจับ NAT เพียงเพราะมี intercept เขียนอยู่ข้างพอร์ตของตัวรับฟัง Squid

ดังนั้นความไม่ตรงกันนี้อาจล้มเหลวก่อนที่ใบรับรองของปลายทางจะเกี่ยวข้อง

เริ่มจากการที่การเชื่อมต่อมาถึงอย่างไร

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

เอกสาร http_port ของ Squid ทำให้ความแตกต่างชัดเจน: การละเว้นแฟล็กโหมดจะเลือกโหมดพร็อกซีส่งต่อ; intercept คาดหวังการดักจับ NAT ที่ชั้น IP

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

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