OpenVPN หลุดหลังต่ออายุ DHCP: รักษาเส้นทางของปลายทาง
การต่ออายุ DHCP อาจทิ้งปลายทางของอุโมงค์ไว้บนเกตเวย์เก่า และเส้นทางครึ่งค่าเริ่มต้นก็กลืนอุโมงค์ไป แก้ที่ใครเป็นเจ้าของเส้นทางนั้น ไม่ใช่เมตริก
อุโมงค์เชื่อมต่อได้ แล้วการต่ออายุสัญญาเช่าบนลิงก์เชื่อมต่อก็ฆ่ามัน และบันทึกโทษการหมดเวลาแทนที่จะโทษเส้นทาง ไม่มีอะไรเปลี่ยนในคอนฟิก VPN และนั่นคือเบาะแส: มีบางอย่างนอกนั้นเปลี่ยนไป เหตุการณ์ DHCP เขียนที่อยู่หรือเกตเวย์ใหม่ และเส้นทางโฮสต์ที่ทำให้ปลายทางของอุโมงค์เข้าถึงได้ตอนนี้ชี้ไปยังฮอปถัดไปที่ไม่มีอยู่แล้ว นี่คือปัญหาเรื่องเจ้าของก่อนจะเป็นปัญหาเรื่องเราเตอร์
เทียบอาการกับเส้นทางครึ่งค่าเริ่มต้น
ด้วย redirect-gateway def1 OpenVPN จะติดตั้ง 0.0.0.0/1 และ 128.0.0.0/1 แทนที่จะแทนที่เส้นทางค่าเริ่มต้น ทั้งสองรวมกันครอบคลุมพื้นที่ที่อยู่ทั้งหมด และชนะ 0.0.0.0/0 ด้วยความยาวพรีฟิกซ์เท่านั้น ดังนั้นปลายทางใด ๆ ที่ไม่มีการจับคู่ที่เจาะจงกว่า จึงเข้าสู่อุโมงค์
ปลายทางต้องการข้อยกเว้น OpenVPN เพิ่มเส้นทางโฮสต์ไปยังที่อยู่เซิร์ฟเวอร์ผ่านเกตเวย์เชื่อมต่อเดิมก่อนที่ครึ่งค่าเริ่มต้นจะถูกใส่ เพื่อให้แพ็กเก็ตที่ห่อหุ้มออกไปได้ เมื่อข้อยกเว้นนั้นหายไป หรือยังคงฮอปถัดไปที่ไม่มีอยู่แล้ว แพ็กเก็ตชั้นนอกของอุโมงค์เองจะตรงกับเส้นทางครึ่งค่าเริ่มต้นและถูกส่งกลับเข้าไปในอุโมงค์ ผลลัพธ์คือการเชื่อมต่อที่ตายในการคงสถานะหรือแฮนด์เชกครั้งถัดไป โดยไม่มีอะไรในบันทึกที่ดูเหมือนข้อผิดพลาดของเส้นทาง
ยืนยันรูปร่างของตารางก่อนแตะสิ่งอื่น ip route show ควรแสดงทั้งสองครึ่งพร้อมเส้นทางโฮสต์สำหรับที่อยู่เซิร์ฟเวอร์ เมื่อไม่มีเส้นทางโฮสต์ ส่วนที่เหลือของการสอบสวนก็มีจุดเริ่มต้นที่ชัดเจน
ทำไมครึ่งค่าเริ่มต้นจึงชนะโดยไม่เปลี่ยนเมตริก
เมตริกที่ต่ำกว่าไม่ชนะพรีฟิกซ์ที่ยาวกว่า เส้นทาง /1 ชนะเพราะเคอร์เนลจับคู่เส้นทางที่เจาะจงที่สุดก่อน การเพิ่มเมตริกบนเส้นทางค่าเริ่มต้นจึงไม่เปลี่ยนว่าทราฟฟิกที่มุ่งสู่อุโมงค์จะไปที่ใด การไล่ตามเมตริกคือทางเลี้ยวผิดที่พบบ่อยที่สุดในการวินิจฉัยนี้
ตรวจสอบการเลือกด้วย ip route get 203.0.113.10 โดยใส่ที่อยู่เซิร์ฟเวอร์จริง คำตอบระบุอินเทอร์เฟซและฮอปถัดไปที่เคอร์เนลจะใช้จริง ซึ่งให้ข้อมูลมากกว่าการอ่านตารางแล้วคิดเอาเอง
รันคำสั่งนั้นก่อนที่อุโมงค์จะเริ่ม ขณะทำงาน และหลังเหตุการณ์สัญญาเช่า สามคำตอบจากคำสั่งเดียว และจุดที่แตกต่างก็ปรากฏขึ้น
เก็บสแนปช็อตสามครั้ง ไม่ใช่ครั้งเดียว
เก็บที่อยู่เชื่อมต่อ เกตเวย์เชื่อมต่อ ปลายทางของปลายทาง เส้นทางที่เลือก และกฎนโยบายใด ๆ ในสามช่วงเวลา: หลังตั้งค่าลิงก์เชื่อมต่อ หลัง VPN เชื่อมต่อ และหลังเหตุการณ์สัญญาเช่าหรือผู้ให้บริการ แต่ละสแนปช็อตคือคำสั่งไม่กี่คำสั่ง และมีความหมายก็ต่อเมื่ออยู่ด้วยกัน สแนปช็อตครั้งเดียวหลังความล้มเหลวบันทึกสถานะ ไม่ใช่การเปลี่ยนผ่าน เขียนคำสั่งลงในสคริปต์เล็ก ๆ เพื่อให้แต่ละสแนปช็อตถูกเก็บด้วยวิธีเดียวกัน
เก็บสแนปช็อตไว้ในไฟล์เดียวพร้อมตราเวลา เพราะคำถามที่น่าสนใจในภายหลังคือลำดับ เหตุการณ์ DHCP เกิดก่อนหรือหลังที่ OpenVPN รีเฟรชเส้นทางของมัน คำตอบเป็นตัวกำหนดว่าใครต้องแก้ ตราเวลาจากนาฬิกาที่ผิดแย่กว่าไม่มีเลย ดังนั้นเก็บจากโฮสต์ที่เป็นเจ้าของตารางเส้นทาง
เมื่อปลายทางถูกกำหนดเป็นชื่อแทนที่อยู่ ให้แปลงชื่อนั้นในแต่ละสแนปช็อตด้วย การเปลี่ยน DNS บนลิงก์เชื่อมต่อสามารถย้ายปลายทางได้โดยไม่แตะเส้นทางใดเลย
ตัดสินว่าองค์ประกอบใดรีเฟรชข้อยกเว้น
บนระบบ dhcpcd ฮุกทำงานจากไดเรกทอรีฮุกและจากฮุกทางออก และโหมดผู้จัดการต่างขอบเขตจากโหมดต่ออินเทอร์เฟซ ไม่ว่าฮุกจะทำอะไร มันต้องทำงานซ้ำได้อย่างปลอดภัย เพราะการต่ออายุอาจมาเป็นระลอก
เจ้าของที่เชื่อถือได้คือการรวมระบบที่รู้ทั้งสองด้านอยู่แล้ว: ตัวจัดการเครือข่ายที่ดูแลการเชื่อมต่อ VPN หรือยูนิตที่ถูกจัดลำดับหลังลิงก์เชื่อมต่อขึ้น เส้นทางแบบคงที่ที่ฮุกเพิ่มจะทำงานจนถึงการเปลี่ยนเกตเวย์ครั้งถัดไป แล้วล้มเหลวในแบบเดียวกันเป๊ะ ถ้าคุณใช้ฮุกจริง ๆ ให้มันอ่านเกตเวย์ปัจจุบันตอนรันแทนการฮาร์ดโค้ดตัวที่คุณเห็นวันนี้
บันทึกเจ้าของไว้ในคอนฟิก คนถัดไปที่ต้องดีบักการเชื่อมต่อใหม่ต้องรู้ว่าฮุก ไม่ใช่ VPN เป็นผู้รับผิดชอบเส้นทางข้อยกเว้น
ทดสอบวงจรชีวิต ไม่ใช่แค่การเชื่อมต่อใหม่
บังคับต่ออายุด้วย dhcpcd -n eth0 หรือโดยปล่อยและรับสัญญาเช่าใหม่ แล้วตรวจ ip route get สำหรับปลายทางอีกครั้ง ทำสองครั้ง เพราะรอบที่สองจะจับฮุกที่เพิ่มเส้นทางซ้ำ จากนั้นรีบูต เพราะความคงอยู่เป็นคนละคุณสมบัติกับความถูกต้อง
อุโมงค์ที่รอดจากการต่ออายุและการรีบูตมีเจ้าของและข้อยกเว้นที่ทำงานได้ อันที่รอดเพียงการรีสตาร์ตด้วยมือไม่มีทั้งสองอย่าง และจะล้มเหลวในเหตุการณ์ถัดไปที่คุณตั้งเวลาไม่ได้