ping ไปยังปลายอีกด้านของอุโมงค์ IPv6 ล้มเหลว? ตรวจสอบที่อยู่ ::

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

อาการที่ชี้ไปที่ที่อยู่

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

ตัวระบุที่เป็นศูนย์ทั้งหมดถูกสงวนไว้เป็น anycast

RFC 4291 เก็บตัวระบุอินเทอร์เฟซที่เป็นศูนย์ทั้งหมดไว้เป็นที่อยู่ subnet-router anycast ดังนั้น /64 อย่าง 2001:db8:4a::/64 จึงไม่มีโฮสต์ที่ใช้งานได้ที่ 2001:db8:4a:: การสงวนนี้มีเหตุผล เพราะ router advertisements และ neighbour discovery ส่งถึงรูปแบบนั้น และเราเตอร์ตอบแทนคำนำหน้าที่มันให้บริการ การกำหนดค่านั้นให้ปลายอุโมงค์เท่ากับมอบบทบาทเราเตอร์ให้ใบไม้ ซึ่งเป็นเหตุผลที่ไม่มีอะไรกลับมา ตัวระบุอื่นใดในคำนำหน้าก็ใช้เป็นโฮสต์ได้ ดังนั้นการแก้ไขมักใช้เพียงหนึ่งหลัก

มองการสงวนนี้เป็นบทบาทที่คุณไม่มีสิทธิ์ครองจากปลายอุโมงค์ ไม่ใช่ความแปลกประหลาดที่ต้องหลบด้วยเส้นทาง

กำหนดที่อยู่โฮสต์และกำหนดเส้นทางคำนำหน้า

เลือก ::1 และ ::2 สำหรับปลายทั้งสอง เพิ่มอีกตัวด้วย ip -6 addr add 2001:db8:4a::2/64 dev tun0 แล้วกำหนดเส้นทางคำนำหน้าปลายไกล แทนที่จะพยายามกำหนดที่อยู่ให้มัน เส้นทางสำหรับ 2001:db8:4a::/64 ออกจากอุโมงค์ทำให้ปลายไกลเข้าถึงได้ ที่อยู่เพียงอย่างเดียวแค่ทำให้อินเทอร์เฟซท้องถิ่นถูกกำหนดค่า

สำหรับอุโมงค์แบบเต็มมีขั้นที่สาม คือเส้นทางเริ่มต้นสำหรับ unicast ทั่วโลกผ่านอุปกรณ์ ซึ่งเทียบเท่า IPv6 ของการส่งทุกอย่างเข้าไปในอุโมงค์ ถ้าข้ามขั้นนี้ IPv6 จะยังใช้อินเทอร์เฟซจริงขณะที่ IPv4 เดินทางในอุโมงค์ ดังนั้นโฮสต์จะรั่วไหลข้อมูลที่คุณเชื่อว่าถูกครอบคลุมไว้พอดี ยืนยันด้วย ip -6 route get 2001:4860:4860::8888 และอ่านว่ามันระบุอุปกรณ์ใด แทนที่จะเดาคำตอบ

multicast ถูกปฏิเสธก่อนการกำหนดเส้นทาง

Android ตรวจสอบที่อยู่และเส้นทางสำหรับ VpnService.Builder ผ่าน LinkAddress และตัวสร้างนั้นปฏิเสธ multicast โดยตรง ถ้าให้คำนำหน้า multicast เป็นเส้นทาง ผลลัพธ์คือความล้มเหลว bad LinkAddress parameters ไม่ใช่เส้นทาง ซึ่งเป็นคำตอบของการตรวจสอบไม่ใช่ของเครือข่าย การปฏิเสธสอดคล้องกับสื่อ อุปกรณ์ tun แบบจุดต่อจุดไม่มี multicast ระดับชั้นลิงก์ ดังนั้นเส้นทางกลุ่มบนอุปกรณ์นั้นจึงไม่มีรูปแบบการส่งมอบให้ติดตั้ง ที่อยู่กลุ่มถูกสร้างและใช้โดยสแตกเอง ไม่ได้กำหนดด้วยมือ

ที่อยู่ IPv6 all-nodes และ solicited-node อยู่ภายใต้กฎเดียวกัน อินเทอร์เฟซมีที่อยู่เหล่านั้นเพราะสแตกใส่มันไว้ ไม่ใช่เพราะนโยบายใดตั้งใจ

สิ่งที่อุโมงค์นำส่งได้แทน

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

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

การตรวจสามข้อก่อนกำหนดสิ่งใด

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

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