บทความ

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

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

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

บทนำ: ทำไมโทรศัพท์ถึงได้รับ IPv6 แต่เว็บไซต์เห็น IPv4

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

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

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

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

สิ่งที่คุณจะได้รู้เมื่ออ่านจนจบ:

  • การขาดแคลนที่อยู่ IPv4 เป็นอย่างไร และทำไมถึงบังคับให้ผู้ให้บริการเปลี่ยนไปใช้ IPv6
  • ประเภทของ APN คืออะไร และ IPv4v6 แตกต่างจาก IPv6 ล้วนๆ อย่างไร
  • 464XLAT ทำงานทีละขั้นตอน CLAT อยู่ที่ไหน PLAT อยู่ที่ไหน
  • NAT64 และ DNS64 ทำให้เว็บไซต์ที่ไม่มีเรกคอร์ด AAAA เข้าถึงได้อย่างไร
  • ที่อยู่ IPv4 ขาออกของมือถือพร็อกซีมาจากไหน
  • Happy eyeballs ทำให้บริการตรวจสอบแสดงทั้ง IPv4 และ IPv6 สลับกันไปมาได้อย่างไร
  • คำสั่งปฏิบัติจริงสำหรับการวินิจฉัยสแต็กการเชื่อมต่อ
  • ทำไม subnet /64 ถึงถูกมองว่าเป็นลูกค้ารายเดียว และมันหมายถึงอะไรสำหรับบัญชีต่างๆ

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

พื้นฐาน: การขาดแคลน IPv4 การเปลี่ยนไปใช้ IPv6 และประเภทของ APN

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

ทำไม IPv4 ถึงหมด

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

ความจริงกลับโหดร้าย สมาร์ทโฟน แท็บเล็ต นาฬิกาอัจฉริยะ ตู้เย็น กล้อง รถยนต์ ทุกอย่างต้องการที่อยู่ ตั้งแต่ต้นทศวรรษ 2010 ผู้ลงทะเบียนอินเทอร์เน็ตในภูมิภาคเริ่มหมดบล็อกว่าง ปัจจุบัน การได้บล็อก IPv4 สีขาวขนาดใหญ่นั้นแทบเป็นไปไม่ได้ และในตลาดรอง ที่อยู่เหล่านี้มีราคาหลายสิบดอลลาร์ต่ออัน

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

IPv6 แก้ปัญหาอย่างไร

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

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

APN คืออะไร และทำไมต้องมีประเภทของมัน

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

มีประเภทหลักๆ ของ PDN หรือ PDP-context อยู่สามแบบ:

  • IPv4 - อุปกรณ์ได้รับเฉพาะที่อยู่ IPv4 รูปแบบคลาสสิกที่ล้าสมัย ใช้งานได้ แต่ต้องการที่อยู่ซึ่งไม่มี
  • IPv6 - อุปกรณ์ได้รับเฉพาะพรีฟิกซ์ IPv6 ไม่มี IPv4 บนอินเทอร์เฟซเลย ประหยัดที่สุดสำหรับผู้ให้บริการ
  • IPv4v6 - dual stack อุปกรณ์ขอที่อยู่ทั้งสองประเภทในเซสชันเดียว

นี่คือจุดที่เกิดความละเอียดอ่อน แม้ว่าโทรศัพท์จะขอ IPv4v6 ผู้ให้บริการอาจแจกเฉพาะส่วน IPv6 และปฏิเสธส่วน IPv4 หรือแจกที่อยู่ส่วนตัวผ่านกลไกการแปล ผู้ให้บริการรายใหญ่หลายรายถูกตั้งค่าให้ลูกค้าได้รับ IPv6 ล้วนๆ โดยค่าเริ่มต้น และความเข้ากันได้กับอินเทอร์เน็ต IPv4 นั้นมาจากเทคโนโลยี 464XLAT ที่อธิบายไปแล้ว

อุปมาที่ช่วยให้เข้าใจ ลองนึกภาพว่าโลกทั้งใบเปลี่ยนมาใช้ภาษาใหม่ในการสื่อสาร แต่หน่วยงานเก่าๆ มากมายยังรับเอกสารเฉพาะภาษาเก่า รัฐไม่สามารถแจกพาสปอร์ตเก่าส่วนตัวให้พลเมืองทุกคนได้ เพราะมีไม่พอ ดังนั้นรัฐจึงแจกเอกสารใหม่ให้ทุกคน และตั้งล่ามไว้ที่ทางเข้าหน่วยงานเก่า ล่ามนั้นก็คือ 464XLAT

เจาะลึก: 464XLAT แยกตามส่วนประกอบ

ตอนนี้เราพร้อมที่จะผ่าเทคโนโลยีนี้แล้ว ชื่อ 464XLAT อ่านว่า four-six-four translation ตัวเลขสะท้อนถึงแก่นแท้: แพ็กเก็ตเริ่มต้นชีวิตเป็น IPv4 ภายในแอปพลิเคชัน เดินทางผ่านเครือข่ายเป็น IPv6 จากนั้นกลายเป็น IPv4 อีกครั้งเมื่อออกไปข้างนอก XLAT ย่อมาจาก translation

พื้นฐานคือมาตรฐานการแปลที่อยู่ระหว่างโปรโตคอลที่อธิบายในข้อกำหนดของ IETF แต่ 464XLAT เพิ่มสถาปัตยกรรมของสององค์ประกอบที่ทำงานเป็นคู่

