IPv6 ผ่านเซิร์ฟเวอร์ VPN แบบ IPv4 ยังต้องมีทางออก IPv6 จริง

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

อาการ: มีที่อยู่แต่ไม่มีเส้นทาง

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

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

ติดตามแพ็กเก็ตหลังการถอดการห่อหุ้ม

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

กลไกการห่อหุ้ม IPv6 บน IPv4 อธิบายไว้ใน RFC 4213 และรายละเอียดสำคัญตรงนั้นคือปลายทั้งสองยังต้องมีการเชื่อมต่อ IPv6 จริงอีกด้านของอุโมงค์ การห่อหัวเรื่องไม่ได้เสก upstream ขึ้นมา

สองชั้นอุโมงค์ สองการตรวจที่เป็นอิสระ

ตรวจแต่ละชั้นแยกกัน เพราะอุโมงค์ชั้นนอกที่ทำงานได้ซ่อนชั้นในที่เสียไว้ ตรวจเส้นทางชั้นนอกด้วย ping IPv4 จากไคลเอนต์ไปยังเซิร์ฟเวอร์ และยืนยันพอร์ตที่คุณใช้ จากนั้นตรวจเส้นทางชั้นในบนเซิร์ฟเวอร์ ซึ่ง ip -6 route ต้องแสดงเส้นทางเริ่มต้นหรือเส้นทางเฉพาะที่เรียนรู้จาก upstream จริง และ ip -6 addr ต้องแสดงคำนำหน้าต้นทางที่ upstream ยอมรับ อะไรที่น้อยกว่านั้นเป็นเพียงการประดับบนอินเทอร์เฟซ

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

เช่นเดียวกันกับไคลเอนต์: ip -6 route get 2001:4860:4860::8888 ควรระบุอุปกรณ์อุโมงค์ และถ้าระบุอุปกรณ์จริง ไคลเอนต์ก็ไม่ได้ใช้ VPN สำหรับ IPv6 เลย

คำนำหน้าต้นทาง ขนาด และ ICMPv6

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

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

อะไรคือปัญหาที่ต่างออกไปโดยสิ้นเชิง

การเข้าถึงแอปพลิเคชันที่เป็น IPv4 เท่านั้นจากไคลเอนต์ที่เป็น IPv6 เท่านั้นคือการแปล ไม่ใช่การทำอุโมงค์ และต้องมีอะไรอย่างการติดตั้ง NAT64 อย่างตั้งใจ ปลายทางจะไม่เข้าใจหัวเรื่องอุโมงค์เพิ่มเติมเพียงเพราะคุณเพิ่มเข้าไป บริการเปลี่ยนผ่านในอดีตสมควรได้รับการดูแลแบบเดียวกัน: RFC 7526 ยกเลิกรูปแบบรีเลย์ anycast 6to4 ดังนั้นคู่มือที่เขียนขึ้นรอบ ๆ จึงอธิบายสิ่งที่ไม่มีรีเลย์สาธารณะที่ดูแลอยู่แล้ว

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