ทำไมการค้นหาเพื่อนบ้าน IPv6 จึงล้มเหลวผ่าน VPN แบบกำหนดเส้นทาง

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

ขอบเขตมาก่อนการกำหนดค่า

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

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

กับดักคือสมมติฐานที่ว่าคำนำหน้าอยู่บนลิงก์

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

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

การบริดจ์เปลี่ยนกฎอย่างตั้งใจ

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

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

ทดสอบด้วยที่อยู่ที่แอปพลิเคชันใช้

ยืนยันเส้นทางด้วย ip -6 route get ตรวจดูรายการเพื่อนบ้านด้วย ip -6 neigh จากนั้น ยืนยันบริการบนเส้นทางที่กำหนด DNS และเส้นทางขากลับเป็นการตรวจแยกกัน และรายการเพื่อนบ้านที่สมบูรณ์ไม่พิสูจน์ทั้งสองอย่าง

หากแอปพลิเคชันยืนยันปลายทางเฉพาะลิงก์หรืออิงการค้นหา นั่นคือบทสนทนาเรื่องการออกแบบไม่ใช่การฝึกปรับแต่ง เพราะไม่มีการตั้งค่าไคลเอนต์ใดทำให้กลไกที่จำกัดเฉพาะลิงก์ทำงานข้ามเราเตอร์ได้

จดบันทึกว่าคุณมีการออกแบบใด

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

การอ่านชุดข้อความครั้งเดียวขจัดสิ่งล่อใจที่จะอธิบายคุณสมบัติขอบเขตของลิงก์ว่าเป็นข้อบกพร่องของ VPN ซึ่งเป็นการวินิจฉัยผิดที่แพงที่สุดในสาขานี้