NAT คืออะไร? หลักการทำงานและการจำแนก

1.1 กลุ่มคำเรียกและสิ่งที่แต่ละกลุ่มอธิบาย

ชื่อเรียก NAT ที่พบในเอกสารต่าง ๆ อธิบายคนละส่วนของระบบ การรวมทุกชื่อเป็นรายการประเภทระดับเดียวกันจะทำให้สับสน เช่น STUN เป็นโปรโตคอลที่ช่วยเรื่อง NAT Traversal ส่วน CGNAT บอกตำแหน่งการวาง NAT ในเครือข่ายผู้ให้บริการ

• ตำแหน่งข้อมูลที่แปลง: SNAT, DNAT, Twice NAT
• การรักษาสถานะ: Stateful NAT, Stateless NAT
• นโยบาย: Policy NAT, No-NAT, NAT Exemption
• การติดตั้งและการใช้งาน: Hairpin NAT, Double NAT, CGNAT
• ตระกูล IP: NAT44, NAT64, NAT46, NAT66
• กลไกช่วยแอปพลิเคชัน: STUN, TURN, ICE, PCP

1.2 กฎเดียวอธิบายได้หลายชื่อพร้อมกัน

ตัวอย่างกฎคงที่สำหรับบริการ TCP ที่แปลงปลายทางจาก 203.0.113.10:443 ไปเป็น 10.10.10.20:8443 อธิบายได้ว่าเป็น DNAT เพราะแปลงปลายทาง เป็น Static PAT เพราะกำหนด IP และ Port Mapping ไว้คงที่ และเป็น NAT44 เพราะทั้งก่อนและหลังแปลงเป็น IPv4 ทั้งหมด

ชื่อทั้งสามไม่ได้หมายความว่าแพ็กเก็ตต้องผ่าน NAT สามชั้น แต่เป็นการอธิบายกฎเดียวกันจากสามมุม

หมายเหตุ IP ภายนอกในตัวอย่างทั้งบทความ เช่น 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 และ IPv6 ภายใต้ 2001:db8::/32 เป็นช่วงที่สงวนไว้สำหรับเอกสาร ไม่ใช่หมายเลขสำหรับนำไปเปิดบริการบนอินเทอร์เน็ตจริง

2.1 ตัวอย่างการออกอินเทอร์เน็ตด้วย SNAT และ PAT

สมมติว่าคอมพิวเตอร์ 10.10.10.11 เปิดการเชื่อมต่อ TCP ไปยังเว็บเซิร์ฟเวอร์ 198.51.100.20:443 โดยใช้ Source Port 51514 ส่วน NAT Gateway มี IP ภายนอก 203.0.113.10 และเลือกพอร์ต 40001 สำหรับการแปลงครั้งนี้

Server เห็นคู่สนทนาเป็น 203.0.113.10:40001 ส่วน Gateway เก็บความสัมพันธ์ที่จำเป็นไว้เพื่อส่งคำตอบกลับไปยัง 10.10.10.11:51514 การใช้พอร์ตร่วมกับ IP ทำให้ Gateway แยกการสื่อสารของหลายเครื่องที่แชร์ IP ภายนอกเดียวกันได้

2.2 NAT Mapping กับ Session State

อุปกรณ์อาจเก็บ NAT Mapping และสถานะการเชื่อมต่อไว้คนละตาราง โดย Mapping หนึ่งรายการอาจเกี่ยวข้องกับหลาย Session ได้ ขึ้นอยู่กับวิธีออกแบบ NAT ตัวอย่างเช่น Stateful NAT64 แยก Binding Information Base ออกจาก Session Table อย่างชัดเจน

สำหรับ TCP และ UDP มักใช้ข้อมูลห้ารายการหรือ 5-tuple เพื่อแยก Flow ได้แก่ Protocol, Source IP, Source Port, Destination IP และ Destination Port ดังนั้นการค้นหาว่าแพ็กเก็ตตอบกลับเป็นของเครื่องใด ไม่จำเป็นต้องใช้เพียง Public IP และ Public Port เท่านั้น บางระบบใช้ข้อมูลปลายทางร่วมด้วย ทำให้ใช้ External IP และ Port เดิมกับการเชื่อมต่อที่มีปลายทางต่างกันได้

ใน Stateful NAT ของ Linux nftables แพ็กเก็ตแรกของ Flow ใช้เลือกกฎและสร้าง NAT Binding ส่วนแพ็กเก็ตถัดไปใช้ Binding เดิม การเปลี่ยนกฎจึงอาจยังไม่เปลี่ยนผลของ Connection ที่เปิดค้างอยู่ ต้องทดสอบด้วย Connection ใหม่หรือจัดการ Session ที่เกี่ยวข้องก่อน

2.3 Checksum, ICMP และแพ็กเก็ตที่ไม่มีพอร์ต

การเปลี่ยน IPv4 Address กระทบ IPv4 Header Checksum และอาจกระทบ TCP หรือ UDP Checksum ซึ่งใช้ IP Address ประกอบการคำนวณด้วย อุปกรณ์ NAT จึงต้องปรับค่า Checksum ที่ได้รับผลจากการแปลงตามกติกาของโปรโตคอล

ICMP เช่น Ping ไม่มี TCP หรือ UDP Port แต่มี Identifier ที่ NAT ใช้แยกการสื่อสารได้ ส่วน ICMP Error อาจแนบข้อมูลของแพ็กเก็ตเดิมมาด้วย NAT ต้องจัดการ Address หรือ Identifier ภายในข้อมูลที่แนบนั้น เพื่อให้เครื่องต้นทางเชื่อมโยง Error กับการสื่อสารที่ถูกต้อง

3.1 Static NAT แบบแปลงเฉพาะ IP

Static NAT แบบ Address-only กำหนดความสัมพันธ์ระหว่าง IP เดิมกับ IP ที่ใช้แทนไว้อย่างคงที่ เช่น 10.10.10.50 จับคู่กับ 203.0.113.50 เมื่อทำ Source Translation ที่ก่อนแปลงเป็น 10.10.10.50:51000 หลังแปลงจะเป็น 203.0.113.50:51000 โดยหมายเลขพอร์ตยังคงเดิม

