OpenVPN หลุดทุกชั่วโมง: เจรจาใหม่หรือเชื่อมต่อใหม่จริง?

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

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

แยกแยะการรีเซ็ตแบบนุ่มจากการรีสตาร์ต

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

อ่านตัวจับเวลาที่มีผลจริง ไม่ใช่ไฟล์ของคุณ

reneg-sec คือจำนวนวินาทีระหว่างการเจรจาใหม่ของช่องข้อมูล และค่าเริ่มต้นคือ 3600 แต่ละฝั่งมีค่าของตัวเอง และค่าที่น้อยกว่าระหว่างสองฝั่งคือสิ่งที่กระตุ้นการรีเฟรชจริง กฎข้อเดียวนี้อธิบายรายงานส่วนใหญ่: โปรไฟล์ไคลเอนต์ที่ตั้งค่าเป็นตัวเลขมากยังถูกรีเซ็ตทุกชั่วโมงตราบใดที่เซิร์ฟเวอร์ยังคงค่าเริ่มต้น

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

เปลี่ยนตรงจุดที่มันถูกพุชจริง

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

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

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

คุณเสียอะไรไปเมื่อปิดการเจรจาใหม่

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

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

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

เมื่อช่วงเวลาชี้ไปที่อื่น

เพื่อนบ้านสองตัวในการกำหนดค่าให้อาการคล้ายกันและวิธีแก้ต่างกัน ping-restart จะรีสตาร์ตอุโมงค์เมื่อไม่มีอะไรเข้ามาตามระยะที่กำหนด ส่วน ping-exit จะลดไคลเอนต์ลงทั้งหมด การหลุดตอนว่างที่ไม่มีการเจรจาใหม่ที่ใดในล็อกเป็นของสองตัวนี้ หรือของอุปกรณ์ NAT ที่ปล่อยให้การแมป UDP หมดอายุตามตารางของตัวเอง

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

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