ทำไมคำตอบ DNS64 จึงเปลี่ยนทันทีที่ VPN เชื่อมต่อ

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

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

ระเบียน AAAA ที่สังเคราะห์ขึ้นชี้ไปที่อะไรกันแน่

resolver ของ DNS64 ตอบคำถาม AAAA สำหรับชื่อที่มีเพียง IPv4 โดยฝังที่อยู่ IPv4 ไว้ในคำนำหน้าที่ตั้งค่าให้ใช้ และคำนำหน้าที่รู้จักกันดีสำหรับงานนี้คือ 64:ff9b::/96 ตามที่อธิบายใน RFC 6147 ระเบียนดูเหมือนระเบียน AAAA อื่นใดสำหรับแอปพลิเคชัน และนั่นคือประเด็น: ไคลเอนต์ที่มีเพียง IPv6 สามารถลองเชื่อมต่อได้โดยไม่รู้ว่าปลายทางไม่เคยมี IPv6 มาก่อน การเชื่อมต่อนั้นจึงขึ้นอยู่กับฟังก์ชัน NAT64 ที่แปลระหว่างสองตระกูลที่ใดที่หนึ่งบนเส้นทาง หากไม่มีตัวแปลนั้น ที่อยู่ที่สังเคราะห์ขึ้นก็เป็นปลายทางที่ดูน่าเชื่อถือแต่ไปไม่ถึงไหน

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

เงื่อนไขสามข้อตัดสินว่ายังใช้งานได้หรือไม่

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

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

เมื่อ resolver เปลี่ยน คำตอบก็เปลี่ยน

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

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

ทดสอบการค้นหาและเส้นทางแยกกัน

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

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

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

บันทึก resolver บริบทเครือข่าย และตระกูลที่อยู่ไว้ข้างผลลัพธ์แต่ละรายการ บันทึกนั้นเองที่ทำให้การเปรียบเทียบครั้งต่อไปแยกการเปลี่ยน resolver ออกจากการเปลี่ยนเส้นทางได้