รูปแบบนี้เหมาะกับระบบที่ต้องการใช้ Address อ้างอิงแน่นอน เช่น Server ที่ต้องออกไปหาคู่ค้าด้วย Source IP ที่กำหนดไว้

การจับคู่คงที่ต้องพิจารณาควบคู่กับทิศทางที่อนุญาตให้เริ่ม Session และ Security Policy การสร้าง Static Source NAT เพียงกฎเดียวไม่ได้รับประกันว่าอุปกรณ์ทุกยี่ห้อจะสร้างทางรับ Connection ใหม่จากภายนอกให้ด้วยโดยอัตโนมัติ

3.2 Dynamic NAT แบบแปลงเฉพาะ IP

Dynamic NAT แบบ Address-only เลือก IP จาก Pool มาจับคู่กับเครื่องภายในตามความต้องการ เช่น เครือข่ายภายใน 10.10.10.0/24 กับ External Pool 203.0.113.100 ถึง 203.0.113.109 เมื่อมีเครื่องเริ่มสื่อสารออกไป อุปกรณ์เลือก Address ที่ยังว่างใน Pool ให้ หลัง Mapping หมดอายุหรือถูกคืนทรัพยากร Address นั้นจึงพร้อมให้เครื่องอื่นใช้

สำหรับตัวอย่างที่มี 10 Address หากเป็นการจัดสรรแบบหนึ่ง IP ภายนอกต่อหนึ่งเครื่องภายในและไม่มี PAT จะรองรับเครื่องที่มี Mapping พร้อมกันได้ 10 เครื่อง แต่แต่ละเครื่องเปิดหลาย Connection ผ่าน Address ที่ได้รับได้ จึงไม่ใช่ข้อจำกัดว่าเปิดได้เพียง 10 Connection รวมกันทั้งระบบ

เมื่อ Pool เต็ม เครื่องที่ยังไม่มี Mapping อาจเริ่มการสื่อสารไม่ได้ แม้ Bandwidth ของลิงก์จะยังเหลืออยู่ก็ตาม

3.3 Dynamic PAT, NAPT และ NAT Overload

PAT หรือ Port Address Translation ใช้ IP และหมายเลขพอร์ตร่วมกัน ส่วนคำว่า NAPT หมายถึง Network Address Port Translation การจัดสรรแบบ Dynamic PAT ทำให้หลายเครื่องแชร์ IP ภายนอกเดียวกันได้ และอาจใช้ Pool ที่มีหลาย IP ด้วย

ตัวอย่างเมื่อสองเครื่องติดต่อ TCP Server เดียวกัน 10.10.10.11:50000 อาจถูกแปลงเป็น 203.0.113.10:40001 ส่วน 10.10.10.12:50000 ถูกแปลงเป็น 203.0.113.10:40002 ทั้งสองเครื่องใช้ Source Port เดิมเหมือนกัน แต่ NAT เลือก Mapping ภายนอกที่แยกคำตอบกลับได้

PAT ไม่จำเป็นต้องเปลี่ยนพอร์ตทุกครั้ง บางอุปกรณ์พยายามรักษาพอร์ตเดิมไว้ เรียกว่า Port Preservation เมื่อรักษาพอร์ตเดิมไม่ได้จึงเลือกพอร์ตอื่น การเห็นหมายเลขพอร์ตเดิมหลัง NAT จึงยังสรุปไม่ได้ว่าเป็นการแปลงแบบ Address-only

3.4 Static PAT และ Port Forwarding

Static PAT กำหนด Mapping ของ IP, Protocol และพอร์ตไว้อย่างคงที่ การนำไปใช้รับบริการจากภายนอกมักเรียกว่า Port Forwarding โดยพอร์ตภายนอกกับภายในจะเหมือนกันหรือต่างกันก็ได้

IP ภายนอกเดียวจึงให้บริการหลายระบบได้ โดยใช้ Protocol และพอร์ตแยกปลายทาง กฎ TCP/443 กับ UDP/443 เป็นคนละ Mapping แม้ตัวเลขพอร์ตเหมือนกัน

การแปลง 443 ไปเป็น 8443 เปลี่ยนเพียงปลายทางระดับพอร์ต บริการภายในต้องรองรับโปรโตคอลที่ Client ใช้งานเอง NAT ไม่ได้ถอดรหัส TLS หรือแปลง HTTPS เป็น HTTP ให้จากการเปลี่ยนพอร์ตเพียงอย่างเดียว

4.1 Source NAT แปลงข้อมูลต้นทาง

Source NAT หรือ SNAT เปลี่ยน Source IP และอาจเปลี่ยน Source Port รูปแบบที่พบในการออกอินเทอร์เน็ตคือต้นทางก่อนแปลง 10.10.10.11:51514 เปลี่ยนเป็นต้นทางหลังแปลง 203.0.113.10:40001

SNAT ใช้ได้ทั้งกับ Static Address Mapping, Dynamic Address Pool และ Dynamic PAT การเลือกขึ้นอยู่กับว่าต้องการ Address คงที่ ต้องการจัดสรร IP เป็นรายเครื่อง หรือต้องการให้หลายเครื่องแชร์ IP ผ่านพอร์ต

แม้จะใช้กับงานขาออกบ่อย แต่คำว่า Source หมายถึงข้อมูลต้นทางของแพ็กเก็ต เช่น ใน Hairpin NAT อาจต้องทำ SNAT ให้การเชื่อมต่อระหว่าง Client กับ Server ภายในย้อนกลับผ่าน Gateway ด้วย

4.2 Destination NAT แปลงข้อมูลปลายทาง

Destination NAT หรือ DNAT เปลี่ยน Destination IP และอาจเปลี่ยน Destination Port เช่น การรับ HTTPS จากภายนอกแล้วส่งต่อไปยัง Server ภายใน ก่อน DNAT เป็น 198.51.100.60:51000 ไปยัง 203.0.113.50:443 หลัง DNAT เป็น 198.51.100.60:51000 ไปยัง 10.10.10.50:443

