เมื่อเส้นทางของอุโมงค์แยกส่วนทับซ้อนกัน: คำนำหน้าใดชนะ

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

1. บันทึกปลายทางและต้นทาง

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

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

2. ถามเคอร์เนลว่าเลือกเส้นทางใด

อย่าอ่านตารางเส้นทางแล้วอนุมานคำตอบ ให้ถามคำถามเดียวกับที่สแตกถาม ด้วยที่อยู่ต้นทางเดียวกัน: ip route get 10.20.4.10 from 10.8.0.2 บน Linux หรือ Find-NetRoute -RemoteIPAddress 10.20.4.10 ใน PowerShell เอาต์พุตจะระบุเส้นทางที่จะถูกใช้จริง และบ่อยครั้งไม่ใช่เส้นทางที่คุณคาดไว้เมื่ออ่านตาราง

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

3. ตรวจสอบว่ากฎนโยบายเปลี่ยนเส้นทางการค้นหาหรือไม่

ก่อนที่ตารางเส้นทางจะถูกตรวจ เคอร์เนลจะไล่ผ่านกฎนโยบายของตน กฎหนึ่งอาจส่งทราฟฟิกจากต้นทาง ผู้ใช้ หรือเครื่องหมายไฟร์วอลล์ที่กำหนดไปยังตารางอื่นโดยสิ้นเชิง ดังนั้นคำนำหน้าที่ชนะในตารางหลักอาจไม่ถูกตรวจเลยสำหรับโฟลว์นั้น ip rule show แสดงรายการตามลำดับการประเมิน และ ip route show table 100 แสดงสิ่งที่ตารางที่เลือกมีอยู่จริง

มีกับดักสองอย่างที่นี่ กฎที่ชี้ไปยังตารางว่างจะสร้างการค้นหาที่ตกผ่านไปยังกฎถัดไป ดังนั้นกฎจึงดูเหมือนไม่ทำอะไรเลย อีกอย่างคือหมายเลขลำดับความสำคัญเอง: กฎถูกอ่านตามลำดับจากน้อยไปมาก และค่าที่มีมาในระบบคือ 0 local, 32766 main และ 32767 default กฎที่มีหมายเลขต่ำกว่า 32767 จะถูกตรวจก่อนกฎเริ่มต้นที่ดักทุกอย่าง กฎที่มีหมายเลขสูงกว่า 32767 อยู่ข้างหลังและเข้าถึงได้เฉพาะเมื่อไม่มีตารางก่อนหน้าตอบ ซึ่งเส้นทางเริ่มต้นปกติใน main ป้องกันไว้ ดังนั้นในทางปฏิบัติจึงไม่เคยเข้าถึงและเงียบ ๆ ไม่ทำอะไรเลยในขณะที่ดูเหมือนถูกติดตั้ง หากไคลเอนต์เขียนกฎและเส้นทางไว้ ให้ตรวจทั้งสอง และตรวจอีกครั้งหลังเชื่อมต่อใหม่ เพราะโปรไฟล์ที่เขียนใหม่สามารถเพิ่มกฎที่สองด้วยลำดับความสำคัญอื่นได้

4. แยกความเสมอกันของเส้นทางออกจากแผนที่อยู่ซ้ำ

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

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

5. ยืนยันว่าตัวแปลงชื่อสอดคล้องกับเส้นทาง

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

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

6. เชื่อมต่อใหม่ ตรวจสอบสถานะที่ถูกนำไปใช้ แล้วทดสอบทั้งสองโฟลว์

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

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