การมอบหมายคำนำหน้า IPv6 ข้าม VPN แบบไซต์ทูไซต์: รายการตรวจสอบ

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

เขียนแผนที่คำนำหน้าก่อนจะแตะทันเนล

การมอบหมายคำนำหน้ามอบบล็อกให้เราเตอร์ที่ร้องขอ มันไม่ได้ติดตั้งเส้นทางบนเพียร์ ไม่ได้ขยายบล็อกนั้นแบบ on-link และไม่ได้บอกเกตเวย์ปลายทางว่ามีอะไรอยู่หลังเราเตอร์ที่ร้องขอ สามสิ่งนี้คุณต้องกำหนดค่าเอง และควรอยู่ในแผนที่อยู่ก่อนที่ไฟล์กำหนดค่าใดจะเปลี่ยน

สำหรับแต่ละไซต์ ให้บันทึกคำนำหน้าที่ได้รับมอบหมาย /64 ที่ใช้จริงบน LAN ที่อยู่ของทันเนล และเจ้าของทุกเส้นทาง ผู้ให้บริการมอบหมาย 2001:db8:a1::/56 ให้ไซต์ A ซึ่งให้บริการ 2001:db8:a1:10::/64 บน LAN ของตน ส่วนไซต์ B เก็บ 2001:db8:b2::/64 ไว้ หากไซต์ A ให้บริการเพียง /64 เดียวนั้น ปลายทั้งสองควรระบุ 2001:db8:a1:10::/64 ไม่ใช่ทั้ง /56

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

จับคู่ตัวเลือกทราฟฟิกของปลายทั้งสองกับเส้นทาง

ทั้ง IKEv2 และ WireGuard ต่างปฏิเสธทราฟฟิกที่ไม่ตรงกัน เงียบพอที่ทันเนลจะยังดูปกติ

ใน strongSwan ตัวเลือกถูกระบุอย่างชัดเจน ที่ไซต์ A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

conn ของไซต์ B สะท้อนทั้งสองซับเน็ต เมื่อไม่ตรงกัน ผู้ตอบจะปฏิเสธ CHILD_SA ด้วย TS_UNACCEPTABLE ดังนั้น child SA จึงไม่ขึ้นเลยแม้ IKE_SA จะขึ้นแล้ว ทั้งสองฝั่งซับเน็ตที่กำหนดค่าต้องเท่ากับสิ่งที่เคอร์เนลโลคัลกำหนดเส้นทางไปยังทันเนล

WireGuard พาข้อมูลเดียวกันใน AllowedIPs โดยมีจุดพลิกหนึ่งอย่าง: AllowedIPs เป็นตัวกรองต้นทางเมื่อรับและเป็นเส้นทางเมื่อส่ง หากรายการ peer ของไซต์ B สำหรับไซต์ A ละเว้น 2001:db8:a1:10::/64 แพ็กเก็ตจากไซต์ A จะมาถึงด้วย handshake ที่ถูกต้องและถูกทิ้งว่าไม่อนุญาต ทำให้เกิดรูปแบบที่คุ้นเคยคือ handshake ต่ออายุซ้ำ ๆ แต่ไม่มีการตอบกลับออกไปเลย เปรียบเทียบปลายทั้งสองด้วย wg show wg0 allowed-ips ตรวจรายการนั้นใหม่ทุกครั้งที่การมอบหมายเปลี่ยน /64 ที่ค้างอยู่ทำให้เซสชันยังมีชีวิตและคำนำหน้าใหม่เข้าถึงไม่ได้

ตัดการส่งต่อ ไฟร์วอลล์ และ MTU ออกก่อน

ก่อนอ่านบรรทัดล็อกถัดไป ให้ยืนยันว่าเกตเวย์ส่งต่อจริงหรือไม่ sysctl net.ipv6.conf.all.forwarding ต้องคืนค่า 1 ทั้งสองเครื่อง และใช้กับอินเทอร์เฟซของทันเนลและ LAN ด้วย มีกับดักหนึ่งอย่าง: เมื่อเปิดการส่งต่อ อินเทอร์เฟซที่ accept_ra=1 จะหยุดรับประกาศเราเตอร์จากผู้ให้บริการ เครื่องจึงอาจสูญเสียเส้นทางเริ่มต้นต้นน้ำแม้กำหนดเส้นทางภายในทันเนลได้อย่างสมบูรณ์ ตั้ง accept_ra=2 ในที่ที่ยังต้องใช้ RA ของผู้ให้บริการ