Source IP ของ Client ยังอยู่ครบในตัวอย่างนี้ Server จึงเห็นต้นทางเป็น 198.51.100.60 เว้นแต่จะมี SNAT หรืออุปกรณ์ตัวกลางอื่นเปลี่ยนข้อมูลต้นทางเพิ่มเติม

สำหรับ Stateful DNAT อุปกรณ์ใช้สถานะเดิมแปลงแพ็กเก็ตตอบกลับให้ Client เห็น Source เป็น 203.0.113.50:443 จึงไม่ต้องสร้างกฎ SNAT เพิ่มเพียงเพื่อรองรับคำตอบของ Session นั้น แต่การให้ Server เริ่ม Connection ใหม่ออกไปด้วย Public IP เดียวกันเป็นอีกข้อกำหนดหนึ่ง

อุปกรณ์บางชนิดเลือกปลายทางจาก Server หลายเครื่องได้ เช่น PAN-OS มี Dynamic IP Destination NAT พร้อม Session Distribution โดยใช้วิธีอย่าง Round-robin หรือ Source IP Hash ความสามารถนี้ต้องแยกจาก Application Load Balancer ซึ่งอาจมี Health Check หรือการตัดสินใจจาก HTTP Content เพิ่มเติม

REDIRECT ใน Linux เป็น DNAT รูปแบบพิเศษที่ส่งทราฟฟิกเข้าหาเครื่องที่กำลังทำ NAT เอง เช่น ส่งต่อไปยังบริการ Proxy บน Gateway ซึ่งแตกต่างจาก DNAT ที่ส่งต่อไปอีกเครื่องหนึ่ง และแตกต่างจาก HTTP Redirect ซึ่งเป็นการให้ Client ไปเรียก URL ใหม่

4.3 Twice NAT แปลงทั้งต้นทางและปลายทาง

Twice NAT ในความหมายเชิงกลไกคือการแปลงทั้ง Source และ Destination ใช้ได้กับการเชื่อมเครือข่ายที่มี IP ซ้ำกัน เพราะทั้งชื่อที่ใช้เรียกปลายทางและ Address ที่ปลายทางใช้ตอบกลับอาจต้องมีค่าทดแทน

สมมติว่า Site A และ Site B ใช้ 192.168.1.0/24 เหมือนกัน โดย Client ที่ Site A คือ 192.168.1.10 และ Server ที่ Site B คือ 192.168.1.20 กำหนดให้ Site A เรียก Server B ผ่าน 10.20.1.20 และให้ Site B มองเห็น Client A เป็น 10.10.1.10 แพ็กเก็ตก่อนแปลงจึงเป็น 192.168.1.10 ไปยัง 10.20.1.20 และหลังแปลงเข้าสู่ Site B เป็น 10.10.1.10 ไปยัง 192.168.1.20

Client ไม่ต้องเรียก Address ที่ชนกับ Subnet ของตนเอง และ Server มี Address สำหรับตอบกลับที่แยกจากเครือข่ายภายในฝั่งตน การออกแบบยังต้องมี Route สำหรับ Address ที่ใช้แทน รวมถึง DNS และ VPN Policy ที่ตรงกับจุดก่อนและหลังการแปลง

คำว่า Full NAT บางผลิตภัณฑ์ใช้หมายถึงการทำ SNAT และ DNAT ร่วมกัน ส่วน Twice NAT บน Cisco ASA ยังเป็นชื่อวิธีกำหนดกฎที่ผูก Source และ Destination เข้าด้วยกัน โดยด้านใดด้านหนึ่งอาจใช้ Identity Mapping ได้ จึงต้องอ่านความหมายตามแพลตฟอร์มด้วย

4.4 ทิศทางการเริ่ม Session และ Bidirectional NAT

การเริ่ม Session จากภายในออกไปย่อมมีแพ็กเก็ตตอบกลับจากภายนอกด้วย ดังนั้นการรับแพ็กเก็ตขากลับได้ กับการให้ภายนอกเริ่ม Session ใหม่เข้ามาได้ เป็นคนละเงื่อนไข

Bidirectional NAT ใช้อธิบาย Mapping ที่รองรับการเริ่ม Session ใหม่จากทั้งสองฝั่งตาม Security Policy ที่อนุญาต การตั้ง Static Source NAT บางระบบมีตัวเลือก Bidirectional ขณะที่บางระบบต้องกำหนด Destination Translation เพิ่มอย่างชัดเจน

5.1 Policy NAT และ Conditional NAT

Policy NAT เลือก Mapping ตามเงื่อนไข เช่น Source, Destination, Service, Interface หรือ Zone ทำให้เครื่องเดียวใช้ Address หลังแปลงต่างกันตามงานได้ เช่น 10.10.10.50 เมื่อติดต่อ Partner A ใช้ Source IP 203.0.113.50 เมื่อออกอินเทอร์เน็ตใช้ 203.0.113.10 และเมื่อไปสาขาผ่าน VPN คง Source IP เดิม

Policy NAT ต้องสอดคล้องกับ Routing เช่น กฎเลือก Source IP ของ WAN A แต่ทราฟฟิกกลับถูกส่งออก WAN B อาจทำให้เส้นทางตอบกลับไม่ตรงกับที่ออกแบบไว้ การเลือกว่าจะแปลงเป็น Address ใดจึงต้องตรวจร่วมกับการเลือกเส้นทางส่งต่อ

5.2 No-NAT, NAT Exemption และ Identity NAT

No-NAT และ NAT Exemption ใช้เรียกการกำหนดให้ทราฟฟิกบางกลุ่มไม่ถูกแปลง เช่น ให้การสื่อสารระหว่างสำนักงานกับสาขาคง IP เดิม แต่ให้การออกอินเทอร์เน็ตใช้ PAT วิธีตั้งข้อยกเว้นขึ้นอยู่กับอุปกรณ์

บน Cisco ASA สามารถใช้ Identity NAT ซึ่งเป็น Static Mapping ที่จับคู่ Address กับตัวเอง ความสัมพันธ์ของคำทั้งสามจึงเป็นดังนี้ Identity NAT เป็นวิธีสร้าง Mapping แบบพิเศษ ส่วน No-NAT หรือ NAT Exemption บอกผลที่ต้องการจากนโยบาย อุปกรณ์อื่นอาจใช้กฎที่ไม่กำหนด Source และ Destination Translation แทนการสร้าง Identity Mapping

