ทำไมเส้นทางต้นทุนเท่ากันจึงทำให้ข้อขัดข้องของ VPN เห็นได้ยาก
เมื่อหลายอุโมงค์แบ่งต้นทุนเดียวกัน แต่ละโฟลว์อาจเลือกคนละเส้น ping ที่สำเร็จไม่ได้บอกอะไรเกี่ยวกับเส้นทางที่แอปพลิเคชันของคุณใช้จริง
ผู้ใช้รายงานว่าแอปพลิเคชันภายในทำงานได้จากเครื่องหนึ่งและล้มเหลวจากอีกเครื่องหนึ่ง ขณะที่ ping ที่คุณรันจากเกตเวย์สำเร็จทั้งสองกรณี เมื่อมีอุโมงค์หลายเส้นที่มีต้นทุนเท่ากัน นี่ไม่ใช่ความขัดแย้ง แต่ละโฟลว์ถูกวางบนฮอปถัดไปของตัวเอง การตรวจสอบของคุณกับเซสชันของผู้ใช้จึงอาจใช้เส้นทางต่างกัน วิธีด้านล่างจะสร้างการเลือกนั้นขึ้นมาใหม่ก่อนจะเปลี่ยนแปลงสิ่งใด
ping ครั้งเดียว หลายเส้นทางที่เป็นไปได้
เมื่อเส้นทางมีฮอปถัดไปมากกว่าหนึ่งที่ต้นทุนเท่ากัน เราเตอร์ต้องเลือกหนึ่งรายการต่อแพ็กเก็ต การใช้งานส่วนใหญ่ทำแฮชฟิลด์จากแพ็กเก็ต โดยทั่วไปคือที่อยู่ต้นทางและปลายทางพร้อมโปรโตคอลและพอร์ต เพื่อให้คำตอบอยู่บนเส้นทางเดิม แอปพลิเคชันต่างกัน หรือแม้แต่การเชื่อมต่อต่างกันของแอปพลิเคชันเดียว ก็ให้แฮชต่างกัน
นี่คือเหตุผลที่การวินิจฉัยจากเกตเวย์พิสูจน์ได้น้อยนัก การตรวจสอบของเกตเวย์เองมีที่อยู่และพอร์ตของตัวเอง จึงมีแฮชของตัวเอง มันอาจไปลงบนอุโมงค์ที่ดี ขณะที่ผู้ใช้ยังคงไปลงบนอุโมงค์ที่เสีย
แพลตฟอร์มเลือกฮอปถัดไปอย่างไร
สร้างการเลือกขึ้นมาใหม่แทนการเดา ถามเคอร์เนลว่าจะใช้เส้นทางใดสำหรับต้นทางและปลายทางเดียวกับเซสชันที่ล้มเหลว การค้นหานั้นรวมฟิลด์ที่การค้นหาปลายทางธรรมดามองข้าม เรียกใช้จากไคลเอนต์ที่ทำงานได้ด้วยแล้วเปรียบเทียบสองคำตอบ:
ip route get 10.20.5.7 from 10.20.0.14iproute2 รุ่นใหม่กว่ายอมรับโปรโตคอลและพอร์ตปลายทางด้วย ซึ่งสำคัญเมื่อแฮชรวมสิ่งเหล่านั้น เปรียบเทียบผลลัพธ์นั้นกับการค้นหาเดียวกันจากไคลเอนต์ที่ทำงานได้ และความต่างคือหลักฐานที่คุณขาดไป
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
ตามโฟลว์ที่ล้มเหลว ไม่ใช่ตารางเส้นทาง
ตารางเส้นทางแสดงอุโมงค์ทั้งสองและดูถูกต้องตามนิยาม คำถามคือแต่ละอุโมงค์ทำอะไรกับแพ็กเก็ตเมื่อถูกเลือกแล้ว ตรวจสอบว่าทั้งคู่มีคำนำหน้าที่ป้องกันเหมือนกัน สิทธิ์ส่งต่อเหมือนกัน และเส้นทางย้อนกลับที่ไปถึงไคลเอนต์เดียวกัน
ใส่ใจอุปกรณ์ที่มีสถานะตรงกลาง หากคำขอออกทางอุโมงค์หนึ่งและคำตอบกลับมาทางอีกอุโมงค์หนึ่ง ไฟร์วอลล์หรือ NAT ที่ไม่เคยเห็นโฟลว์ต้นฉบับจะทิ้งมันไป อุโมงค์ทั้งสองส่งต่อทราฟฟิกได้ถูกต้อง แต่การเชื่อมต่อก็ยังล้มเหลว
ตรวจสอบ MTU ของแต่ละเส้นทางด้วย เส้นทางที่มีการห่อหุ้มเพิ่มเติมจะลดขนาดที่ใช้ได้ และการถ่ายโอนที่สำเร็จบนอุโมงค์หนึ่งจะหยุดบนอีกอุโมงค์ที่ขนาดเดียวกับที่อุโมงค์เล็กกว่าพัง
เปรียบเทียบทีละเส้นทาง
ที่ซึ่งการออกแบบอนุญาตให้บำรุงรักษา ให้ถอดอุโมงค์หนึ่งออกจากบริการแล้วทำภารกิจของผู้ใช้ซ้ำ หากข้อขัดข้องหายไป ปัญหาเป็นของเส้นทางที่คุณถอดออก และขั้นต่อไปคือเปรียบเทียบการกำหนดค่ากับเส้นทางข้างเคียง แทนที่จะตรวจตารางเส้นทางใหม่
เปรียบเทียบแอปพลิเคชันจริง ไม่ใช่ ping ซ้ำ ๆ บันทึกว่าข้อขัดข้องตามฮอปถัดไปที่เฉพาะเจาะจง ขนาดแพ็กเก็ต หรือการเปลี่ยนผ่านหลังเชื่อมต่อใหม่ เพราะรูปแบบทั้งสามชี้ไปยังการซ่อมที่ต่างกัน
สุดท้าย จดบันทึกว่าเหตุใดเส้นทางจึงถือว่าเทียบเท่ากัน และข้อขัดข้องควรถอดหนึ่งในนั้นออกจากบริการอย่างไร หลายเส้นทางจะปลอดภัยก็ต่อเมื่อเส้นทางแลกเปลี่ยนกันได้จริง และนั่นเป็นข้อความเชิงออกแบบที่ควรตรวจสอบไม่ใช่สันนิษฐาน