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

จุดตรวจที่หนึ่ง: การเชื่อมต่อที่ทำงานอยู่แล้ว

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

จดบันทึกพูล โทโพโลยี และเส้นทางที่ถูกดันซึ่งคุณพึ่งพาอยู่แล้ว งาน IPv6 ขยายการตั้งค่านั้น ไม่ได้แทนที่

จุดตรวจที่สอง: เลือกคำนำหน้าภายใน

เลือก ULA /48 สำหรับไซต์และตัด /64 สองอันออกมา หนึ่งสำหรับไคลเอนต์อุโมงค์ หนึ่งสำหรับเซกเมนต์ LAN ที่มีเวิร์กโหลด IPv6 สร้าง ID ทั่วโลก 40 บิตแทนการคัดลอกคำนำหน้าตัวอย่าง และตรวจซับเน็ตทั้งสองกับทุกเครือข่ายที่ไซต์กำหนดเส้นทางอยู่แล้ว:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

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

จุดตรวจที่สาม: เพิ่มตัวช่วยและการดันเส้นทาง

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

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

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

ตัวช่วยไม่อยู่ร่วมกับพูล IPv6 แบบคงที่หรือกับ nopool. หากการติดตั้งจงใจกำหนดที่อยู่แบบคงที่ ให้คงนโยบายนั้นและออกแบบสิ่งที่เทียบเท่า IPv6 อย่างชัดเจน แทนการลบนโยบายเพื่อให้เข้ากับตัวอย่าง

จุดตรวจที่สี่: การส่งต่อและเส้นทางตอบกลับ

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

sysctl -w net.ipv6.conf.all.forwarding=1

การส่งต่อเปลี่ยนพฤติกรรม IPv6 ของโฮสต์เกินกว่าการกำหนดเส้นทางแพ็กเก็ต โฮสต์ที่ยอมรับประกาศเราเตอร์ในฐานะไคลเอนต์จะหยุดทำเช่นนั้นในลักษณะเดียวกันเมื่อเริ่มส่งต่อ เครื่องที่ลิงก์ขึ้น IPv6 พึ่งพา RA จึง ต้องมีแผนชัดเจนสำหรับลิงก์นั้น.

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

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

รักษาประเภท ICMPv6 ที่ลิงก์ต้องการ รวมถึงผลตอบกลับ MTU ของเส้นทาง กฎไฟร์วอลล์ IPv4 ไม่ได้หมายถึงกฎ IPv6 และการบล็อก IPv6 ทั้งหมดจะทำให้การค้นหาเพื่อนบ้านเสียในแบบที่ดูเหมือนความผิดพลาดของการกำหนดเส้นทาง

จุดตรวจที่ห้า: อ่านไคลเอนต์ แล้วจึงทดสอบ

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

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

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

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

เผยแพร่ระเบียน AAAA เมื่อเส้นทาง IPv6 ตอบกลับตั้งแต่ต้นจนจบเท่านั้น DNS ที่ถามผ่าน IPv4 ยังคืนที่อยู่ IPv6 ได้ ชื่อที่แปลงได้จึงไม่ใช่หลักฐานว่ามีสิ่งใดกำลังฟังอยู่ แนวทาง RFC 4193 สำหรับ ULA ครอบคลุมการสร้าง ID ทั่วโลกที่ทำให้คำนำหน้าเหล่านี้เป็นของคุณ ไม่ใช่สำเนา

บทความที่เกี่ยวข้อง