สำหรับระบบที่ใช้กฎแรกที่ตรงเงื่อนไข ต้องวางข้อยกเว้นให้ถูกพิจารณาก่อนกฎที่ครอบคลุมกว้างกว่า มิฉะนั้นทราฟฟิกไปสาขาอาจถูกกฎ PAT สำหรับอินเทอร์เน็ตจับไปก่อน และแม้จะไม่ทำ NAT ก็ยังต้องมี Security Policy อนุญาตการสื่อสารนั้น

6.1 Masquerade ใช้ IP ของ Interface ขาออก

Masquerade ใน Linux เป็นรูปแบบของ SNAT ที่ใช้ Address ของ Output Interface เป็น Address หลังแปลง เหมาะกับ WAN ที่ IP อาจเปลี่ยน เพราะกฎไม่ต้องผูกกับตัวเลข IP ภายนอกค่าเดิมตลอดเวลา

คำว่า Dynamic ใน Dynamic NAT และการที่ WAN ได้ Dynamic IP เป็นคนละเรื่องกัน Dynamic NAT กล่าวถึงการจัดสรร Mapping ส่วน Dynamic WAN IP กล่าวถึง Address ที่ Interface ได้รับ การเลือกใช้ IP ของ Interface ช่วยให้กฎติดตาม Address ใหม่ได้ แต่ Connection ที่ใช้ Address เก่าอาจต้องสร้างใหม่เมื่อ WAN เปลี่ยน IP

6.2 Network NAT, Subnet NAT และ NETMAP

การแปลงแบบ Network หรือ Prefix Mapping กำหนดความสัมพันธ์ของ Address ทั้งช่วง เช่น 10.10.10.0/24 จับคู่กับ 172.20.10.0/24 หากใช้รูปแบบที่รักษาบิตส่วน Host ไว้ 10.10.10.11 จะกลายเป็น 172.20.10.11 และ 10.10.10.80 จะกลายเป็น 172.20.10.80

วิธีนี้จึงไม่ต้องเขียน Mapping ทีละเครื่อง ลักษณะนี้สัมพันธ์กับการแปลง Address แบบคงที่ทั้ง Prefix และนำไปใช้กับ Source หรือ Destination Translation ตามงานได้ ตัวอย่างความสามารถดังกล่าวมีใน Prefix NAT Mapping ของ nftables

6.3 Hairpin NAT, NAT Loopback และ NAT Reflection

Hairpin NAT ช่วยให้ Client ภายในเรียก Server ที่อยู่หลัง NAT เดียวกันผ่าน Address ภายนอกของบริการ เช่น ผู้ใช้ในสำนักงานเรียกชื่อเว็บที่ DNS ตอบเป็น Public IP ของสำนักงานเอง

สมมติว่า Client คือ 10.10.10.11 Server คือ 10.10.10.50 LAN Gateway คือ 10.10.10.1 และ Public Service IP คือ 203.0.113.50 หากทำเฉพาะ DNAT เมื่อ Client และ Server อยู่ใน Subnet เดียวกัน Server อาจตอบตรงถึง Client โดยไม่ย้อนผ่าน Gateway ทำให้คำตอบมี Source เป็น 10.10.10.50 ทั้งที่ Client เรียก 203.0.113.50

แนวทางหนึ่งคือทำ SNAT เพิ่ม ให้ Server เห็นต้นทางเป็น Gateway แล้วตอบกลับผ่าน Gateway ซึ่งมีสถานะสำหรับแปลงกลับให้ Client เห็นคู่สนทนาเป็น Public IP เดิม ผลข้างเคียงคือ Server เห็น Source เป็น Gateway แทน IP จริงของ Client ความจำเป็นในการทำ SNAT เพิ่มขึ้นอยู่กับเส้นทางตอบกลับ ไม่ใช่ข้อกำหนดว่า Hairpin ทุก Topology ต้องใช้ LAN IP ของ Gateway เสมอ

อีกทางเลือกคือ Split DNS ให้ชื่อบริการเดียวกันตอบเป็น Internal IP สำหรับผู้ใช้ภายใน และตอบเป็น External IP สำหรับผู้ใช้ภายนอก อย่างไรก็ตาม DNS เปลี่ยน Address ได้แต่เปลี่ยนพอร์ตไม่ได้ หากภายนอกใช้ 443 แต่บริการภายในรับเฉพาะ 8443 การเปลี่ยนคำตอบ DNS อย่างเดียวอาจยังไม่ทำให้ Client ใช้บริการได้

6.4 Double NAT ผ่าน NAT สองชั้น

Double NAT เกิดเมื่อทราฟฟิกผ่านการแปลงสองจุด เช่น Client 192.168.10.20 ผ่าน Router ภายในที่มี WAN เป็น 192.168.1.2 แล้วผ่าน Router อินเทอร์เน็ตที่มี WAN เป็น 203.0.113.10 อีกชั้นหนึ่ง

การรับ Connection ใหม่จากภายนอกต้องผ่าน Mapping และ Filtering ของทั้งสองชั้น การสร้าง Port Forward ที่ Router ชั้นในจึงไม่ได้สร้าง Mapping ที่ Router ชั้นนอกตามไปด้วย

Double NAT กล่าวถึงจำนวนชั้นการแปลง ส่วน Twice NAT กล่าวถึงการแปลงทั้ง Source และ Destination ของแพ็กเก็ต สองคำนี้จึงใช้แทนกันไม่ได้

6.5 CGNAT, Carrier-Grade NAT และ Large-Scale NAT

CGNAT คือ NAT ที่อยู่ในเครือข่ายผู้ให้บริการ เพื่อให้ลูกค้าหลายรายแชร์ Public IPv4 ร่วมกัน ลูกค้าจึงอาจควบคุม NAT บน Router ของตนเองได้ แต่ไม่มีสิทธิ์กำหนด Mapping บน CGN ของผู้ให้บริการโดยตรง

