ทราฟฟิก IPv6 ที่ลอดนอก VPN: หาเส้นทางที่รั่ว

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

ทำงานตามลำดับนั้น การตอบผิดลำดับจะกลายเป็นการโต้เถียงยาวว่าอุโมงค์เสียหรือไม่ ทั้งที่คำตอบจริงคือไม่เคยมีการติดตั้งเส้นทาง IPv6 เลย

การไหลใดออกไปจริง และบนอะแดปเตอร์ใด

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

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

การอ่านเส้นทางที่เคอร์เนลเลือก

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

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

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

นโยบาย IPv6 ของไคลเอนต์มาจากไหน

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

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

การสังเกตแบบแคบ เมื่อตารางขัดกัน

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

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

สามวิธีปิดช่องโหว่

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

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