การเชื่อมต่อถูกรีเซ็ตโดยคู่ผ่านพร็อกซี: หาขั้นตอนที่ล้มเหลว
ใช้ขั้นตอนการเชื่อมต่อและหลักฐานสนับสนุนเพื่อตรวจสอบการรีเซ็ตของพร็อกซี โดยไม่ถือข้อความข้อผิดพลาดสั้น ๆ ของระบบปฏิบัติการเป็นการระบุสาเหตุ
“Connection reset by peer” บ่งชี้ถึงการเชื่อมต่อการขนส่งที่ขาดหาย ไม่ได้ระบุผู้ให้บริการอินเทอร์เน็ต ผู้ดำเนินการพร็อกซี หรือเว็บไซต์ว่าเป็นสาเหตุ
| เวลาของการรีเซ็ต | จะตรวจสอบที่ใด |
|---|---|
| ทันทีหลังจาก TCP เชื่อมต่อ | โปรโตคอลไม่ตรงกันหรือบริการที่ปฏิเสธการแลกเปลี่ยนเริ่มต้น |
| หลังจาก CONNECT สำเร็จ | เส้นทางอุโมงค์ที่สร้างขึ้น |
| ระหว่างการตอบสนอง | การปิดต้นน้ำ นโยบายอายุการใช้งานของตัวกลาง และเส้นทางส่งต่อ |
จากนั้นเปลี่ยนเงื่อนไขที่เกี่ยวข้องหนึ่งอย่างโดยให้พร็อกซีและปลายทางคงที่ เปรียบเทียบการเชื่อมต่อแบบเข้ารหัสจากไคลเอนต์ไปยังพร็อกซีที่กำหนดค่าอย่างถูกต้อง ในกรณีที่รองรับ หรือไคลเอนต์เดียวกันจากเครือข่ายอื่นที่ได้รับอนุญาต ถามว่าผู้ดำเนินการสามารถเชื่อมโยงความพยายามนี้ในบันทึกของตนได้หรือไม่
ผลลัพธ์ที่แตกต่างทำให้การตรวจสอบแคบลง แต่ไม่ได้พิสูจน์สาเหตุเดียว การส่งทราฟฟิกผ่านอุโมงค์อาจเปลี่ยนเวลา ภาระ นโยบาย และอุปกรณ์กลางพร้อมกัน ความสำเร็จเพียงอย่างเดียวไม่สามารถยืนยันการปิดกั้นโดยเจตนาบนเส้นทางเดิมได้
ในที่ที่มีการสังเกตแพ็กเก็ตที่ได้รับอนุญาต ให้เปรียบเทียบกับบันทึกของแอปพลิเคชันและพร็อกซี แม้แต่ที่อยู่ต้นทางของแพ็กเก็ตที่คาดหวังก็ไม่อธิบายว่าทำไมจึงส่งการรีเซ็ตหรือระบบใดบังคับใช้นโยบาย
เก็บรักษาข้อผิดพลาดเชิงตัวเลข เวลา จุดปลายทาง และขั้นตอนสุดท้ายที่เสร็จสมบูรณ์ ใช้หลักฐานนั้นก่อนเปลี่ยนข้อมูลรับรองหรือการตั้งค่า TLS ข้อความรีเซ็ตสั้น ๆ ในตัวเองไม่ได้ให้เหตุผลใด ๆ ในการเปลี่ยนทั้งสองอย่าง