การย้อนกลับของรีเพลย์ OpenVPN ในบันทึก: สิ่งที่บรรทัดไม่ได้พิสูจน์

บรรทัดกล่าวว่า PID_ERR replay-window backtrack occurred และผลการค้นหาทั้งหมดอธิบายว่าเป็นแพ็กเก็ตที่หลุดและอุโมงค์ที่เสียหาย ในเส้นทาง UDP ของ Community OpenVPN 2.6 ข้อความนั้นถูกเขียนขณะที่ฟังก์ชันรับยังตัดสินใจว่าจะทำอย่างไรกับแพ็กเก็ต มันบันทึกค่าสูงสุดใหม่ของการย้อนกลับ จากนั้นฟังก์ชันเดิมจะเปรียบเทียบระยะทางกับหน้าต่างและสถานะที่บันทึกไว้ก่อนจะรับหรือปฏิเสธ การอ่านป้ายบันทึกเป็นคำตัดสิน คือข้อผิดพลาดที่รายการตรวจสอบนี้มีไว้เพื่อป้องกัน

จุดหยุดที่หนึ่ง: ระบุว่าบรรทัดคืออะไร

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

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

จุดหยุดที่สอง: ค้นหาผลลัพธ์ของแพ็กเก็ตนั้น

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

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

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

จุดหยุดที่สาม: ตัดสินว่าการจัดเรียงใหม่เป็นจริงหรือไม่

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

ข้อความไม่กี่ข้อความระหว่างการเชื่อมต่อใหม่ไม่ใช่เรื่องแปลก กระแสต่อเนื่องควบคู่กับเวลาหมดจริงของแอปควรค่าแก่การตรวจสอบ และการรวมกันนั้นเป็นหลักฐาน ไม่ใช่ป้ายกำกับ

จุดหยุดที่สี่: พารามิเตอร์หน้าต่าง และสิ่งที่ไม่ใช่

replay-window รับขนาดลำดับและค่าหน่วยเวลาแบบเลือกได้ ดังนั้นการขยายจึงเปลี่ยนความอดทนสองอย่างพร้อมกัน การเพิ่มจำนวนยอมให้แพ็กเก็ตที่อยู่นอกลำดับไกลขึ้น ส่วนค่าหน่วยเวลาจำกัดว่าแพ็กเก็ตยังพิจารณาได้นานเท่าใด การขยายเป็นการเปลี่ยนนโยบายที่มีต้นทุนด้านความปลอดภัย และไม่ได้เสริมความแข็งแกร่งของไซเฟอร์หรือปิดการตรวจจับรายการซ้ำ ความอดทนทั้งสองเคลื่อนไปด้วยกัน ไม่ว่าคุณจะตั้งใจหรือไม่

แพ็กเก็ตที่ผ่านการรับรองเก่าอาจยังเป็นการทำซ้ำที่ไม่ต้องการ จึงเป็นเหตุให้ผู้รับคงการตรวจสอบเหล่านี้ไว้ การยอมรับการจัดเรียงใหม่มากขึ้นหมายถึงการยอมรับความเสี่ยงนั้นมากขึ้น

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

mute 20
replay-window 64 15

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

จุดหยุดที่ห้า: ทดสอบเส้นทางที่ผู้ใช้ให้ความสำคัญ

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

จดสิ่งที่คุณวัดได้ในแต่ละจุดหยุด บันทึกนั่นแหละที่กันไม่ให้รายงานถัดไปเริ่มต้นที่บรรทัดที่น่ากลัวอีกครั้งและทำงานจากตรงนั้นออกไป

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