CLAT - ตัวแปลบนอุปกรณ์

CLAT ย่อมาจาก Customer-side translator นั่นคือตัวแปลฝั่งลูกค้า มันอยู่บนสมาร์ทโฟนของคุณโดยตรง ซึ่งฝังอยู่ในระบบปฏิบัติการ ใน Android ฟังก์ชันนี้ทำโดยเดมอนพิเศษ ในระบบอื่นก็มีโมดูลที่คล้ายกัน

หน้าที่ของ CLAT มีเพียงหนึ่งเดียว แต่สำคัญมาก เมื่อแอปพลิเคชันบนโทรศัพท์ต้องการส่งแพ็กเก็ตผ่าน IPv4 เช่น มันใช้ IPv4 socket อย่างตายตัว หรือเรียกที่อยู่ IP โดยตรง CLAT จะสกัดแพ็กเก็ต IPv4 นั้นและห่อหุ้มไว้ใน IPv6 ในทางเทคนิค มันทำการแปลส่วนหัวตามอัลกอริทึม stateless-translation โดยแปลงที่อยู่ IPv4 ต้นทางและปลายทางเป็นที่อยู่ IPv6 ที่สอดคล้องกันโดยใช้พรีฟิกซ์ที่ทราบล่วงหน้า

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

PLAT - ตัวแปลในเครือข่ายผู้ให้บริการ

PLAT ย่อมาจาก Provider-side translator ตัวแปลฝั่งผู้ให้บริการ มันคือโหนดที่ทรงพลัง somewhere ในแกนเครือข่ายของผู้ให้บริการ ทำหน้าที่ NAT64 ที่นี่เองที่การแปลงครั้งสุดท้ายเกิดขึ้น

PLAT รับแพ็กเก็ต IPv6 ที่มาจากอุปกรณ์ และดึงข้อมูลเกี่ยวกับปลายทาง IPv4 ดั้งเดิมออกมา จากนั้นมันทำ stateful-translation: เปลี่ยนแพ็กเก็ต IPv6 กลับเป็นแพ็กเก็ต IPv4 ใส่ที่อยู่ IPv4 สาธารณะจาก pool ของผู้ให้บริการเป็นที่อยู่ต้นทาง และส่งแพ็กเก็ตไปยังอินเทอร์เน็ต IPv4 ทั่วไป

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

ทำไมต้องมีตัวแปลสองตัว

คำถามที่สมเหตุสมผลคือ: ทำไมต้องมี CLAT บนอุปกรณ์ ในเมื่อ PLAT ก็แปลทุกอย่างอยู่แล้ว? คำตอบคือแอปพลิเคชันที่ไม่รองรับ IPv6

แอปพลิเคชันจำนวนมากถูกเขียนขึ้นโดยใช้ IPv4 อย่างตายตัว พวกมันขอ IPv4 socket ทำงานกับ IPv4 literals ของที่อยู่ บางโปรโตคอลอย่างการใช้งานแบบเก่าส่งที่อยู่ IP ภายใน payload ถ้าบนอุปกรณ์มีแค่ IPv6 ล้วนๆ แอปพลิเคชันเหล่านี้ก็จะพังทันที CLAT ให้ภาพลวงตาของสภาพแวดล้อม IPv4 ที่สมบูรณ์แก่พวกมัน ในขณะที่ยังคงมองไม่เห็น

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

NAT64 และ DNS64: เว็บไซต์ที่ไม่มีเรกคอร์ด AAAA มีชีวิตขึ้นมาได้อย่างไร

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

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

ปัญหาของการไม่มีเรกคอร์ด AAAA

ในระบบชื่อโดเมน ที่อยู่ของโปรโตคอลต่างๆ จะถูกเก็บไว้ในเรกคอร์ดประเภทต่างๆ ที่อยู่ IPv4 เก็บในเรกคอร์ดประเภท A ที่อยู่ IPv6 เก็บในเรกคอร์ดประเภท AAAA ซึ่งออกเสียงว่า quad-A

เมื่ออุปกรณ์ที่ใช้ IPv6 ล้วนๆ ต้องการเปิดเว็บไซต์ มันจะขอเรกคอร์ด AAAA จาก DNS แต่ถ้าเว็บไซต์ไม่มีโครงสร้างพื้นฐาน IPv6 มันก็ไม่มีเรกคอร์ด AAAA มีแต่เรกคอร์ด A ที่มีที่อยู่ IPv4 อุปกรณ์ได้รับคำตอบว่างเปล่า และตามทฤษฎีแล้วควรบอกว่าเว็บไซต์ไม่สามารถเข้าถึงได้ แต่สิ่งนี้ไม่เกิดขึ้นเพราะ DNS64

DNS64 ทำงานอย่างไร

DNS64 คือ resolver DNS พิเศษของผู้ให้บริการที่มีความสามารถพิเศษ เมื่ออุปกรณ์ขอเรกคอร์ด AAAA สำหรับโดเมน แต่ไม่มีเรกคอร์ด AAAA จริง DNS64 ไม่ยอมแพ้ มันทำดังนี้:

  1. ขอเรกคอร์ด A ปกติจากเซิร์ฟเวอร์ที่เชื่อถือได้ และรับที่อยู่ IPv4 ของเว็บไซต์
  2. นำที่อยู่ IPv4 นั้นมาสร้างเรกคอร์ด AAAA ปลอมขึ้นมา
  3. ในการสังเคราะห์ มันฝัง 32 บิตของที่อยู่ IPv4 เข้าไปในพรีฟิกซ์ IPv6 พิเศษ
  4. ส่งคืนเรกคอร์ด AAAA ที่สังเคราะห์แล้วนี้ให้กับอุปกรณ์ เหมือนไม่มีอะไรเกิดขึ้น