ช่วง Address ที่สงวนไว้สำหรับ Shared Address Space คือ 100.64.0.0/10 ซึ่งแยกจาก Private Address ตาม RFC 1918 และไม่ใช่ Public Address สำหรับ Route ทั่วอินเทอร์เน็ต การพบ WAN Address ในช่วงนี้เป็นเหตุให้ตรวจสอบว่ามี CGN อยู่ด้านหน้าหรือไม่ โดยยังต้องยืนยัน Topology กับผู้ให้บริการ

เมื่อมี NAT ทั้งที่ Router ลูกค้าและที่ผู้ให้บริการ จะได้รูปแบบที่เรียกว่า NAT444 เลข 444 อ้างถึงพื้นที่ Address ของ IPv4 สามชุด ในรูปแบบนี้มีจุดแปลงสองจุด ไม่ใช่ NAT สามเครื่อง และ CGNAT ก็ติดตั้งโดยไม่มี NAT ชั้นลูกค้าได้เช่นกัน

การเปิดบริการจากภายนอกต้องมีช่องทางที่ผ่าน CGN ได้ เช่น Mapping ที่ผู้ให้บริการจัดสรรให้ หรือสถาปัตยกรรมที่เชื่อมต่อออกไปหา Relay หรือ Tunnel การตั้ง DDNS เปลี่ยนเพียงความสัมพันธ์ของชื่อกับ Address ไม่ได้สร้าง Mapping บน CGN ตามไปด้วย

6.6 Port Block Allocation และ Deterministic NAT

สองคำนี้เกี่ยวข้องกับการจัดสรรพอร์ตและการติดตามผู้ใช้ โดยเฉพาะในระบบที่แชร์ IPv4 จำนวนมาก

Port Block Allocation หรือ PBA จัดสรรพอร์ตเป็นชุดให้ผู้ใช้หรือ Address ภายใน แทนการจัดสรรแบบอิสระทีละ Connection ส่วน Deterministic NAT ใช้กฎที่คำนวณความสัมพันธ์ของผู้ใช้กับ Public IP และช่วงพอร์ตย้อนกลับได้ ช่วยลดข้อมูล Log ที่ต้องบันทึกในบางสถาปัตยกรรม

PBA ไม่จำเป็นต้องเป็น Deterministic ทั้งหมด เพราะบางระบบจัดสรร Port Block แบบ Dynamic หรือมีการจัดสรรเพิ่มเติมเมื่อชุดแรกไม่พอ รายละเอียดเหล่านี้มีผลต่อข้อมูลที่ต้องเก็บเพื่อระบุผู้ใช้ย้อนหลัง

7.1 Stateful NAT และ Stateless NAT

Stateful NAT อาศัยสถานะของ Mapping หรือ Flow เพื่อแปลงแพ็กเก็ตที่เกี่ยวข้องกัน เช่น Dynamic PAT เมื่อสถานะสูญหาย Connection ที่เปิดอยู่จึงอาจใช้งานต่อไม่ได้ แม้กฎ NAT ยังอยู่ครบ

Stateless NAT คำนวณการแปลงจากกฎและข้อมูลในแพ็กเก็ต โดยไม่ต้องมี Dynamic Binding หรือสถานะ NAT ราย Flow ตัวอย่างคือการแปลงแบบ SIIT และ NPTv6 การไม่มี State ในส่วนของ NAT ไม่ได้ห้ามอุปกรณ์เดียวกันเก็บ State เพื่อทำ Stateful Firewall

Static และ Stateless อธิบายคนละเรื่อง Static บอกว่า Mapping ถูกกำหนดคงที่ ส่วน Stateless บอกว่าการแปลงไม่ต้องอาศัยสถานะราย Flow จึงมี Static Mapping ที่ทำงานร่วมกับ Stateful Connection Tracking ได้

7.2 Mapping Behavior และ Filtering Behavior

เมื่อ Endpoint ภายในติดต่อหลายปลายทาง ต้องแยกพฤติกรรมสองด้าน Mapping Behavior บอกว่า NAT ใช้ Mapping เดิมต่อหรือไม่เมื่อปลายทางเปลี่ยน ส่วน Filtering Behavior บอกว่า Endpoint ภายนอกใดส่งแพ็กเก็ตเข้ามายัง Mapping นั้นได้

ตัวอย่างเช่น อุปกรณ์สามารถมี EIM พร้อม APDF ได้ คือใช้ Mapping เดิมกับหลายปลายทาง แต่ยังกรองแพ็กเก็ตขาเข้าตาม Remote Endpoint ที่เคยติดต่อ การรู้ Mapping Behavior เพียงอย่างเดียวจึงยังไม่พอจะสรุปว่า Peer ภายนอกใดติดต่อเข้ามาได้

7.3 Full Cone, Restricted Cone และ Symmetric NAT

คำเรียกแบบ Cone และ Symmetric มาจากแบบจำลอง NAT สำหรับ UDP ใน STUN รุ่นแรก แต่การอธิบายอุปกรณ์จริงด้วย Mapping และ Filtering แยกกันให้รายละเอียดได้มากกว่า

Full Cone ไม่ได้หมายความว่าอุปกรณ์เปิดทุกพอร์ตของทุกเครื่องภายในโดยไม่มี Mapping และไม่ได้ยกเลิก Security Policy อื่น ส่วนคำว่า Symmetric NAT ต้องอ่านตามนิยามของเครื่องมือหรือผลิตภัณฑ์ที่รายงานผล เพราะคำเรียกแบบเก่าอาจไม่บอกพฤติกรรมทุกด้านของระบบ

8.1 Stateful NAT64 และ DNS64

Stateful NAT64 ให้ IPv6 Client ติดต่อ IPv4 Server โดยจัดสรร IPv4 Address และ Transport Identifier ฝั่งภายนอก แล้วเก็บสถานะเพื่อแปลงคำตอบกลับเป็น IPv6 คำตอบของ Session เดิมย้อนกลับผ่าน NAT64 ชุดเดียวกันได้ ไม่ต้องสร้าง NAT46 อีกชุดเพื่อรับคำตอบ แต่การให้ IPv4 Host เริ่ม Session ใหม่เข้ามายัง IPv6 Host ต้องมี Mapping และเงื่อนไขรองรับ เช่น Static Binding

