พอร์ต TCP เปิดไม่ได้พิสูจน์ว่าพร็อกซีใช้งานได้

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

พอร์ต TCP ที่เปิดบอกว่าลิสเทนเนอร์รับการเชื่อมต่อแล้ว อาจเป็นพร็อกซี เว็บเซิร์ฟเวอร์ทั่วไป หรือบริการอื่นก็ได้ พอร์ต 8080 ไม่ได้ระบุโปรโตคอล

สำหรับเอนด์พอยต์ที่เอกสารระบุว่าเป็นพร็อกซี HTTP ให้ใช้ที่อยู่จริงในคำขอ HTTPS ที่จำกัดเวลา:

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/

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

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

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

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

บันทึกขั้นตอนสุดท้ายที่สำเร็จ ‘พอร์ตเปิด แต่การเจรจา SOCKS ถูกปฏิเสธ’ ช่วยให้การตรวจสอบครั้งต่อไปมีจุดเริ่มต้นที่ชัดเจน

บทความที่เกี่ยวข้อง