อุปกรณ์ได้รับที่อยู่ IPv6 ที่ถูกต้อง และส่งแพ็กเก็ตไปยังที่อยู่นั้นอย่างมีความสุข มันไม่รู้และไม่จำเป็นต้องรู้ว่าที่อยู่นี้เป็นของปลอม

พรีฟิกซ์สังเคราะห์ 64:ff9b::/96

มาถึงหนึ่งใน artifacts ที่เป็นที่รู้จักมากที่สุดของทั้งระบบแล้ว สำหรับการสังเคราะห์ที่อยู่ จะใช้พรีฟิกซ์ที่สงวนไว้เป็นพิเศษ 64:ff9b::/96 มันถูกเรียกว่า Well-Known Prefix ซึ่งก็คือพรีฟิกซ์ที่รู้จักทั่วไป และถูกกำหนดเป็นมาตรฐานสำหรับการแปล NAT64 โดยเฉพาะ

กลไกนั้นเรียบง่ายและสง่างาม พรีฟิกซ์ครอบครอง 96 บิตแรกของที่อยู่ 32 บิตที่เหลือคือขนาดพอดีของที่อยู่ IPv4 DNS64 ก็แค่ต่อท้ายที่อยู่ IPv4 ของเว็บไซต์เข้าไปที่ส่วนท้ายของพรีฟิกซ์

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

ผู้ให้บริการบางรายใช้พรีฟิกซ์เครือข่ายของตัวเองจากพื้นที่ที่อยู่ของตน แทนที่จะใช้พรีฟิกซ์ที่รู้จักทั่วไป ตรรกะเหมือนกัน แต่ค่าเฉพาะของบิตแรกเปลี่ยนไป

การจับคู่ทำงานร่วมกันอย่างไร

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

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

เส้นทางของแพ็กเก็ตจากแอปพลิเคชันถึงเว็บไซต์ด้วย 464XLAT: แผนภาพแบบคำพูด

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

เส้นทางไป: จากโทรศัพท์ถึงเว็บไซต์

  1. ขั้นตอนที่ 1. แอปพลิเคชันต้องการเชื่อมต่อ แอปพลิเคชันบนโทรศัพท์ตัดสินใจเปิดเว็บไซต์ที่มีเฉพาะ IPv4 มันติดต่อ DNS เพื่อขอที่อยู่
  2. ขั้นตอนที่ 2. DNS64 สังเคราะห์ที่อยู่ resolver ของผู้ให้บริการไม่พบเรกคอร์ด AAAA จริง จึงนำเรกคอร์ด A มา ฝังที่อยู่ IPv4 ลงในพรีฟิกซ์ 64:ff9b::/96 และส่งคืนเรกคอร์ด AAAA ที่สังเคราะห์แล้ว
  3. ขั้นตอนที่ 3. แอปพลิเคชันส่งแพ็กเก็ต มีสองทางเลือก ถ้าแอปพลิเคชันทำงานบน IPv6 มันจะส่งแพ็กเก็ต IPv6 ไปยังที่อยู่ที่สังเคราะห์ขึ้นโดยตรง ถ้าแอปพลิเคชันผูกติดกับ IPv4 อย่างตายตัว มันจะส่งแพ็กเก็ต IPv4 ไปยังอินเทอร์เฟซเสมือนของ CLAT
  4. ขั้นตอนที่ 4. CLAT แปล IPv4 เป็น IPv6 ในกรณีของแอปพลิเคชัน IPv4 เดมอน CLAT จะสกัดกั้นแพ็กเก็ตและแปลงเป็นแพ็กเก็ต IPv6 ตามกฎ stateless-translation โดยใช้พรีฟิกซ์ NAT64 เดียวกัน
  5. ขั้นตอนที่ 5. แพ็กเก็ตเดินทางผ่านเครือข่ายวิทยุ ตอนนี้มันคือแพ็กเก็ต IPv6 บริสุทธิ์ มันผ่านสถานีฐานและแกนเครือข่ายมือถือของผู้ให้บริการ ภายในส่วนวิทยุทั้งหมดมีเพียง IPv6
  6. ขั้นตอนที่ 6. แพ็กเก็ตถึง PLAT ในแกนเครือข่ายมีโหนด PLAT ที่มีฟังก์ชัน NAT64 มันเห็นแพ็กเก็ตที่มีปลายทางขึ้นต้นด้วยพรีฟิกซ์ NAT64
  7. ขั้นตอนที่ 7. PLAT แปล IPv6 เป็น IPv4 โหนดดึง 32 บิตสุดท้ายของที่อยู่ปลายทางออกมา ซึ่งก็คือ IPv4 จริงของเว็บไซต์ จากนั้นใส่ที่อยู่ IPv4 สาธารณะจาก pool ของตนเป็นต้นทาง บันทึกการจับคู่ในตารางสถานะ
  8. ขั้นตอนที่ 8. แพ็กเก็ตออกสู่อินเทอร์เน็ต ตอนนี้มันคือแพ็กเก็ต IPv4 ปกติ มันเดินทางผ่านเครือข่ายทั่วโลกไปยังเซิร์ฟเวอร์เป้าหมาย
  9. ขั้นตอนที่ 9. เว็บไซต์เห็น IPv4 เซิร์ฟเวอร์ได้รับการเชื่อมต่อจากที่อยู่ IPv4 สาธารณะของผู้ให้บริการ ใน log มันบันทึก IPv4 นี้ นี่คือช่วงเวลาแห่งความจริง: เว็บไซต์ไม่เคยรู้ว่าแพ็กเก็ตเกิดในสภาพแวดล้อม IPv6