DNS64 ช่วยสังเคราะห์ AAAA Record จาก A Record เพื่อให้ IPv6 Client ได้ Address ที่ชี้ผ่าน Translator ไปยัง IPv4 Server DNS64 มีหน้าที่ด้านการตอบ DNS ส่วน NAT64 รับผิดชอบการแปลงแพ็กเก็ต

ตัวอย่างการฝัง IPv4 ใน IPv6 โดยใช้ Prefix แบบ /96 สำหรับเอกสาร IPv4 Server 192.0.2.80 กับ Translation Prefix 2001:db8:64::/96 จะได้ IPv6 ที่ใช้แทนเป็น 2001:db8:64::c000:250 โดยส่วนท้าย c000:250 มาจาก 192.0.2.80 ในรูปเลขฐานสิบหก

DNS64 เพียงอย่างเดียวไม่แก้แอปพลิเคชันที่ใช้ IPv4 Literal หรือเรียกใช้ IPv4 โดยไม่ผ่าน DNS และการใช้งานร่วมกับ DNSSEC ต้องออกแบบตำแหน่งการตรวจสอบคำตอบให้เหมาะสม

8.2 SIIT, Stateless Translation และ SIIT-DC

SIIT หรือ Stateless IP/ICMP Translation แปลง Header ระหว่าง IPv4 และ IPv6 โดยใช้กฎ Address Mapping ที่กำหนดไว้ ไม่สร้าง Dynamic NAT Binding ราย Flow หลักการแปลงอธิบายใน RFC 7915 ซึ่งมาแทน RFC 6145

การใช้ Stateless Translation ต้องเตรียม Address Plan ให้รองรับการแปลงกลับได้ ตัวอัลกอริทึม SIIT เองไม่ได้ทำหน้าที่แชร์ IPv4 แบบ Dynamic PAT

SIIT-DC นำแนวคิดนี้ไปใช้กับ Data Center เพื่อให้บริการในเครือข่าย IPv6 เข้าถึงได้จาก IPv4 ผ่าน Border Relay และ Address Mapping ที่กำหนด จัดเป็นสถาปัตยกรรมการให้บริการ ไม่ใช่ชื่อชนิด Mapping เพิ่มเติม

8.3 464XLAT

464XLAT รวม Translator สองส่วนเพื่อรองรับแอปพลิเคชัน IPv4 ผ่านเครือข่าย IPv6 โดย CLAT ทำ Stateless IPv4 ไป IPv6 ฝั่งลูกค้า ส่วน PLAT ทำ Stateful NAT64 ไปยัง IPv4 ฝั่งบริการ จึงรองรับกรณีที่แอปพลิเคชันยังต้องใช้ IPv4 ซึ่ง DNS64 เพียงอย่างเดียวจัดการไม่ได้

8.4 NAT66 และ NPTv6

NAT66 เป็นชื่อกว้างของการแปลง IPv6 เป็น IPv6 ส่วน NPTv6 ตาม RFC 6296 เป็นการแปลง Prefix แบบเฉพาะ ซึ่งมีคุณสมบัติ Stateless, Bidirectional และ Checksum-Neutral โดยเอกสารดังกล่าวเผยแพร่ในหมวด Experimental

NPTv6 ไม่ใช้การรวมหลายเครื่องให้แชร์ Address เดียวด้วยพอร์ตแบบ PAT อัลกอริทึมอาจปรับส่วนอื่นของ IPv6 Address เพื่อชดเชยผลจากการเปลี่ยน Prefix ทำให้ Transport Checksum ยังคงใช้ได้โดยไม่ต้องแก้ TCP หรือ UDP Header

จึงไม่ควรอธิบาย NPTv6 ว่าเปลี่ยน Prefix แล้วคงทุกบิตส่วนที่เหลือเสมอ และการไม่แก้ Transport Header ก็ไม่ได้รับประกันว่าแอปพลิเคชันที่ฝัง IP ไว้ใน Payload จะไม่มีผลกระทบ

8.5 NAT-PT และสถาปัตยกรรม DS-Lite, MAP-T, MAP-E

NAT-PT และ NAPT-PT เป็นแนวทางแปลง IPv4 กับ IPv6 รุ่นเก่า RFC 4966 เปลี่ยนสถานะของ NAT-PT ไปเป็น Historic เนื่องจากข้อจำกัดด้านสถาปัตยกรรม การอ่านเอกสารเก่าจึงควรแยกชื่อเหล่านี้จาก NAT64 และ SIIT

DS-Lite ห่อ IPv4 ผ่าน IPv6 ไปยัง AFTR โดยมี NAT44 ฝั่งผู้ให้บริการ MAP-T ใช้ Translation และกฎ Mapping ของ Address และ Port Set ส่วน MAP-E ใช้ Encapsulation ของ IPv4 ผ่าน IPv6 โดยฝั่งลูกค้าอาจใช้ NAPT44 ตามชุดพอร์ตที่ได้รับ

การทำ Translation เปลี่ยน Header ระหว่างโปรโตคอล ส่วน Encapsulation ห่อแพ็กเก็ตเดิมไว้ภายในอีกโปรโตคอลหนึ่ง จึงไม่ควรเรียกรวมว่าทั้งหมดเป็น NAT64

10.1 SIP Register สำเร็จ แต่เสียงไม่ผ่าน

ระบบ SIP แยก Signaling ที่ใช้สร้างและควบคุมการโทร ออกจาก Media เช่น RTP ที่ส่งเสียงหรือวิดีโอ การ Register สำเร็จจึงยังไม่ยืนยันว่า Media Path ใช้งานได้ครบทั้งสองทิศทาง

SIP ส่งรายละเอียด Media ผ่าน SDP ซึ่งระบุ Address และพอร์ตไว้ในเนื้อหาข้อความ เช่นบรรทัด c=IN IP4 10.10.10.50 และ m=audio 20000 RTP/AVP 0 8 ในตัวอย่างนี้ SDP ประกาศ Address สำหรับ Media เป็น 10.10.10.50 และพอร์ตเสียงเป็น 20000 การแปลง IP Header ด้านนอกไม่ได้เปลี่ยนข้อความเหล่านี้ให้เอง