จากนั้นกฎไฟร์วอลล์ต้องอนุญาตคำนำหน้าในทั้งสองทิศทาง และ ICMPv6 ต้องอยู่รอด: การค้นหาเพื่อนบ้าน packet-too-big และ destination-unreachable ไม่ใช่ตัวเลือกเสริม หากทิ้งสิ่งเหล่านี้ การค้นหา MTU ของเส้นทางจะพัง และได้การเชื่อมต่อที่เปิดแล้วหยุดที่การตอบกลับขนาดใหญ่ครั้งแรก กฎขั้นต่ำหนึ่งคู่มีลักษณะดังนี้:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU อยู่เบื้องหลังเรื่องนี้ ทันเนลลด MTU ที่ใช้ได้ให้ต่ำกว่า 1500 และ IPv6 กำหนดให้ทุกลิงก์ส่งได้อย่างน้อย 1280 ping ขนาดเล็กผ่านได้ เซสชัน SSH แข็งตัวเมื่อมีข้อมูลก้อนใหญ่ และ /proc/net/snmp6 แสดงข้อความ packet-too-big ที่ไม่เคยกลับมา ตั้ง MTU ของทันเนลอย่างชัดเจน หรือจำกัด TCP MSS ในตาราง mangle และปล่อยให้ ICMPv6 ที่แจ้ง MTU ที่เล็กกว่ากลับมา

ทดสอบเส้นทางกลับ ไม่ใช่ที่อยู่ของทันเนล

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

สองคำสั่งจัดการส่วนใหญ่ได้ ที่ไซต์ A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 แสดงว่าการตอบกลับจากต้นทางนั้นจะใช้อินเทอร์เฟซใด ให้ทำการตรวจแบบกระจกที่ไซต์ B จากนั้นสร้างทราฟฟิกจากโฮสต์ไม่ใช่จากเกตเวย์ และเปรียบเทียบตัวนับที่ปลายทั้งสอง

หากการร้องขอเพื่อนบ้านสำหรับคำนำหน้าปลายทางปรากฏบนทันเนล แสดงว่า คำนำหน้านั้นเป็น on-link ในที่ที่ไม่ควรเป็น ให้แก้ก่อนปรับเส้นทาง Proxy NDP ครอบคลุมกรณีที่จำเป็นต้องบริดจ์จริง ไม่ใช่ตัวแทนของเส้นทาง

วางแผนรับมือการเปลี่ยนคำนำหน้าใต้เท้าคุณ

การมอบหมายคำนำหน้าเป็นการเช่าระหว่างเราเตอร์ที่มอบหมายและผู้ร้องขอ และการต่ออายุอาจคืนบล็อกอื่น: /56 อื่นหลังการย้ายผู้ให้บริการ หรือสัญญาเช่าที่สั้นกว่าอายุของทันเนล ทุกที่ที่ระบุคำนำหน้าเดิมจะล้าสมัยพร้อมกัน: เส้นทาง ตัวเลือก AllowedIPs กฎไฟร์วอลล์ บันทึก DNS และการตรวจสอบใด ๆ ที่ฝังที่อยู่ตามตัวอักษร กระแสข้อความอยู่ใน RFC 8415

ในที่ที่คาดว่าคำนำหน้าจะเคลื่อนย้าย ให้คงแผนที่อยู่ภายในที่ไม่ขึ้นกับมันและแปลที่ชายขอบ NPTv6 เป็นตัวเลือกแบบไม่มีสถานะและทำให้นโยบายภายในอ่านได้ แต่เป็นการแปลคำนำหน้า ไม่ใช่ชั้นวิเศษ: ขอบเขต /64 ต้องตรงกัน มีการปรับ checksum และแอปพลิเคชันที่ฝังที่อยู่ตามตัวอักษรยังคงพัง หากคงที่อยู่ของผู้ให้บริการไว้ตลอด ให้บันทึกพฤติกรรมการเช่าและขั้นตอนการเปลี่ยนแปลงไว้ในแผนที่อยู่

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