เส้นทางกลับ: จากเว็บไซต์ถึงโทรศัพท์

  1. ขั้นตอนที่ 10. เซิร์ฟเวอร์ตอบกลับ เว็บไซต์ส่งแพ็กเก็ต IPv4 ตอบกลับไปยังที่อยู่สาธารณะที่มันเห็น
  2. ขั้นตอนที่ 11. PLAT พบการจับคู่ โหนด NAT64 ดูในตารางสถานะของมัน พิจารณาว่าอุปกรณ์ใดเป็นเจ้าของการเชื่อมต่อ และกู้คืนที่อยู่ IPv6
  3. ขั้นตอนที่ 12. แปลกลับเป็น IPv6 PLAT เปลี่ยนคำตอบ IPv4 เป็นแพ็กเก็ต IPv6 และส่งผ่านแกนเครือข่ายกลับไปยังโทรศัพท์
  4. ขั้นตอนที่ 13. CLAT ส่งคืน IPv4 ให้แอปพลิเคชัน ถ้าเดิมแอปพลิเคชันทำงานบน IPv4 CLAT บนอุปกรณ์จะแปลคำตอบ IPv6 กลับเป็น IPv4 และส่งให้แอปพลิเคชันผ่านอินเทอร์เฟซเสมือน
  5. ขั้นตอนที่ 14. แอปพลิเคชันได้รับคำตอบ สำหรับแอปพลิเคชัน ทุกอย่างดูเหมือนการแลกเปลี่ยน IPv4 ปกติ วงจรปิดลง

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

ทั้งหมดนี้หมายความว่าอย่างไรสำหรับพร็อกซี: ที่อยู่ขาออกเกิดที่ไหน

ตอนนี้เราจะนำทฤษฎีทั้งหมดมาประยุกต์ใช้กับการปฏิบัติจริงของมือถือพร็อกซี นี่คือส่วนที่สำคัญที่สุดสำหรับคนที่ทำงานกับทราฟฟิก

ที่อยู่ขาออกเกิดที่ไหน

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

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

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

สิ่งที่เว็บไซต์เป้าหมายเห็นในท้ายที่สุด

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

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

เมื่อใดที่เว็บไซต์อาจเห็น IPv6

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

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

รายการตรวจสอบความเข้าใจที่อยู่ขาออก

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

Dual stack และ happy eyeballs: ทำไมการตรวจสอบถึงแสดงทั้ง IPv4 และ IPv6

คุณคงเคยเจอว่าบริการตรวจสอบ IP เมื่อเรียกซ้ำๆ แสดงที่อยู่ต่างกัน - บางครั้ง IPv4 บางครั้ง IPv6 สิ่งนี้น่างง มาทำความเข้าใจกันว่าทำไมถึงเป็นเช่นนั้น

Dual stack คืออะไร

Dual stack หมายความว่าอุปกรณ์มีทั้งที่อยู่ IPv4 และ IPv6 พร้อมกัน และสามารถใช้ทั้งสองโปรโตคอลได้ ในสภาพแวดล้อมมือถือ สิ่งนี้มักเกิดขึ้นผ่าน APN แบบ IPv4v6 หรือผ่านการรวมกันของ IPv6 ดั้งเดิมและ CLAT ที่ให้ IPv4 ในเครื่อง

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

อัลกอริทึม happy eyeballs

เพื่อแก้ปัญหานี้ จึงคิดค้นอัลกอริทึม happy eyeballs ซึ่งแปลว่า ตาอันเบิกบาน แนวคิดของมันคือไม่ต้องเดาล่วงหน้าว่าโปรโตคอลไหนดีกว่า แต่ให้จัดการแข่งขันแทน

วิธีการทำงานโดยคร่าวๆ ดังนี้:

  1. ลูกค้าขอทั้งเรกคอร์ด A และ AAAA สำหรับโดเมนพร้อมกัน
  2. เมื่อได้รับที่อยู่ของทั้งสองโปรโตคอลแล้ว มันจะเริ่มสร้างการเชื่อมต่อเกือบจะพร้อมกัน
  3. การพยายาม IPv6 มักจะเริ่มก่อน โดยมีข้อได้เปรียบเล็กน้อยประมาณหลายสิบหรือหลายร้อยมิลลิวินาที
  4. ถ้าการเชื่อมต่อ IPv6 สร้างได้เร็ว ก็จะใช้มัน
  5. ถ้า IPv6 ช้าหรือไม่ตอบสนอง ลูกค้าจะเปลี่ยนไปใช้ IPv4 เกือบจะทันที
  6. ผู้ชนะการแข่งขันจะถูกใช้สำหรับการส่งข้อมูล ส่วนการเชื่อมต่อที่แพ้จะถูกปิด

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

