อุโมงค์ยังอยู่ แต่เส้นทางหายไป: แยกความล้มเหลวของ VPN สองแบบ

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

สามขั้นตอนที่ดูเหมือนเหตุการณ์เดียว

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

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

อ่านเส้นทางที่ติดตั้งไว้ก่อน

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

จากนั้นดูมุมมองของโปรโตคอลเอง

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

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

เมื่อนาฬิกาไม่ตรงกัน

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

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

การกู้คืนโดยไม่มีลูป

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

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