หากคู่สนทนาอยู่อีกเครือข่ายและส่งเสียงไปยัง Private IP ที่เข้าถึงไม่ได้ อาจเกิดอาการไม่มีเสียงหรือได้ยินเพียงด้านเดียว การตรวจจึงต้องดูทั้ง SIP, SDP และ RTP ที่รับส่งจริง ไม่ใช่ตรวจเฉพาะสถานะ Registration

10.2 SIP ALG และ SBC

ALG หรือ Application Layer Gateway ช่วยจัดการโปรโตคอลที่บรรจุ Address หรือพอร์ตไว้ใน Payload โดยอาจแก้ข้อความและสร้างสถานะที่เกี่ยวข้องเพิ่มเติม แต่การรองรับขึ้นอยู่กับความเข้าใจโปรโตคอลของ ALG และความเข้ากันได้กับแอปพลิเคชัน

สำหรับ SIP ควรกำหนดให้ชัดว่า PBX, Endpoint, SBC หรือ ALG ตัวใดรับผิดชอบการประกาศ Address และการจัดเส้นทาง Media การแก้ข้อมูลซ้ำหลายจุดอาจทำให้ผลลัพธ์ไม่ตรงกับที่ระบบปลายทางคาดไว้ จึงควรตรวจจาก Packet Capture แทนการตัดสินใจเปิดหรือปิด ALG โดยไม่ดูรูปแบบระบบ

SBC จัดการ SIP Signaling และ Media ตามความสามารถของผลิตภัณฑ์ เช่น ทำ Media Relay ควบคุมการเข้าถึง และปรับข้อมูลที่เปิดเผยออกนอกเครือข่าย การตั้ง Static NAT ให้ PBX จึงไม่ได้เพิ่มหน้าที่เหล่านี้ให้ NAT Gateway โดยอัตโนมัติ

เมื่อ Signaling ถูกเข้ารหัส อุปกรณ์ที่ไม่ได้เป็นจุดสิ้นสุดของการเข้ารหัสจะไม่สามารถอ่านและแก้ Payload ได้เหมือนข้อความที่ไม่เข้ารหัส การออกแบบ SIP over TLS จึงต้องคำนึงถึงตำแหน่งของอุปกรณ์ที่มีหน้าที่จัดการข้อความด้วย

10.3 IPsec NAT-T กับ NAT Exemption

NAT-T ของ IPsec ใช้การห่อ ESP ใน UDP เพื่อส่งผ่าน NAT โดยทั่วไปเกี่ยวข้องกับ UDP/4500 ส่วน NAT Exemption กำหนดให้ทราฟฟิกบางชุดคง Address เดิม ทั้งสองอย่างเกิดร่วมกันได้ในระบบเดียว เช่น แพ็กเก็ตภายใน VPN จาก 10.10.10.0/24 ไปยัง 10.20.20.0/24 คง IP เดิมตามกฎ No-NAT ขณะที่แพ็กเก็ตด้านนอกของ VPN Gateway ต้องผ่าน Router ที่ทำ NAT และใช้ NAT-T เพื่อส่ง ESP ผ่าน NAT

การตรวจปัญหาต้องแยก Inner Packet ภายใน Tunnel ออกจาก Outer Packet ที่ใช้ส่ง VPN ผ่านเครือข่ายภายนอก เครือข่ายที่มี IP ซ้ำกันอาจจำเป็นต้องแปลง Inner Address ด้วย จึงไม่ใช่ทุก VPN ที่ต้องใช้ No-NAT เสมอไป

ESP ใช้ IP Protocol Number 50 ไม่ใช่ TCP หรือ UDP Port 50 ส่วน AH ปกป้องข้อมูลบางส่วนของ IP Header จึงมีข้อขัดแย้งกับการเปลี่ยน Address ระหว่างทาง รายละเอียดเหล่านี้ทำให้ IPsec ต้องมีวิธีรับมือ NAT โดยเฉพาะ

10.4 โปรโตคอลอื่นที่ฝัง Address ใน Payload

FTP บางโหมดและโปรโตคอลบางชนิดประกาศ Address หรือพอร์ตของการเชื่อมต่อเพิ่มเติมไว้ใน Control Channel การแปลง Header อย่างเดียวจึงอาจไม่พอ ต้องเลือกโหมดการทำงานที่เหมาะสม ใช้กลไก Traversal หรือ ALG ที่รองรับ และเมื่อ Payload เข้ารหัส การแก้ข้อความระหว่างทางยิ่งมีข้อจำกัด

11.1 เส้นทางขาไปและขากลับ

Stateful NAT ต้องให้แพ็กเก็ตที่เกี่ยวข้องผ่านจุดที่มีสถานะถูกต้อง หากขาไปผ่าน Firewall A แต่ขากลับผ่าน Firewall B ที่ไม่มี State เดียวกัน การแปลงกลับหรือการตรวจ Session อาจล้มเหลว ระบบ HA จึงต้องพิจารณาทั้งการซิงโครไนซ์ State และเส้นทางรับส่ง

Public IP ที่ใช้ในกฎ NAT ต้องมีเส้นทางมาถึง Gateway ด้วย เช่น มี Upstream Route หรือการตอบ ARP ที่เหมาะสม การเพิ่ม Address ลงใน NAT Rule ไม่ได้รับประกันว่าเครือข่ายต้นทางจะส่งแพ็กเก็ตมาถึงอุปกรณ์นั้นเอง

ลำดับการประมวลผลแตกต่างกันตามแพลตฟอร์ม ตัวอย่างเช่น PAN-OS ใช้ Pre-NAT Source และ Destination Address กับ Post-NAT Zone ในการประเมิน Security Policy การคัดลอกสมมติฐานเรื่อง Policy ต้องใช้ IP ก่อนหรือหลัง NAT จากอีกยี่ห้อจึงอาจทำให้กฎไม่ตรงทราฟฟิก

11.2 จำนวนพอร์ตไม่เท่ากับจำนวน Session สูงสุดเสมอไป