ทำไมการตรวจสอบถึงแสดงที่อยู่ต่างกัน

ตอนนี้ก็ชัดเจนแล้วว่าความไม่แน่นอนมาจากไหน เมื่อคุณเปิดบริการตรวจสอบ IP สิ่งต่อไปนี้เกิดขึ้น:

  • ถ้าบริการมีทั้งเรกคอร์ด A และ AAAA happy eyeballs ก็จะทำงาน
  • ขึ้นอยู่กับการเชื่อมต่อไหนชนะการแข่งขันในขณะนั้น คุณจะเห็น IPv4 หรือ IPv6
  • สถานะเครือข่าย โหลด เครดิตการเชื่อมต่อ ทั้งหมดมีผลต่อผลการแข่งขัน
  • ในการเรียกครั้งต่อไป การแข่งขันอาจจบลงต่างกัน และที่อยู่ก็เปลี่ยนไป

นี่ไม่ใช่ข้อผิดพลาดของพร็อกซี หรือความไม่เสถียรของการเชื่อมต่อ นี่คือพฤติกรรมที่คาดหวังของ dual stack ภายใต้การควบคุมของ happy eyeballs ถ้าคุณต้องการผลลัพธ์ที่คาดเดาได้ คุณต้องบังคับเวอร์ชันโปรโตคอล - เกี่ยวกับเรื่องนี้ในหัวข้อถัดไป

ข้อมูลเชิงปฏิบัติ

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

ปฏิบัติ: วิธีดูว่าสแต็กการเชื่อมต่อเป็นแบบไหน

ทฤษฎีที่ไม่มีปฏิบัตินั้นตาย ขอเตรียมคำสั่งเฉพาะเพื่อให้คุณเห็นด้วยตาตัวเองว่าเกิดอะไรขึ้นกับการเชื่อมต่อของคุณ เครื่องมือทั้งหมดเป็นมาตรฐานและมีอยู่ในระบบส่วนใหญ่

ดูที่อยู่ของอินเทอร์เฟซ

สิ่งแรกที่ต้องทำคือดูว่าที่อยู่ใดถูกกำหนดให้กับอินเทอร์เฟซเครือข่าย สำหรับ IPv6 ให้ใช้คำสั่ง:

  • ip -6 addr - แสดงที่อยู่ IPv6 ทั้งหมดบนทุกอินเทอร์เฟซ
  • ip -4 addr - คล้ายกันสำหรับ IPv4
  • ip addr - แสดงทั้งหมดพร้อมกัน

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

ตรวจสอบการเข้าถึงด้วย ping

ping ช่วยตรวจสอบว่าโปรโตคอลเฉพาะทำงานหรือไม่:

  • ping6 ที่อยู่ หรือ ping -6 ที่อยู่ - ตรวจสอบการเชื่อมต่อผ่าน IPv6
  • ping -4 ที่อยู่ - ตรวจสอบการเชื่อมต่อผ่าน IPv4

ถ้า ping ผ่าน IPv6 ไปยังโหนดทั่วโลกได้ แสดงว่าคุณมีการเชื่อมต่อ IPv6 ที่ใช้งานได้ ถ้าผ่านเฉพาะ IPv4 แสดงว่า IPv6 ไม่ได้ถูกกำหนดค่าหรือไม่ทำงาน

บังคับโปรโตคอลใน curl

เครื่องมือวินิจฉัยที่ทรงพลังที่สุดสำหรับทราฟฟิกเว็บคือ curl พร้อมกับคีย์บังคับเลือกโปรโตคอล:

  • curl -4 ที่อยู่ - บังคับใช้เฉพาะ IPv4
  • curl -6 ที่อยู่ - บังคับใช้เฉพาะ IPv6
  • curl -v ที่อยู่ - โหมดละเอียด แสดงว่าจริงๆ แล้วเชื่อมต่อกับที่อยู่ใด

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

การตรวจสอบบน endpoint ที่ใช้ IPv6 เท่านั้น

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

สถานการณ์การตรวจสอบเชิงปฏิบัติ:

  1. รัน curl -6 บน endpoint ที่ใช้ IPv6 เท่านั้น - ตรวจสอบการเชื่อมต่อ IPv6 ดั้งเดิม
  2. รัน curl -4 บนบริการระบุ IP - ดู IPv4 ขาออกผ่าน PLAT
  3. เปรียบเทียบที่อยู่ - ถ้า IPv6 ขาออกมาจาก subnet ของสมาชิก และ IPv4 จาก pool ของผู้ให้บริการ แสดงว่ามี dual stack ที่สมบูรณ์พร้อม 464XLAT

วิธีตรวจสอบว่ามีพรีฟิกซ์ NAT64 หรือไม่

เพื่อให้รู้ว่าเครือข่ายของคุณใช้ NAT64 หรือไม่ ให้ดูที่อยู่ที่สังเคราะห์ขึ้น ขอเรกคอร์ด AAAA สำหรับโดเมนที่ไม่มี IPv6 อย่างแน่นอน และดูคำตอบ ถ้าคืนที่อยู่ที่ขึ้นต้นด้วย 64:ff9b นั่นคือสัญญาณชัดเจนว่ามี DNS64 และ NAT64 ทำงานอยู่ บางระบบมีกลไกตรวจจับพรีฟิกซ์ NAT64 ในตัว ซึ่งทำงานในลักษณะนี้: ขอชื่อที่รู้จักและดูโครงสร้างของคำตอบ

