การแบ่ง /64 ของคุณไม่ได้ทำให้ IPv6 ไปถึงไคลเอนต์ VPN

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

ความเชื่อผิด: ส่วนหนึ่งของ /64 ของคุณเข้าถึงได้อยู่แล้ว

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

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

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

การส่งมอบบนลิงก์ต้องการอะไรจริง ๆ

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

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

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

การส่งมอบแบบกำหนดเส้นทางต้องการอะไร

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

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

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

สองเส้นทางที่เป็นอิสระต่อกันที่ต้องทำให้ถูกต้อง

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

รักษาทราฟฟิกควบคุมที่ IPv6 ต้องพึ่งพาให้ทำงานภายใต้นโยบายใดก็ตามที่คุณใช้ ข้อความ Packet Too Big เป็นเหยื่อคลาสสิกของไฟร์วอลล์ที่อนุญาตเฉพาะ TCP และ UDP และการทิ้งข้อความเหล่านั้นทำให้เกิดการเชื่อมต่อที่สร้างขึ้นแล้วหยุดชะงักในการถ่ายโอนขนาดใหญ่

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

บันทึกการออกแบบไว้เพื่อให้การสร้างใหม่ทำซ้ำได้

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

จากนั้นทดสอบทิศทางกลับอย่างชัดเจนด้วยแพ็กเก็ตที่ต้องกลับมาจากภายนอก คู่มือ openvpn(8) ครอบคลุมตัวเลือก server-ipv6 และ redirect และการยืนยันเส้นทางจากผู้ให้บริการของคุณครอบคลุมครึ่งที่คู่มือทำไม่ได้