Network Address Translation ( NAT ) ได้กลายเป็นรากฐานสำคัญของโครงสร้างพื้นฐานอินเทอร์เน็ตสมัยใหม่ ช่วยให้อุปกรณ์หลายพันล้านเครื่องสามารถใช้ที่อยู่ IPv4 ที่มีจำกัดร่วมกันได้ แม้ว่าคนส่วนใหญ่จะเข้าใจ NAT เป็นเพียงการแมปง่ายๆ ระหว่างที่อยู่ IP ส่วนตัวและสาธารณะ แต่การอภิปรายทางเทคนิคล่าสุดเผยให้เห็นชั้นความซับซ้อนที่ซ่อนอยู่ซึ่งทำให้การนำ NAT มาใช้งานอย่างแข็งแกร่งนั้นท้าทายกว่าที่ดูเผินๆ มาก
การเปรียบเทียบพื้นที่แอดเดรสของ IPv4 กับ IPv6
- IPv4: แอดเดรส 32 บิต = จำนวนแอดเดรสทั้งหมด 4,294,967,296 แอดเดรส (~4.3 พันล้าน)
- IPv6: แอดเดรส 128 บิต = จำนวนแอดเดรส 340,282,366,920,938,463,463,374,607,431,768,211,456 แอดเดรส (~340 อันดีซิลเลียน)
- อัตราส่วนแอดเดรส: IPv6 มีแอดเดรสมากกว่า IPv4 ประมาณ 79 ออกทิลเลียนเท่า
การแบ่งส่วน IP สร้างความท้าทายที่ไม่คาดคิดใน NAT
ความซับซ้อนที่สำคัญที่สุดในระบบ NAT มาจากการจัดการการแบ่งส่วน IP โดยเฉพาะกับแพ็กเก็ต UDP เมื่อ datagram ของ UDP มีขนาดเกินขนาดแพ็กเก็ตสูงสุด มันจะถูกแบ่งออกเป็นแพ็กเก็ต IP หลายๆ แพ็กเก็ต อย่างไรก็ตาม มีเพียงแพ็กเก็ตแรกเท่านั้นที่มี header ของ UDP พร้อมข้อมูลพอร์ตที่อุปกรณ์ NAT ต้องการสำหรับการแปลงที่อยู่
สิ่งนี้สร้างปัญหาต่อเนื่องหลายประการ อุปกรณ์ NAT ต้องเชื่อมโยงแพ็กเก็ตที่แบ่งส่วนโดยใช้ fragment ID และเขียน IP address ใหม่ทั่วทุกส่วน ที่แย่กว่านั้น ส่วนต่างๆ สามารถมาถึงไม่เป็นลำดับ ทำให้ระบบ NAT ต้องเก็บส่วนหลังๆ ไว้ในบัฟเฟอร์จนกว่าแพ็กเก็ตแรกที่มี UDP header จะมาถึง ความต้องการในการเก็บบัฟเฟอร์นี้เพิ่มภาระหน่วยความจำและความซับซ้อนในการประมวลผลที่หลายคนไม่รู้ว่ามีอยู่
ปัญหาการแบ่งส่วนกลายเป็นเรื่องที่ยุ่งยากโดยเฉพาะในเครือข่ายขนาดใหญ่ที่มีเส้นทางหลายเส้นทาง เราเตอร์สมัยใหม่ใช้ flow steering เพื่อกระจายการรับส่งข้อมูลข้ามลิงก์โดยการแฮชรายละเอียดการเชื่อมต่อจาก UDP หรือ TCP header แต่แพ็กเก็ตที่แบ่งส่วนทำลายระบบนี้เนื่องจากส่วนหลังๆ ขาดข้อมูล header ที่จำเป็นสำหรับการกำหนดเส้นทางที่สม่ำเสมอ
ความซับซ้อนเพียงจุดเดียวนี้น่าจะเป็นสาเหตุของความซับซ้อนครึ่งหนึ่งในการนำ NAT ที่แข็งแกร่งมาใช้งาน
ผลกระทบในโลกจริงนอกเหนือจากเครือข่ายบ้าน
แม้ว่าหลายคนจะเชื่อมโยง NAT กับเราเตอร์บ้านเป็นหลัก แต่เทคโนโลยีนี้แพร่หลายในโครงสร้างพื้นฐานองค์กรและคลาวด์ คอนเทนเนอร์ Docker พึ่งพา Linux NAT อย่างมากผ่านกฎ iptables เพื่อแมปพอร์ตโฮสต์กับบริการคอนเทนเนอร์ ทุกครั้งที่นักพัฒนารันคำสั่งแมปพอร์ตง่ายๆ พวกเขากำลังใช้ประโยชน์จากเทคนิคการจัดการแพ็กเก็ตเดียวกันที่ใช้โดย NAT gateway ระดับ ISP
ความซับซ้อนจะเด่นชัดยิ่งขึ้นในบริการ cloud NAT ที่จัดการซึ่งต้องการความพร้อมใช้งานสูงและการจำลองแบบสด ระบบเหล่านี้ต้องจัดการกับกรณีขอบของการแบ่งส่วนในขณะที่รักษาความสอดคล้องของธุรกรรมข้ามโหนดหลายโหนด
ประเภทของ NAT และลักษณะเฉพาะ
| ประเภท NAT | คำอธิบาย | การเข้าถึงจากภายนอก |
|---|---|---|
| Basic/Static NAT | การแปลง IP แบบหนึ่งต่อหนึ่ง | การแมปโดยตรง |
| Port Address Translation (PAT) | อุปกรณ์หลายตัวใช้ IP สาธารณะร่วมกันโดยใช้พอร์ตที่แตกต่างกัน | การแยกแยะตามพอร์ต |
| Full Cone NAT (NAT 1) | โฮสต์ภายนอกใดๆ สามารถส่งแพ็กเก็ตได้หากทราบ IP/พอร์ต สาธารณะ | การเข้าขาเข้าแบบไม่จำกัด |
| Restricted Cone NAT (NAT 2) | เฉพาะโฮสต์ภายนอกที่เคยติดต่อไปแล้วเท่านั้นที่สามารถส่งแพ็กเก็ตกลับมาได้ | การเข้าขาเข้าที่จำกัดตาม IP |
| Port Restricted Cone NAT (NAT 3) | โฮสต์ภายนอกต้องตรงกันทั้ง IP และพอร์ตจากการสื่อสารขาออก | จำกัดตาม IP+พอร์ต |
| Symmetric NAT (NAT 4) | การแมปที่แตกต่างกันสำหรับแต่ละปลายทาง ทำให้ WebRTC ที่ใช้ STUN ไม่สามารถทำงานได้ | จำกัดมากที่สุด |
แนวทางทางเลือกและการพิจารณาในอนาคต
วิศวกรเครือข่ายบางคนโต้แย้งว่า UDP ควรจัดการการแบ่งส่วนในชั้นโปรโตคอลแทนที่จะพึ่งพาการแบ่งส่วนระดับ IP สิ่งนี้จะขจัดความซับซ้อนของ NAT หลายอย่างโดยการรับประกันว่าทุกแพ็กเก็ตจะมีข้อมูล header ที่จำเป็น อย่างไรก็ตาม คนอื่นๆ ชี้ให้เห็นว่าการค้นพบ path MTU ที่แข็งแกร่งมีความท้าทายของตัวเอง โดยเฉพาะในเครือข่ายที่มีเส้นทางหลายเส้นทางที่มีหน่วยการส่งสูงสุดที่แตกต่างกัน
เครือข่ายการเงินแสดงให้เห็นแนวทางที่ประสบความสำเร็จหนึ่งแนวทางโดยการรักษาขนาดแพ็กเก็ต UDP ให้ต่ำกว่าเกณฑ์การแบ่งส่วนโดยเจตนาและใช้หมายเลขลำดับชั้นแอปพลิเคชันสำหรับการติดตามแพ็กเก็ต สิ่งนี้ย้ายการจัดการการแบ่งส่วนไปยังชั้นแอปพลิเคชันอย่างมีประสิทธิภาพซึ่งสามารถจัดการได้อย่างคาดเดาได้มากขึ้น
ความเป็นจริงของการย้ายไป IPv6
แม้ว่า IPv6 จะมีความสามารถทางทฤษฎีในการขจัดความต้องการ NAT ผ่านพื้นที่ที่อยู่ขนาดใหญ่ของมัน แต่การนำมาใช้ยังคงช้า สถิติการนำ IPv6 มาใช้ทั่วโลกปัจจุบันแสดงให้เห็นว่าการเปลี่ยนผ่านยังไกลจากการสมบูรณ์ หมายความว่าความซับซ้อนของ NAT จะคงอยู่ต่อไปอีกหลายปี แม้แต่เครือข่าย IPv6 บางครั้งก็ใช้เทคโนโลยีคล้าย NAT เช่น Network Prefix Translation ( NPT ) สำหรับกรณีการใช้งานเฉพาะ
การคงอยู่ของ NAT เน้นให้เห็นว่าโซลูชันเครือข่ายชั่วคราวมักจะกลายเป็นส่วนประกอบถาวร NAT ซึ่งเสนอครั้งแรกเป็นการแก้ไขระยะสั้นสำหรับการหมดของที่อยู่ IPv4 ในปี 1994 ได้พัฒนาเป็นองค์ประกอบที่สำคัญแต่ซับซ้อนของโครงสร้างพื้นฐานอินเทอร์เน็ตที่วิศวกรต้องเข้าใจอย่างลึกซึ้งเพื่อนำมาใช้งานอย่างเชื่อถือได้