รายการตรวจสอบการวินิจฉัยสแต็ก

  • ip -6 addr - มี IPv6 ทั่วโลกหรือไม่
  • ip -4 addr - มี IPv4 หรือไม่ และมันเป็นที่อยู่ส่วนตัวของ CLAT หรือเปล่า
  • ping -6 ไปยังโหนดทั่วโลก - การเชื่อมต่อ IPv6 ทำงานหรือไม่
  • curl -4 ไปยังบริการ IP - IPv4 ที่เว็บไซต์เห็นคืออะไร
  • curl -6 ไปยัง endpoint ที่ใช้ IPv6 เท่านั้น - มี IPv6 ดั้งเดิมหรือไม่
  • การสอบถาม AAAA สำหรับโดเมนที่ใช้ IPv4 เท่านั้น - เห็นพรีฟิกซ์ 64:ff9b หรือไม่

ความเข้ากันได้: ทำไม subnet /64 ถึงถูกมองว่าเป็นลูกค้ารายเดียว

ต่อไปเป็นคำถามที่มีความสำคัญในทางปฏิบัติอย่างมากสำหรับทุกคนที่ทำงานกับหลายบัญชี ว่ากันที่ว่าแพลตฟอร์มต่างๆ ปฏิบัติต่อการเชื่อมต่อ IPv6 อย่างไร

ทำไมบางแพลตฟอร์มถึงปฏิบัติต่อ IPv6 แย่กว่า

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

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

ดังนั้นแพลตฟอร์มจึงพัฒนาวิธีการพิเศษสำหรับ IPv6 และการทำความเข้าใจมันเป็นสิ่งสำคัญอย่างยิ่ง

การตีความ subnet /64

จำสิ่งที่เราพูดในส่วนพื้นฐานได้ไหม: ผู้ให้บริการจัดสรร subnet /64 ทั้งหมดให้สมาชิกหนึ่งคน นั่นคือจำนวนที่อยู่มหาศาลสำหรับอุปกรณ์หนึ่งเครื่อง

ระบบชื่อเสียงที่ชาญฉลาดเข้าใจสิ่งนี้ แทนที่จะประเมินที่อยู่ IPv6 แต่ละที่อยู่แยกกัน พวกมันรวม subnet /64 ทั้งหมดและถือว่าเป็นตัวระบุเดียว ตรรกะง่าย: เนื่องจาก subnet ทั้งหมดนี้เป็นของสมาชิกคนเดียว ก็ควรปฏิบัติต่อมันเหมือนลูกค้ารายเดียว

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

สิ่งนี้หมายถึงอะไรสำหรับการทำงานกับหลายบัญชี

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

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

ข้อสรุปสำคัญสำหรับการจัดการหลายบัญชี:

  • การเปลี่ยนบิตสุดท้ายของ IPv6 ภายใน /64 เดียวกันไม่ได้เปลี่ยนตัวระบุสำหรับแพลตฟอร์มที่ชาญฉลาด
  • หน่วยที่มีความหมายสำหรับ IPv6 คือพรีฟิกซ์ /64 ไม่ใช่ที่อยู่เดี่ยว
  • การแยกต้องเกิดขึ้นในระดับ subnet /64 ที่แตกต่างกัน ไม่ใช่ที่อยู่ภายใน subnet เดียวกัน
  • IPv4 ผ่าน NAT64 ผสมคุณกับสมาชิกรายอื่นของผู้ให้บริการ ซึ่งให้พลศาสตร์ชื่อเสียงที่แตกต่าง
  • เข้าใจเสมอว่าโปรโตคอลใดถูกใช้จริงสำหรับการเชื่อมต่อกับแพลตฟอร์มเฉพาะ

คำแนะนำเชิงปฏิบัติในการควบคุมโปรโตคอล

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

ข้อผิดพลาดทั่วไปเมื่อทำงานกับ IPv6 ในเครือข่ายมือถือ

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

ข้อผิดพลาดแรก: คิดว่าที่อยู่ IPv6 บนโทรศัพท์หมายถึงการออกทาง IPv6

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

ข้อผิดพลาดที่สอง: สับสนระหว่างที่อยู่ขาออกกับที่อยู่อินเทอร์เฟซ

ที่อยู่บนอินเทอร์เฟซเครือข่ายของอุปกรณ์กับที่อยู่ที่เว็บไซต์เห็นนั้นเป็นคนละสิ่งกัน ระหว่างพวกมันมี CLAT และ PLAT พร้อมการแปลและ NAT อย่าตัดสินที่อยู่ขาออกจากสิ่งที่ ip addr แสดง ให้ตรวจสอบกับบริการภายนอกจริงเสมอ

ข้อผิดพลาดที่สาม: ตื่นตระหนกเพราะที่อยู่กระโดดในการตรวจสอบ

เราได้อธิบายไปแล้วว่า happy eyeballs ทำให้ dual stack แสดงทั้ง IPv4 และ IPv6 สลับกันไปมา นี่เป็นเรื่องปกติ อย่าถือว่านี่เป็นสัญญาณว่าพร็อกซีเสีย ถ้าต้องการความเสถียร ให้บังคับโปรโตคอล

ข้อผิดพลาดที่สี่: คิดว่าการเปลี่ยน IPv6 ภายใน /64 จะสร้างตัวระบุใหม่

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