คำกล่าวว่า Public IP หนึ่งตัวรองรับได้ 65,535 Sessions ไม่ใช่ข้อจำกัดตายตัวของ NAT ทุกระบบ แม้ TCP และ UDP Port มีขนาด 16 บิต แต่จำนวนที่ใช้ได้จริงขึ้นอยู่กับช่วงพอร์ตที่จัดสรร การสงวนพอร์ต Protocol และวิธีใช้ Mapping ซ้ำกับปลายทางที่ต่างกัน

ตัวอย่างประเมินจากสมมติฐานที่มี Public IP 4 ตัว ใช้พอร์ตได้ 60,000 พอร์ตต่อ IP พิจารณา Protocol เดียว และทุก Connection ติดต่อ Remote IP และ Port เดียวกัน จะได้พื้นที่ Mapping ประมาณ 240,000 รายการ

ตัวเลขนี้ยังไม่ใช่ความสามารถรับ Session ของอุปกรณ์ ต้องตรวจ Concurrent Sessions, อัตราสร้าง Connection ใหม่, Packets per Second, Throughput และทรัพยากรสำหรับ Connection Tracking เพิ่มเติม โดยเฉพาะระบบที่ผู้ใช้จำนวนมากแย่งใช้ Address และพอร์ตชุดเดียวกัน

11.3 Timeout และ Keepalive

UDP ไม่มีขั้นตอนปิด Connection แบบ TCP NAT จึงใช้ Timer และพฤติกรรมการรับส่งเพื่อรักษาหรือล้างสถานะ ส่วน TCP มีสถานะการเชื่อมต่อและ Timeout หลายช่วง

Timeout ที่สั้นเกินไปอาจทำให้ Mapping หายระหว่างช่วงที่แอปพลิเคชันยังต้องใช้งาน ส่วน Timeout ที่ยาวเกินไปทำให้สถานะค้างกินทรัพยากร การตั้ง Keepalive จึงต้องสัมพันธ์กับ Timeout ของอุปกรณ์ที่อยู่ในเส้นทาง ไม่ควรนำค่า Default ของ Firewall รุ่นหนึ่งไปถือว่าใช้กับทุกระบบ

11.4 Logging และการระบุผู้ใช้

ในระบบที่แชร์ Public IP การทราบ IP เพียงอย่างเดียวไม่พอจะระบุผู้ใช้ ต้องเชื่อมโยง Public IP, พอร์ต, Protocol และเวลากับ Mapping หรือ Port Block ที่จัดสรรให้ผู้ใช้รายนั้น

หากระบบใช้ External IP และ Port เดิมกับหลาย Connection ที่มีปลายทางต่างกัน การวิเคราะห์อาจต้องใช้ Destination IP และ Port ร่วมด้วยตามวิธีจัดสรรของอุปกรณ์ จึงควรตรวจรูปแบบ NAT ก่อนกำหนดฟิลด์ Log ที่จะเก็บ

ในทางปฏิบัติ ควรตรวจด้วยว่านาฬิกาของ NAT Gateway ระบบยืนยันตัวตน และระบบเก็บ Log สัมพันธ์กันเพียงพอสำหรับจับคู่เหตุการณ์ โดยเฉพาะเมื่อ Mapping ถูกนำกลับมาใช้ใหม่ในเวลาสั้น ๆ

11.5 หน้าที่ของ NAT กับ Firewall

NAT รับผิดชอบการแปลง Address ส่วน Firewall รับผิดชอบนโยบายอนุญาตหรือปฏิเสธทราฟฟิก การที่ Dynamic Mapping บางแบบไม่รับ Connection ใหม่จากภายนอกโดยไม่มีสถานะ ไม่ได้ทดแทนการกำหนด Security Policy และไม่ได้เข้ารหัสข้อมูลที่ส่งผ่าน

IPv6 ใช้ Stateful Firewall เพื่ออนุญาตการเชื่อมต่อออกและคำตอบกลับ พร้อมปฏิเสธ Connection ใหม่จากภายนอกได้โดยไม่ต้องทำ NAT การตัดสินใจใช้ NAT66 หรือ NPTv6 จึงควรมีเหตุผลด้าน Addressing หรือการเชื่อมเครือข่ายรองรับ

12.1 ข้อควรระวังในการตรวจ

ตารางข้างบนเป็นจุดเริ่มต้นการตรวจ ไม่ใช่การยืนยันสาเหตุจากอาการเพียงอย่างเดียว หลักการที่ใช้คือการติดตาม Mapping, State และเส้นทางรับส่ง รวมถึงข้อมูลระดับแอปพลิเคชันเมื่อโปรโตคอลนั้นฝัง Address ไว้ใน Payload

การที่ Ping ขนาดเล็กผ่านยังไม่ยืนยันว่าแพ็กเก็ตทุกขนาดผ่านได้ ต้องตรวจ Fragmentation และ ICMP Error ที่เกี่ยวข้องกับ Path MTU ด้วย โดยเฉพาะการแปลง IPv4 กับ IPv6 ซึ่ง Header มีขนาดต่างกัน

เมื่อแก้กฎแล้ว ให้ทดสอบด้วย Connection ใหม่ก่อน หากจำเป็นต้องล้าง Session ควรเลือกเฉพาะรายการที่เกี่ยวข้องกับการทดสอบ เพื่อไม่ตัดการสื่อสารอื่นที่กำลังใช้งานอยู่

12.2 การบันทึกกฎ NAT ในเอกสารระบบ

ควรระบุให้ครบทั้งวัตถุประสงค์ เงื่อนไขก่อนแปลง ผลหลังแปลง และเส้นทางตอบกลับ

• วัตถุประสงค์ เปิดบริการ HTTPS ให้ผู้ใช้ภายนอก
• เงื่อนไข TCP ไปยัง 203.0.113.10:443
• การแปลง Destination เป็น 10.10.10.20:8443 ไม่เปลี่ยน Source ของ Client
• คำอธิบายกฎ DNAT รวมกับ Static PAT และ NAT44
• เงื่อนไขการทำงาน มี Security Policy อนุญาต Server รับบริการที่ TCP/8443 และคำตอบกลับผ่าน Gateway ที่มีสถานะของ Connection
• การทดสอบ สร้าง Connection ใหม่ ตรวจแพ็กเก็ตก่อนและหลัง NAT ทั้งสองทิศทาง