การกำหนดเส้นทางนโยบาย IPv6 เมื่ออัปลิงก์สองเส้นใช้ fe80::1 ร่วมกัน

คุณมีอัปลิงก์สองเส้น และ ip -6 route show พิมพ์ฮอปถัดไปเดียวกันบนทั้งสองเส้น: default via fe80::1 dev uplink0 และ default via fe80::1 dev uplink1. นี่ไม่ใช่ความขัดแย้งของที่อยู่ซ้ำ และการคัดลอกฮอปถัดไปเปล่า ๆ fe80::1 ลงในตารางนโยบายไม่ได้บอกเคอร์เนลว่าคุณหมายถึงลิงก์ใด คำถามจริงแคบกว่าที่อาการบอกไว้: ตารางที่สองต้องการลิงก์เดียวหรือทั้งสอง และอะไรทำให้เส้นทางเหล่านั้นยังมีชีวิตหลังรีบูต เงื่อนไขสามข้อที่ตรวจตามลำดับช่วยแก้ส่วนใหญ่ได้

fe80::1 เดียวกันคือเพื่อนบ้านสองรายที่ต่างกัน

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

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

ถอดอุปกรณ์ออกแล้วเส้นทางจะเขียนไม่ได้ ip -6 route add default via fe80::1 table 200 ไม่สามารถแก้เกตเวย์ได้ และ iproute2 จะปฏิเสธด้วย Error: Nexthop has invalid gateway. ข้อผิดพลาด เพิ่ม dev uplink0 แล้วคำสั่งจะสำเร็จ เพราะอุปกรณ์คือสิ่งที่ตรึงฮอปถัดไปไว้กับเพื่อนบ้านสองรายนั้น สิ่งที่อุปกรณ์บอกไม่ได้คือ uplink0 เป็นลิงก์ที่ถูกต้องสำหรับตารางนี้หรือไม่ และเส้นทางที่คัดลอกจากโฮสต์อื่นจะนำชื่ออินเทอร์เฟซของโฮสต์นั้นมาด้วย ความผิดพลาดจริงจึงมาจากตรงนั้น

เงื่อนไขข้อหนึ่ง: หนึ่งลิงก์หรือสองลิงก์ในตาราง

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

ในกรณีที่สอง กฎตัดสินว่าเมื่อใดจะดูตาราง และเส้นทางตัดสินว่าแพ็กเก็ตจะไปที่ใดหลังจากนั้น:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

ไม่มีวัตถุใดแทนที่อีกวัตถุได้ และตารางที่มีเพียงดีฟอลต์ก็ยังอาจแก้เกตเวย์ของตัวเองไม่ได้ ถ้าการเพิ่มถูกปฏิเสธ หรือมีเส้นทางแต่ใช้ไม่ได้ ให้ใส่คำนำหน้าแบบเชื่อมต่อของอินเทอร์เฟซนั้นลงในตารางเดียวกัน หรือทำเครื่องหมายฮอปเป็น onlink (เมื่อคำนำหน้านั้นถูกกำหนดเส้นทางที่อื่น) ในบล็อกข้างบน 2001:db8:100::/48 แทนคำนำหน้าแบบเชื่อมต่อนั้นบน uplink1 ไม่ใช่ปลายทางอะไรก็ได้ กฎ fwmark ใช้เพียงเครื่องหมายที่สิ่งอื่นต้องตั้งให้ จากกฎ nftables หรือ iptables บนเส้นทางส่งต่อ หรือจาก SO_MARK บนซ็อกเก็ต ดังนั้นบล็อกที่คัดลอกมาโดยไม่มีแหล่งเครื่องหมายจะไม่ตรงกับอะไรเลย

เงื่อนไขข้อสอง: เมตริกตรวจไม่พบผู้ให้บริการที่ตายแล้ว

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

ตรวจสอบตัวเลือกหลังสร้างตารางแล้ว และตรวจสอบในแบบที่เคอร์เนลจะมองเห็น ip -6 route get 2001:db8:100::1 พิมพ์เส้นทางที่จะถูกใช้ รวมถึงอุปกรณ์และที่อยู่ต้นทางที่เลือก และมันเคารพกฎนโยบาย ที่อยู่ต้นทางที่เป็นของอัปลิงก์ผิดเป็นสัญญาณปกติว่ากฎตรงก่อนที่คุณจะคาด

เงื่อนไขข้อสาม: ตัดสินว่าใครเป็นเจ้าของความคงทน

เส้นทางที่เพิ่มด้วย ip -6 route add จะอยู่จนรีบูตหรือจนมีสิ่งใดล้างมัน ดีฟอลต์ที่เรียนรู้จากประกาศของเราเตอร์มีอายุและเราเตอร์ถอนคืนได้ ส่วนดีฟอลต์ที่เพิ่มด้วยมือไม่เคยหมดอายุเอง การผสมทั้งสองในตารางเดียวคือวิธีที่เส้นทางถาวรที่ล้าสมัยขึ้นมาเหนือกว่าเส้นทางที่เพิ่งประกาศใหม่ แม้เวลาจะผ่านไปนานหลังจากอัปลิงก์ที่มันบรรยายไว้ไม่มีอยู่แล้ว

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

บนเราเตอร์ที่ส่งต่อให้โฮสต์อื่น ก่อนโทษตาราง ให้ตรวจสอบ net.ipv6.conf.all.forwarding ก่อน เมื่อปิดการส่งต่อ แพ็กเก็ตที่ส่งไปยังเครือข่ายอื่นจะถูกทิ้งไม่ว่าตาราง 201 จะถูกต้องเพียงใด

บันทึกการออกแบบไว้ให้คนถัดไปตรวจสอบได้

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

ก่อนจะบอกว่าตารางเสร็จแล้ว ให้ยืนยันเพื่อนบ้านด้วย ip -6 neigh show dev uplink0 แล้วอ่าน ip -6 rule show อีกครั้งเพื่อดูอุบัติเหตุด้านลำดับ และทดสอบด้วยทราฟฟิกที่ตรงกับกฎแทน ping ที่ใช้เส้นทางดีฟอลต์ จากนั้นปิดอัปลิงก์หนึ่งเส้นโดยตั้งใจและดูว่าเคอร์เนลถอยไปยังเส้นทางใด คำตอบควรตรงกับที่คุณบันทึกไว้