ข้อผิดพลาดที่ห้า: ละเลยประเภท APN

ประเภท APN - IPv4, IPv6 หรือ IPv4v6 - กำหนดโดยตรงว่าจะเกิดอะไรขึ้นกับทราฟฟิก ถ้าไม่เข้าใจว่าใช้ประเภทไหน คุณก็ทำงานแบบสุ่มสี่สุ่มห้า ควรตรวจสอบการกำหนดค่าเซสชันเสมอ

ข้อผิดพลาดที่หก: ทดสอบการเชื่อมต่อโดยใช้โปรโตคอลเดียวเท่านั้น

การตรวจสอบเฉพาะ IPv4 หรือเฉพาะ IPv6 จะให้ภาพที่ไม่สมบูรณ์ การวินิจฉัยที่แท้จริงต้องตรวจสอบทั้งสองโปรโตคอลแยกกันด้วยคีย์ -4 และ -6 รวมถึงการติดต่อ endpoint ที่ใช้ IPv6 เท่านั้น

ข้อผิดพลาดที่เจ็ด: สับสนระหว่างพรีฟิกซ์ NAT64 กับเว็บไซต์ IPv6 จริง

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

ข้อผิดพลาดที่แปด: คิดว่า CLAT และ PLAT เป็นสิ่งเดียวกัน

CLAT อยู่บนอุปกรณ์และทำ stateless-translation สำหรับแอปพลิเคชัน PLAT อยู่ในเครือข่ายผู้ให้บริการและทำ stateful-translation พร้อม NAT พวกมันเป็นส่วนประกอบที่แตกต่างกัน มีหน้าที่ต่างกัน การสับสนระหว่างพวกมันทำให้ไม่เข้าใจว่าที่อยู่ขาออกเกิดที่ไหน

เครื่องมือและทรัพยากรสำหรับการทำงานกับสแต็กโปรโตคอล

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

บรรทัดคำสั่ง

  • ip addr และรูปแบบต่างๆ ip -4 addr, ip -6 addr - เครื่องมือพื้นฐานสำหรับดูที่อยู่อินเทอร์เฟซ
  • ping และ ping6 - ตรวจสอบการเชื่อมต่อตามโปรโตคอลที่ระบุ
  • curl พร้อมคีย์ -4 และ -6 - เครื่องมือหลักสำหรับวินิจฉัยการเชื่อมต่อเว็บและตรวจสอบที่อยู่ขาออก
  • traceroute และ traceroute6 - การติดตามเส้นทาง ช่วยดูว่าแพ็กเก็ตผ่านโหนดใดบ้าง
  • dig และ nslookup - การสอบถาม DNS เพื่อตรวจสอบเรกคอร์ด A และ AAAA ตรวจจับที่อยู่สังเคราะห์
  • ip route - ดูตารางเส้นทางสำหรับทั้งสองโปรโตคอล

บริการตรวจสอบออนไลน์

  • บริการระบุ IP ภายนอก - แสดงสิ่งที่เว็บไซต์ระยะไกลเห็น
  • Endpoint ทดสอบที่ใช้ IPv6 เท่านั้น - ตรวจสอบการเชื่อมต่อ IPv6 ดั้งเดิม
  • บริการที่แสดง IPv4 และ IPv6 แยกกัน - ช่วยให้เห็น dual stack
  • เครื่องมือตรวจสอบการรองรับ IPv6 ของโดเมน - แสดงว่ามีเรกคอร์ด AAAA หรือไม่

การวินิจฉัย DNS

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

กรอบการวินิจฉัยสแต็กของระบบ

ขอเสนอกรอบการทำงานทีละขั้นตอนที่ควรทำเมื่อพบกับเครือข่ายมือถือใดๆ เป็นครั้งแรก:

  1. สำรวจที่อยู่ รัน ip addr ตรวจสอบว่ามี IPv6 ทั่วโลกหรือไม่ และลักษณะของ IPv4
  2. ระบุ CLAT ค้นหาอินเทอร์เฟซเสมือนที่มี IPv4 ส่วนตัว ซึ่งเป็นสัญญาณของ 464XLAT
  3. ตรวจสอบ NAT64 ขอ AAAA สำหรับโดเมนที่ใช้ IPv4 เท่านั้น มองหาพรีฟิกซ์ 64:ff9b
  4. ทดสอบ IPv6 ดั้งเดิม curl -6 ไปยัง endpoint ที่ใช้ IPv6 เท่านั้น
  5. ระบุ IPv4 ขาออก curl -4 ไปยังบริการระบุ IP
  6. ระบุ IPv6 ขาออก curl -6 ไปยังบริการที่รองรับ IPv6
  7. วิเคราะห์พฤติกรรม dual stack ส่งคำขอปกติโดยไม่บังคับโปรโตคอล สังเกต happy eyeballs

เมื่อทำครบทั้งเจ็ดขั้นตอน คุณจะได้ภาพที่สมบูรณ์: การเชื่อมต่อประเภทใดในเครือข่าย, การแปลทำงานหรือไม่, ที่อยู่ประเภทใดที่เว็บไซต์ประเภทต่างๆ เห็น, และ dual stack มีพฤติกรรมอย่างไร นี่คือการตรวจสอบมาตรฐานของคุณ

กรณีศึกษาและผลลัพธ์: การวิเคราะห์สถานการณ์จริง

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

