ที่อยู่ IPv6 แบบสาธารณะไม่ได้หมายความว่าทราฟฟิกเลี่ยงอุโมงค์

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

ขอบเขตกับบทบาทเป็นคำถามต่างกันด้วยหลักฐานต่างกัน

ขอบเขตตอบว่าใครเราเตอร์ได้ ไม่ใช่ใครทำ

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

ที่อยู่หนึ่งสามารถมีขอบเขตสาธารณะและยังถูกบรรทุกภายในอุโมงค์ได้ เพราะอุโมงค์เป็นเส้นทาง ไม่ใช่แผนที่อยู่

อ่านที่อยู่ทั้งหมดบนอินเทอร์เฟซ ไม่ใช่การทดสอบเว็บ

ผลลัพธ์ของอินเทอร์เฟซแสดงหลายที่อยู่พร้อมกัน: ที่อยู่ภายนอกบนลิงก์กายภาพ ที่อยู่ของอุโมงค์ และที่อยู่เฉพาะลิงก์หนึ่งรายการต่ออินเทอร์เฟซ การทดสอบเว็บแสดงเฉพาะที่อยู่ต้นทางของคำขอเดียว. เริ่มด้วย ip -6 addr show แล้วบันทึกว่าที่อยู่ใดเป็นของอินเทอร์เฟซใดและมีคำนำหน้ายาวเท่าใด จากนั้นถามว่าคำขอใช้อินเทอร์เฟซใดจริง

เปรียบเทียบกับ ip -6 route get 2606:4700::1111 ซึ่งพิมพ์อินเทอร์เฟซและต้นทางที่เคอร์เนลจะเลือกสำหรับปลายทาง

คำนำหน้าสาธารณะเข้าไปอยู่ในอุโมงค์ได้อย่างไร

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

ถามผู้ดูแลระบบว่าอันไหนใช้ได้ คำตอบกำหนดว่าเซิร์ฟเวอร์อีกฝั่งเห็นคุณเป็นต้นทางอย่างไร

ทำไมที่อยู่ที่ดูเป็นส่วนตัวจึงไม่ใช่สัญญาณของความน่าเชื่อถือ

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

ตัดสินความน่าเชื่อถือจากนโยบาย การพิสูจน์ตัวตน และการเข้ารหัส รูปลักษณ์ของที่อยู่เป็นการคาดเดาที่อ่อนแอและล้มเหลวทั้งสองทาง

ทดสอบเส้นทางและนโยบายเป็นสองคำถาม

ข้อแรกเส้นทาง: รัน curl -6 https://ifconfig.me ผ่านอุโมงค์แล้วรันอีกครั้งผ่านอินเทอร์เฟซกายภาพ แล้วเปรียบเทียบคำตอบ ข้อที่สองนโยบาย: ยืนยันว่าอุโมงค์บรรทุกคำนำหน้าใดจริงและอีกฝั่งมีเส้นทางขากลับสำหรับมันหรือไม่ คำขอที่สำเร็จไปยังเว็บไซต์สาธารณะไม่ได้พิสูจน์ทั้งสองอย่าง เพราะปลายทางนั้นเข้าถึงได้จากทุกที่ ใช้ปลายทางภายในสำหรับการทดสอบนโยบาย

บันทึกที่อยู่ต้นทางที่แต่ละเส้นทางสร้างขึ้น นั่นคือหลักฐานที่ข้อกล่าวอ้างเรื่องการเลี่ยงอุโมงค์ต้องการจริง ๆ