IPv4 เข้าเว็บได้ แต่ทำไมบางเครือข่ายยังเข้าไม่ได้

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

เมื่อชื่อบริการมีทั้ง A สำหรับ IPv4 และ AAAA สำหรับ IPv6 เรากำลังประกาศที่อยู่คนละชุดให้ผู้ใช้เลือกใช้ ที่อยู่ทั้งสองจึงต้องพาไปยังบริการที่พร้อมจริง ไม่ใช่ตั้ง AAAA ไว้แล้วถือว่า IPv4 ที่ตรวจผ่านจะรับรองอีกทางด้วย

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

A กับ AAAA ไม่ได้ตรวจความพร้อมให้กัน

DNS บอกที่อยู่ตาม record ที่ตั้งไว้ แต่ไม่ได้รับรองว่าเครื่องปลายทางมี listener เปิดอยู่ port นั้น หรือ firewall อนุญาต traffic ไปถึง การมี AAAA ที่รูปแบบถูกจึงยังอาจพาไป IPv6 address ที่ไม่มีบริการรอรับ

หากใช้ load balancer หรือ proxy ที่อยู่สองชุดก็อาจเข้าคนละ frontend โดยไม่ได้ตั้งใจ ตัวหนึ่งอาจโหลด certificate ใหม่แล้ว แต่อีกตัวยังใช้ config เก่า ปัญหาที่ผู้ใช้เห็นจึงขึ้นกับทางที่มาถึง แม้ backend application จะใช้ชุดเดียวกันก็ตาม

ในระบบที่อยู่ผ่านผู้ให้บริการภายนอก ควรตรวจว่าสัญญาการให้บริการครอบคลุม IPv6 ที่ชั้นใดด้วย เช่น client ถึง edge รองรับสองแบบ แต่ edge ติดต่อ origin อีกแบบหนึ่ง อย่าเอาที่อยู่ของ origin ไปเติมเป็น AAAA ของ public hostname โดยยังไม่เข้าใจทางที่ออกแบบไว้

Client บางตัวลองหลายทาง แต่ไม่ใช่ใบรับรองว่าทุกทางดี

กลไกอย่าง Happy Eyeballs ช่วยลดเวลารอเมื่อมีหลาย address family โดยจัดการการค้นชื่อและพยายามเชื่อมต่ออย่างเหมาะสมตาม implementation จุดประสงค์คือให้คนใช้เชื่อมต่อได้โดยไม่ติดรอเส้นทางที่มีปัญหานานเกินไป

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

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

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

บังคับทางในการตรวจโดยรักษาชื่อบริการเดิม

เครื่องมืออย่าง curl มีตัวเลือก -4 และ -6 เพื่อจำกัดการ resolve hostname ให้ address family ที่ต้องการ จึงใช้เป็นส่วนหนึ่งของการเทียบเส้นทางได้เมื่อเครื่องและเครือข่ายที่ตรวจรองรับทางนั้นจริง

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

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

curl -4 -I https://service.example/
curl -6 -I https://service.example/

การใช้ -I ส่งคำขอ HEAD จึงต้องดูว่าบริการรองรับวิธีนี้หรือไม่ หากเส้นทางใช้งานจริงเป็น GET หรือมีการยืนยันตัวตน ก็ต้องมีการตรวจตามสัญญานั้นเพิ่มเติม ไม่ตัดสินว่าแอปเสียจาก HEAD ที่ endpoint ไม่รองรับเพียงอย่างเดียว

ควรคง hostname เดิมใน URL เพื่อให้การตรวจ TLS กับการเลือกเว็บเสมือนยังอ้างบริการที่ตั้งใจ หากจำเป็นต้องระบุ IP สำหรับทดสอบปลายทางเฉพาะ ค่อยใช้วิธีอย่าง --resolve ตามรูปแบบ host และ port ที่เครื่องมือกำหนด แทนการเปลี่ยน URL เป็น IP แล้วปิดตรวจ certificate เพื่อให้ผ่าน

อ่านว่าไม่ผ่านชั้นใดก่อนแก้

ถ้าไม่พบ AAAA ต้องตรวจข้อมูล DNS กับ resolver ที่ใช้อยู่ก่อน แต่ถ้าพบที่อยู่แล้วเชื่อม TCP ไม่ได้ ก็ต้องตาม route listener และกติกาเครือข่ายของทางนั้น การตอบชื่อสำเร็จไม่ได้ยืนยันว่า port ปลายทางเปิด

หากเชื่อมได้แต่ TLS ไม่ผ่าน ให้เก็บชื่อที่ตรวจ certificate และจุดที่เชื่อมจริงด้วย อาจเป็น certificate คนละฉบับหรือ chain คนละชุด ไม่ใช่เหตุให้ปิดการตรวจ TLS ของ client ทั้งระบบ

เมื่อผ่าน TLS แล้วได้ HTTP ผิด เช่น redirect ไปชื่อเก่าหรือหน้า default ของ proxy ต้องกลับไปดู virtual host กับแอปที่ตอบ การที่ IP นั้นมีบริการ HTTPS ใดบริการหนึ่งอยู่ยังไม่เท่ากับมันให้บริการชื่อที่เราประกาศครบแล้ว

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

เตรียมสองทางให้มีสัญญาบริการเดียวกัน

การแก้ไม่จำเป็นต้องเริ่มจากลบ AAAA เสมอไป ควรหาว่าที่อยู่ผิด บริการไม่ฟังบน IPv6 หรือ firewall ของสอง family มีเงื่อนไขต่างกัน แล้วแก้ตามต้นเหตุโดยคงขอบเขตการเปิดบริการที่ตั้งใจไว้

ถ้าระบบยังไม่พร้อมให้บริการทางหนึ่งจริง ต้องวางการเปลี่ยน DNS อย่างมีแผนร่วมกับอายุ cache และผู้ใช้ที่ได้รับที่อยู่ไปแล้ว การลบ record ไม่ได้ดึงคำตอบเก่ากลับจากทุก resolver ทันที จึงยังต้องติดตามเส้นทางนั้นในช่วงเปลี่ยนด้วย

สำหรับชุดตรวจประจำ ควรเก็บ address family ปลายทางที่ตอบ ผล TLS และผล HTTP แยกกัน พร้อมระบุจุดที่ตรวจ ไม่รวมค่าเฉลี่ยทุกทางจนมองไม่เห็นว่า IPv6 ไม่ผ่านทั้งหมดแต่ IPv4 ยังดีอยู่ การแยกนี้ยังช่วยให้รู้ว่าการแก้ครั้งถัดไปเปลี่ยนเฉพาะชั้นใด

การรองรับ dual stack เริ่มจากการประกาศที่อยู่ แต่จบที่ผู้ใช้ผ่านแต่ละเส้นทางไปถึงบริการที่ถูกต้องได้ เมื่อแยก DNS การเชื่อมต่อ TLS และ HTTP ของ IPv4 กับ IPv6 เราจะมองเห็นปัญหาที่ fallback อาจบังไว้ และแก้ตรงจุดโดยยังรักษาการตรวจตัวตนของบริการครบตามชื่อที่ผู้ใช้เรียก