กรณีแรก: เว็บไซต์ใน log เห็น IPv4 เดียวสำหรับลูกค้าหลายคน

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

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

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

กรณีที่สอง: คำตอบที่ไม่แน่นอนจากบริการตรวจสอบ

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

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

วิธีแก้ บังคับโปรโตคอลด้วย curl -4 หรือการตั้งค่าที่เหมาะสมของไคลเอ็นต์ หลังจากบังคับ IPv4 ที่อยู่ก็คงที่ ปัญหาความไม่เสถียรกลายเป็นเรื่องหลอกลวง

กรณีที่สาม: บัญชีถูกเชื่อมโยงแม้จะใช้ IPv6 ต่างกัน

สถานการณ์ ทำงานกับหลายบัญชีผ่าน IPv6 แต่ละบัญชีได้รับที่อยู่ IPv6 แยกกัน แต่แพลตฟอร์มกลับเชื่อมโยงบัญชีเข้าด้วยกัน

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

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

กรณีที่สี่: แอปพลิเคชันที่ไม่รองรับ IPv6

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

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

สรุป 464XLAT ให้ความเข้ากันได้อย่างโปร่งใสสำหรับแอปพลิเคชันที่ล้าสมัย นี่คือสาเหตุที่การเปลี่ยนไปใช้ IPv6 ของผู้ให้บริการไม่ได้ทำลายระบบนิเวศของซอฟต์แวร์ IPv4

คำถามที่พบบ่อย

ทำไมโทรศัพท์ของฉันถึงแสดง IPv6 แต่เว็บไซต์ใน log บันทึก IPv4?

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

พรีฟิกซ์ 64:ff9b คืออะไรและมาจากไหน?

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

CLAT แตกต่างจาก PLAT อย่างไร?

CLAT ทำงานบนอุปกรณ์และทำ stateless-translation จาก IPv4 เป็น IPv6 สำหรับแอปพลิเคชันที่ต้องการ IPv4 PLAT ทำงานในเครือข่ายผู้ให้บริการและทำ stateful-translation จาก IPv6 เป็น IPv4 พร้อม NAT โดยใส่ที่อยู่สาธารณะ CLAT แก้ปัญหาความเข้ากันได้บนอุปกรณ์ PLAT แก้ปัญหาความเข้ากันได้กับอินเทอร์เน็ต IPv4

ทำไมบริการตรวจสอบ IP ถึงแสดงที่อยู่ต่างกันเมื่อรีเฟรช?

เพราะอัลกอริทึม happy eyeballs ในสภาพแวดล้อม dual stack ถ้าบริการตรวจสอบสามารถเข้าถึงได้ทั้ง IPv4 และ IPv6 ไคลเอ็นต์จะเริ่มการแข่งขันการเชื่อมต่อ และในเวลาที่ต่างกัน โปรโตคอลที่ต่างกันอาจชนะ นี่เป็นพฤติกรรมปกติ ไม่ใช่ความผิดพลาด บังคับโปรโตคอลด้วยคีย์เพื่อผลลัพธ์ที่เสถียร

จะรู้ได้อย่างไรว่าฉันมีการเชื่อมต่อ IPv6 จริง ไม่ใช่แค่ NAT64?

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

ทำไมการเปลี่ยนที่อยู่ IPv6 จึงไม่ช่วยแยกบัญชี?

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

ทำไมมือถือพร็อกซีถึงมี IPv4 ขาออกเป็นส่วนใหญ่ แทนที่จะเป็น IPv6?

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

จะบังคับให้ไคลเอ็นต์ใช้โปรโตคอลเวอร์ชันที่ต้องการได้อย่างไร?

ในระดับ curl ใช้คีย์ -4 สำหรับ IPv4 และ -6 สำหรับ IPv6 แอปพลิเคชันและไลบรารีหลายตัวมีการตั้งค่ากำหนดโปรโตคอลที่คล้ายกัน นอกจากนี้ยังสามารถจัดการผ่านการตั้งค่าระบบของนโยบายลำดับความสำคัญของที่อยู่ ซึ่งจะปิดความไม่แน่นอนของ happy eyeballs และให้ผลลัพธ์ที่คาดเดาได้

เว็บไซต์เป้าหมายเห็นอะไรเมื่อเชื่อมต่อผ่านเครือข่ายมือถือ?

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

ประเภท APN มีผลต่อที่อยู่ที่เว็บไซต์เห็นหรือไม่?

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

สรุป: สิ่งสำคัญเกี่ยวกับกลไก IPv6 ในเครือข่ายมือถือ

เรามาไกลมาก เริ่มจากปริศนา - โทรศัพท์ใน IPv6 แต่เว็บไซต์เห็น IPv4 - และไขมันได้อย่างสมบูรณ์ มาสรุปข้อค้นพบสำคัญกัน

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

ประการที่สอง 464XLAT ประกอบด้วยตัวแปลสองตัว CLAT บนอุปกรณ์แปลงทราฟฟิก IPv4 ของแอปพลิเคชันเป็น IPv6 PLAT ในเครือข่ายผู้ให้บริการแปลง IPv6 กลับเป็น IPv4 และใส่ที่อยู่สาธารณะ ที่ PLAT นี้เองที่ที่อยู่ IPv4 ขาออกซึ่งเว็บไซต์เห็น ถูกสร้างขึ้น

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

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

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

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

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