P_CONTROL_HARD_RESET_CLIENT_V2 ในล็อก: เป็นข้อผิดพลาดหรือไม่

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

รหัสปฏิบัติการระบุตำแหน่งในโปรโตคอล

OpenVPN มัลติเพล็กซ์แพ็กเก็ตหลายชนิดบนซ็อกเก็ตเดียว และรหัสปฏิบัติการบอกผู้รับว่ากำลังถือชนิดใด แพ็กเก็ต hard-reset เปิดเซสชัน แพ็กเก็ตควบคุมนำวัสดุจับมือ การตอบรับยืนยันการรับ และแพ็กเก็ตข้อมูลนำเพย์โหลดของอุโมงค์ การอ่านไบต์แรกบอกว่าแพ็กเก็ตอยู่ในตำแหน่งใดของการแลกเปลี่ยนนั้น และ นิยามแพ็กเก็ตในซอร์สโค้ด ระบุชื่อแต่ละตระกูลอย่างชัดเจน

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

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

สิ่งที่ไคลเอนต์กำลังทำจริงในขณะนั้น

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

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

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

ความล้มเหลวจริงซ่อนอยู่ที่ใดหลังการรีเซ็ต

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

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

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

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

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

ทำไมการปิดการตรวจสอบจึงเป็นการตอบสนองที่ผิด

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

เปลี่ยนขอบเขตที่ล้มเหลวจริงแทน ปัญหาความไว้วางใจเป็นของผู้ออกใบรับรองและโปรไฟล์ที่อ้างถึงมัน ปัญหาเวลาเป็นของนาฬิกา ปัญหาข้อมูลรับรองเป็นของระบบหลังบ้านการพิสูจน์ตัวตนที่ปฏิเสธมัน และคู่สนทนาที่เข้าถึงไม่ได้เป็นของเส้นทางระหว่างสองโฮสต์

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