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

เดินตามห้าขั้นตอนเดียวกับที่แพ็กเก็ตเดิน

ขั้นที่ 1: ดูการค้นหาชื่อ

หากโปรไฟล์ใช้ชื่อโฮสต์ คำถามแรกคือรีโซลเวอร์คืนค่าอะไร dig AAAA vpn.example.com บนเครือข่าย IPv6 เท่านั้นคืนระเบียน AAAA จริง ระเบียนที่สังเคราะห์จาก DNS64 หรือไม่คืนอะไรเลย คำตอบที่สังเคราะห์จะเข้ารหัสปลายทาง IPv4 ไว้ในคำนำหน้าการแปล และเมื่อนั้นไคลเอนต์ที่ไม่มีปลายทาง IPv6 จึงเข้าถึงได้ โปรไฟล์ที่ฝังที่อยู่ IPv4 แบบตายตัวจะไปไม่ถึงจุดนี้ เพราะไม่มีชื่อให้สังเคราะห์

ความต่างเพียงข้อเดียวนี้อธิบายรายงาน ‘ทำงานได้ที่นั่น ล้มเหลวที่นี่’ ส่วนใหญ่ และใช้คำสั่งเดียวก็เห็นได้

ขั้นที่ 2: ดูว่าไคลเอนต์เรียกตระกูลใด

ดูที่ซ็อกเก็ตแทนแถบความคืบหน้า ไคลเอนต์ที่เปิดซ็อกเก็ต IPv4 ไปยังที่อยู่ IPv4 บนลิงก์ที่มีเฉพาะ IPv6 ไม่มีที่ให้ส่ง และความล้มเหลวปรากฏเป็นหมดเวลา ไม่ใช่ข้อผิดพลาดของชื่อ ss -tanp ขณะไคลเอนต์เชื่อมต่อจะแสดงที่อยู่ปลายทางและตระกูลที่มันลอง เปรียบเทียบกับ ip -6 route เพื่อยืนยันว่าเส้นทางเริ่มต้นเป็นฮ็อปถัดไป IPv6 จริง

ตระกูลที่อยู่ในตารางซ็อกเก็ตคือข้อเท็จจริง แถบความคืบหน้าเป็นบทสรุปที่คนอื่นเขียน

ขั้นที่ 3: แยกการแปลออกจากอุโมงค์

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

การแปลล้มเหลวดูเหมือนไม่เคยเชื่อมต่อ การครอบคลุมภายในล้มเหลวดูเหมือนเชื่อมต่อแต่ไปไม่ถึงอะไร

ขั้นที่ 4: ทดสอบโปรไฟล์เดียวกันบนเครือข่ายอื่น

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

รายงานที่บอกว่า VPN เสียใช้การไม่ได้ รายงานที่บอกว่าล้มเหลวเฉพาะการเข้าถึง IPv6 เท่านั้นคือรายงานบั๊ก

ขั้นที่ 5: แก้เส้นทาง ไม่ใช่การตั้งค่าความปลอดภัย

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

ตัวเลือกจริงคือไคลเอนต์ที่รองรับรูปแบบการแปลเครือข่าย หรือปลายทางที่มีที่อยู่ IPv6 ที่เข้าถึงได้ ขอสักอย่างหนึ่ง

บทความที่เกี่ยวข้อง