ทำไมลำดับอะแดปเตอร์ไม่กำหนดเส้นทาง VPN ของแล็บคุณ

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

สามเงื่อนไขกำหนดเส้นทาง

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

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

เงื่อนไขที่หนึ่ง: พรีฟิกซ์ใดชนะ

เส้นทางไปยัง 10.8.0.0/24 ชนะเส้นทางเริ่มต้นสำหรับที่อยู่ภายในนั้น ไม่ว่าเมตริกจะเป็นอย่างไรและไม่ว่าลำดับอะแดปเตอร์จะเป็นอย่างไร นี่คือเหตุผลที่ไคลเอนต์ VPN ซึ่งติดตั้งเส้นทางเฉพาะยังทำงานต่อไปได้แม้มีอะแดปเตอร์ตัวที่สองที่มีเมตริกต่ำกว่าเกิดขึ้น เพราะความเจาะจงชนะก่อนที่จะพิจารณาต้นทุน ตรวจสอบตารางที่คุณคิดว่าใช้งานอยู่ด้วย ip route show และตรวจสอบคำตอบที่เคอร์เนลจะให้จริงสำหรับปลายทางหนึ่งด้วย ip route get 203.0.113.9

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

เงื่อนไขที่สอง: เมตริกทำอะไรและไม่ทำอะไร

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

ในเกสต์ ip route show พิมพ์เมตริกไว้ข้างแต่ละเส้นทาง และ Get-NetRoute บน Windows พิมพ์ InterfaceMetric พร้อมเมตริกเส้นทาง ควรอ่านทั้งสอง เพราะความชอบที่มีผลจริงอาจเป็นผลรวมไม่ใช่ฟิลด์เดียว ถ้ามีเส้นทางเริ่มต้นสองเส้นทาง นั่นคือสิ่งที่พบ: เกสต์มีทางออกสองทาง และเส้นใดชนะขึ้นอยู่กับตัวเลขที่การเปลี่ยนฮาร์ดแวร์อาจทำให้เปลี่ยนไป

เงื่อนไขที่สาม: เกสต์ใช้สิ่งใดจริง

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

ตรวจสอบสถานะที่ใช้งาน ไม่ใช่สถานะที่ตั้งใจ ip -br link แสดงอินเทอร์เฟซที่มีอยู่ตอนนี้ และบนโฮสต์ที่ใช้ NetworkManager nmcli connection show แสดงว่าโปรไฟล์ใดผูกกับอุปกรณ์ใด โปรไฟล์ที่ผูกไม่สำเร็จจะทิ้งอินเทอร์เฟซไว้โดยไม่มีที่อยู่ ซึ่งดูเหมือนปัญหาเส้นทางแต่จริง ๆ เป็นปัญหาการตั้งชื่อ สแนปช็อตที่กู้คืนมาทำให้แย่ลง เพราะสถานะที่บันทึกไว้ของเกสต์อาจอ้างถึงอัตลักษณ์อะแดปเตอร์ที่ฮาร์ดแวร์ใหม่ไม่ได้ให้แล้ว

ทำให้โครงสร้างของแล็บทำซ้ำได้

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

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

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

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