เลข IP ในเครื่องคุณตอนนี้น่าจะขึ้นต้นด้วย 192.168. หรือ 10. แต่ถ้าเปิดเว็บ ที่บอกว่า "IP ของคุณคือ..." มันจะขึ้นเลขคนละชุดเลย
เลขสองชุดนั้นไม่ได้ขัดกัน มันคือหลักฐานว่ามีอะไรบางอย่างกำลังแปลงที่อยู่ให้คุณ อยู่ตลอดเวลา และสิ่งนั้นคือ NAT
เรื่องที่น่าสนใจคือ NAT ไม่ได้ถูกออกแบบมาให้อยู่ถาวร เอกสารที่นิยามมันเมื่อปี 1994 เป็นเพียงเอกสารประเภท Informational ไม่ใช่มาตรฐาน และเขียนไว้ตรง ๆ ว่า ทางออกระยะยาวคือโพรโทคอลที่มีเลขยาวกว่านี้
สามสิบกว่าปีผ่านไป ทางออกระยะยาวยังมาไม่ถึง และของชั่วคราวชิ้นนั้นอยู่ในบ้าน ทุกหลังบนโลก
หน้านี้ต่อจาก Internet Protocol และ IPv4 Subnet ซึ่งวางเรื่องเลขที่อยู่กับเลขวงส่วนตัวไว้แล้ว
ถ้ายังไม่เคยสังเกต เริ่มตรงนี้
$ ifconfig en0 | grep 'inet '
inet 192.168.1.134 netmask 0xffffff00 broadcast 192.168.1.255
$ curl -s https://api.ipify.org
203.0.113.7สองบรรทัดนี้คือ NAT ทั้งหมดในภาพเดียว — เครื่องคุณเรียกตัวเองว่า 192.168.1.134 ส่วนโลกภายนอกเห็นคุณเป็น 203.0.113.7
และถ้าลองดูว่าตอนนี้เครื่องคุณเปิดการเชื่อมต่ออยู่กี่อัน
$ netstat -an -p tcp | grep ESTABLISHED | wc -l
14ทั้งสิบสี่การเชื่อมต่อนั้นออกอินเทอร์เน็ตด้วยเลขสาธารณะเลขเดียวกันหมด คำถามที่บทความนี้ตอบคือ แล้วคำตอบที่วิ่งกลับมารู้ได้อย่างไรว่าเป็นของอันไหน
เลขไม่พอ และไม่พอมานานแล้ว
IPv4 ใช้เลขที่อยู่ยาว 32 บิต ซึ่งแปลว่ามีเลขทั้งหมด
2^32 = 4,294,967,296 เลขฟังดูเยอะจนน่าจะพอ จนกระทั่งเอาไปหารด้วยจำนวนคนบนโลก
4,294,967,296 ÷ 8,200,000,000 คน = 0.52 เลขต่อคนให้คนละเลขยังไม่พอ และนั่นคือยังไม่นับว่าคนหนึ่งคนมีโทรศัพท์ โน้ตบุ๊ก ทีวี นาฬิกา กล้อง และเครื่องใช้ไฟฟ้าที่ต่อเน็ตได้อีกหลายชิ้น
ทางออกคือ RFC 1918 ซึ่งกันเลขสามช่วงไว้ให้ใช้ซ้ำกันได้ทุกที่
10.0.0.0/8 16,777,216 เลข
172.16.0.0/12 1,048,576 เลข <- ช่วงที่คนลืมบ่อยที่สุด
192.168.0.0/16 65,536 เลขเลขในสามช่วงนี้ห้ามโผล่บนอินเทอร์เน็ต เราเตอร์ทุกตัวบนโลกทิ้งมันทันที ทุกบ้านจึงใช้ 192.168.1.1 เป็นเราเตอร์ได้พร้อมกันโดยไม่ชนกัน
แต่นั่นสร้างปัญหาใหม่ — ถ้าเลขในบ้านใช้บนอินเทอร์เน็ตไม่ได้ แล้วจะออกไป ข้างนอกได้อย่างไร
พฤษภาคม 1994 — ของที่ตั้งใจให้เป็นของชั่วคราว
NAT นิยามไว้ใน RFC 1631 เขียนโดย K. Egevang กับ P. Francis เผยแพร่พฤษภาคม 1994
รายละเอียดที่บอกอะไรได้เยอะคือ สถานะของมันคือ Informational ไม่ใช่ Standards Track — เอกสารที่บอกว่า "นี่คือสิ่งที่คนทำกัน" ไม่ใช่ "นี่คือสิ่งที่ ต้องทำ"
เอกสารระบุปัญหาไว้ชัดว่า
ปัญหาสองข้อที่กดดันอินเทอร์เน็ต IP มากที่สุดคือ การหมดไปของเลขที่อยู่ และการขยายตัวของการจัดเส้นทาง
และวางตำแหน่งของทางออกไว้ว่า
ทางออกระยะสั้นคือ CIDR ส่วนทางออกระยะยาวประกอบด้วยข้อเสนอต่าง ๆ สำหรับโพรโทคอลอินเทอร์เน็ตใหม่ที่มีเลขที่อยู่ยาวกว่าเดิม
NAT ถูกวางไว้เป็นตัวอุดช่องว่าง เผื่อว่า CIDR จะเอาไม่อยู่จนกว่าโพรโทคอล ที่มีเลขยาวกว่าจะมาถึง
โพรโทคอลนั้นมาแล้วชื่อ IPv6 แต่ช่องว่างที่ NAT อุดไว้ยังไม่ปิด และ NAT กลายเป็นสิ่งที่ทุกคนถือว่าเป็นเรื่องปกติจนลืมไปว่ามันเคยเป็นของชั่วคราว
เอกสารรุ่นต่อมาคือ RFC 3022 ปี 2001 ซึ่งอธิบายสิ่งที่ใช้กันจริงละเอียดกว่า
แนวคิดการออกแบบ — ตารางเดียวที่ทำทุกอย่าง
ปัญหาที่ต้องแก้คือ หลายเครื่องข้างใน แต่มีเลขข้างนอกเลขเดียว
ถ้าแปลงแค่เลขที่อยู่ พอคำตอบวิ่งกลับมาที่ 203.0.113.7 เราเตอร์จะไม่รู้เลยว่า ต้องส่งต่อให้เครื่องไหนในบ้าน
ทางออกคือใช้หมายเลขพอร์ตเป็นตัวแยก
ข้างใน ข้างนอก ปลายทาง
192.168.1.10:51820 -> 203.0.113.7:40001 -> 93.184.216.34:443
192.168.1.10:51821 -> 203.0.113.7:40002 -> 142.250.0.14:443
192.168.1.25:60112 -> 203.0.113.7:40003 -> 93.184.216.34:443แถวที่หนึ่งกับแถวที่สามไปปลายทางเดียวกันจากคนละเครื่อง แต่แยกกันได้เพราะ พอร์ตข้างนอกไม่ซ้ำกัน
ชื่อที่ถูกต้องของสิ่งที่ทุกคนเรียกว่า NAT จึงคือ NAPT ซึ่งมีคำว่า Port อยู่ในชื่อ NAT แบบที่แปลงแค่ที่อยู่มีอยู่จริงแต่แทบไม่มีใครใช้ เพราะมันแก้ ปัญหาเลขไม่พอไม่ได้เลย
ตารางนี้อยู่ในหน่วยความจำ ไม่ได้เก็บถาวร รีบูตเราเตอร์แล้วทุกการเชื่อมต่อ ที่ค้างอยู่ขาดหมด และแต่ละแถวมีอายุ ซึ่งเป็นหัวข้อที่จะกลับมาพูดถึง
ขาออกและขากลับ
ขาออก
เครื่อง จาก 192.168.1.10:51820 ถึง 93.184.216.34:443
NAT จาก 203.0.113.7:40001 ถึง 93.184.216.34:443 + จดลงตาราง
ขากลับ
เว็บ จาก 93.184.216.34:443 ถึง 203.0.113.7:40001
NAT จาก 93.184.216.34:443 ถึง 192.168.1.10:51820 + เปิดตารางสิ่งที่ต้องเข้าใจคือ เว็บที่ปลายทางไม่มีทางรู้ว่ามีกี่เครื่องอยู่หลังเลขนั้น มันเห็นแค่ 203.0.113.7 และสำหรับมันแล้วนั่นคือลูกค้าหนึ่งราย
เชื่อมกับบทความ MAC address ตรงนี้ได้พอดี — MAC ตายที่เราเตอร์ตัวแรก ส่วนเลข IP ต้นทางตายที่ NAT ข้อมูลที่บอกว่าคุณเป็น ใครในบ้าน หายไปทั้งคู่ก่อนออกจากบ้าน
ทำไมคนข้างนอกต่อเข้ามาไม่ได้
กลไกทั้งหมดข้างบนทำงานได้เพราะเครื่องในบ้านเป็นฝ่ายเริ่มก่อน แถวในตาราง จึงถูกสร้างไว้แล้วตอนที่คำตอบวิ่งกลับมา
ทีนี้ลองกลับด้าน — มีคนข้างนอกอยากต่อเข้ามาที่พอร์ต 443 ของเครื่องในบ้าน
แพ็กเก็ตมาถึง 203.0.113.7:443 แล้ว NAT เปิดตารางดู ไม่มีแถวไหนบอกว่า พอร์ต 443 เป็นของเครื่องไหน เพราะไม่มีใครในบ้านเคยเริ่มการเชื่อมต่อที่ใช้ พอร์ตนั้น
แพ็กเก็ตจึงไม่มีที่ให้ไปต่อ และถูกทิ้ง
ข้อสำคัญ — NAT ไม่ได้ปฏิเสธเพราะมีนโยบายห้าม แต่เพราะมันไม่รู้ว่าจะส่งให้ใคร ความต่างนี้จะกลับมาสำคัญมากในหัวข้อเรื่องไฟร์วอลล์
Port forwarding คือการเพิ่มแถวถาวรลงในตารางด้วยมือ เพื่อตอบคำถามนั้น ล่วงหน้า — บอกไว้เลยว่าอะไรที่มาถึงพอร์ต 443 ให้ส่งต่อไปที่เครื่องนี้
แถวในตารางมีอายุ
เราเตอร์มีหน่วยความจำจำกัด จะเก็บทุกแถวไว้ตลอดกาลไม่ได้ แถวที่ไม่มีทราฟฟิก วิ่งผ่านนานพอจึงถูกลบทิ้ง
RFC 5382 กำหนดค่าต่ำสุดไว้
การเชื่อมต่อที่เปิดอยู่แล้ว ต้องเก็บไว้ไม่ต่ำกว่า 2 ชั่วโมง 4 นาที
การเชื่อมต่อที่กำลังเปิดหรือปิด ต้องเก็บไว้ไม่ต่ำกว่า 4 นาทีแต่นั่นคือค่าต่ำสุดที่มาตรฐานบังคับ ไม่ใช่ค่าที่อุปกรณ์จริงตั้งไว้ เราเตอร์บ้านและอุปกรณ์ CGNAT จำนวนมากตั้งสั้นกว่านั้นมากเพื่อประหยัด หน่วยความจำ บางตัวสั้นถึงระดับไม่กี่นาที
นี่คือคำอธิบายของอาการที่คนเจอบ่อยที่สุด — เปิด ssh ทิ้งไว้ ลุกไปกินข้าว กลับมาพิมพ์แล้วค้าง ทั้งเครื่องคุณและเซิร์ฟเวอร์ยังคิดว่าการเชื่อมต่อเปิดอยู่ แต่ NAT ตรงกลางลืมไปแล้ว
ทางแก้คือส่งอะไรเบา ๆ เป็นระยะเพื่อให้แถวไม่หมดอายุ ซึ่งเป็นที่มาของค่า ServerAliveInterval ใน ssh, keepalive ใน VPN และค่าคล้ายกันในโพรโทคอลอื่น
CGNAT — เมื่อ NAT ซ้อน NAT
เมื่อเลขสาธารณะไม่พอแม้แต่จะให้บ้านละเลข ผู้ให้บริการจึงทำ NAT อีกชั้นที่ ฝั่งตัวเอง เรียกว่า CGNAT และใช้ช่วง 100.64.0.0/10 ที่ RFC 6598 กันไว้ให้โดยเฉพาะ
ผลคือแพ็กเก็ตของคุณถูกแปลงสองครั้ง — ที่เราเตอร์บ้าน แล้วที่อุปกรณ์ของ ผู้ให้บริการอีกที
และตรงนี้มีขีดจำกัดทางคณิตศาสตร์ที่หลบไม่ได้
พอร์ตทั้งหมดต่อหนึ่งเลขสาธารณะ 65,536
หักช่วงที่สงวนไว้ 64,512 ที่ใช้แมปได้จริง
ถ้าอุปกรณ์หนึ่งใช้ 50 การเชื่อมต่อพร้อมกัน -> รองรับ 1,290 ราย
ถ้าอุปกรณ์หนึ่งใช้ 100 การเชื่อมต่อพร้อมกัน -> รองรับ 645 ราย
ถ้าอุปกรณ์หนึ่งใช้ 200 การเชื่อมต่อพร้อมกัน -> รองรับ 322 ราย
ถ้าอุปกรณ์หนึ่งใช้ 500 การเชื่อมต่อพร้อมกัน -> รองรับ 129 รายเบราว์เซอร์ที่เปิดหลายแท็บใช้ได้เป็นร้อยการเชื่อมต่อพร้อมกันโดยง่าย ผู้ให้บริการจึงต้องจำกัดจำนวนพอร์ตต่อราย ไม่ใช่ปล่อยตามใจ
อาการเมื่อพอร์ตหมดคือเปิดเว็บบางเว็บไม่ได้แบบสุ่ม ๆ โดยไม่มีข้อความบอก อะไรทั้งสิ้น ซึ่งเป็นอาการที่ไล่หาสาเหตุยากมากถ้าไม่รู้ว่ามี CGNAT อยู่
ดูว่าตัวเองอยู่หลัง CGNAT หรือไม่ได้จาก traceroute ถ้าเห็นเลขในช่วง 100.64.0.0/10 ที่ฮอปต้น ๆ นั่นคือคำตอบ
NAT ไม่ใช่ไฟร์วอลล์
นี่คือความเข้าใจผิดที่แพร่หลายที่สุดเรื่อง NAT
จริงอยู่ว่าคนข้างนอกต่อเข้ามาไม่ได้ แต่เหตุผลไม่ใช่ความปลอดภัย NAT ไม่ได้ตัดสินว่าอะไรควรผ่านหรือไม่ควรผ่าน มันแค่ไม่รู้ว่าจะส่งต่อให้ใคร การกันได้จึงเป็นผลข้างเคียง ไม่ใช่หน้าที่
และสิ่งที่ NAT ไม่ได้กันเลย คือทุกอย่างที่เครื่องในบ้านเป็นฝ่ายเริ่มเอง
- มัลแวร์ที่ติดตั้งแล้วต่อออกไปหาเซิร์ฟเวอร์ของคนร้าย
- ผู้ใช้ที่กดเปิดเว็บอันตรายเอง
- อุปกรณ์ IoT ที่ส่งข้อมูลออกไปโดยไม่มีใครสั่ง
ซึ่งคือเส้นทางของการโจมตีเกือบทั้งหมดในยุคนี้
ไฟร์วอลล์ตัดสินตามนโยบายว่าอะไรควรผ่านทั้งขาเข้าและขาออก ส่วน NAT ทำอย่างเดียว คือแปลงที่อยู่ สองอย่างนี้บังเอิญให้ผลคล้ายกันในกรณีเดียว และเป็นกรณีที่ไม่ใช่ ช่องทางหลักอีกต่อไป
สิ่งที่ NAT ทำพัง
RFC 1631 เขียนข้อเสียไว้เองตั้งแต่ปี 1994
แอปพลิเคชันใดก็ตามที่พกที่อยู่ IP ไว้ข้างในตัวแอปพลิเคชันเอง จะทำงานผ่าน NAT ไม่ได้ เว้นแต่ NAT จะรู้จักกรณีนั้นและทำการแปลงให้อย่างเหมาะสม
เพราะ NAT แปลงที่อยู่ในหัวแพ็กเก็ต แต่ไม่รู้เรื่องข้อมูลข้างใน โพรโทคอลที่ส่ง เลข IP ของตัวเองไปในเนื้อข้อมูลจึงส่งเลขที่ใช้ไม่ได้ไปให้อีกฝ่าย
เอกสารเดียวกันสรุปสั้น ๆ ว่า "มันทำให้แอปพลิเคชันบางอย่างพัง หรืออย่างน้อย ก็ทำให้รันยากขึ้น"
ผลที่ลึกกว่านั้นคือ NAT ทำลายสมมติฐานที่อินเทอร์เน็ตถูกออกแบบมาบนมันตั้งแต่ต้น — ที่ว่าเครื่องสองเครื่องใดก็ได้ควรต่อถึงกันได้โดยตรง
เมื่อสมมติฐานนั้นหายไป การเชื่อมต่อตรงระหว่างสองเครื่องที่อยู่หลัง NAT กลายเป็นปัญหาที่ต้องมีเทคนิคทั้งชุดมาแก้ ทั้ง STUN ที่ให้เครื่องถามว่าตัวเอง ถูกเห็นเป็นเลขอะไรจากข้างนอก และ TURN ที่ยอมแพ้แล้วส่งผ่านเซิร์ฟเวอร์กลางแทน
วิดีโอคอลที่คุณใช้ทุกวันมีโค้ดจำนวนมากที่มีอยู่เพียงเพื่อเอาชนะ NAT
ตัวอย่างจริงจากงานจริง
กรณีที่ 1 — ssh ที่ค้างเมื่อลุกไปกินข้าว
$ ssh server
... ทำงานปกติ ...
... ลุกไป 40 นาที ...
$ ls
(ค้าง ไม่มีอะไรเกิดขึ้น)อ่านอย่างไร ทั้งสองปลายยังคิดว่าการเชื่อมต่อเปิดอยู่ แต่แถวใน NAT ถูกลบไป แล้ว แพ็กเก็ตถัดไปจึงไม่มีที่ให้ไปต่อ
ยืนยันได้ด้วยการเปิดใหม่แล้วเชื่อมต่อได้ทันที ถ้าเซิร์ฟเวอร์ล่มจริงจะเปิดใหม่ ไม่ได้ด้วย
ทางแก้ ตั้งให้ ssh ส่งอะไรเบา ๆ เป็นระยะ
# ~/.ssh/config
Host *
ServerAliveInterval 60สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่า NAT ตัวไหนลืม อาจเป็นเราเตอร์ที่บ้าน หรืออุปกรณ์ CGNAT ของผู้ให้บริการ ต้องทดสอบจากเครือข่ายอื่นเทียบดู
กรณีที่ 2 — อยู่หลัง CGNAT หรือไม่
$ traceroute -n 8.8.8.8
1 192.168.1.1 1.1 ms
2 100.64.12.1 9.8 ms <- ช่วงที่ RFC 6598 กันไว้ให้ CGNAT
3 203.0.113.1 14.1 msอ่านอย่างไร ฮอปที่สองอยู่ในช่วง 100.64.0.0/10 ซึ่งไม่ใช่ทั้งเลขส่วนตัว ตาม RFC 1918 และไม่ใช่เลขสาธารณะ เห็นแบบนี้แปลว่าอยู่หลัง CGNAT
สิ่งที่ตามมา เปิด port forwarding ที่เราเตอร์บ้านจะไม่ช่วยอะไร เพราะยังมี NAT อีกชั้นอยู่เหนือขึ้นไปที่คุณไม่ได้ควบคุม
สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าผู้ให้บริการจำกัดพอร์ตต่อรายไว้เท่าไหร่ ซึ่งเป็นตัวกำหนดว่าจะเจอปัญหาพอร์ตหมดเมื่อไหร่
กรณีที่ 3 — port forwarding ที่ตั้งแล้วแต่ยังเข้าไม่ได้
อ่านอย่างไร ไล่ตามลำดับว่าติดตรงไหน
1 เลขสาธารณะที่เว็บบอก ตรงกับเลขที่เราเตอร์บ้านแสดงไหม
ไม่ตรง -> มี CGNAT อยู่เหนือขึ้นไป จบ ทำต่อไม่ได้
2 เครื่องปลายทางในบ้านตั้งเลข IP ตายตัวหรือเปล่า
ไม่ตั้ง -> DHCP เปลี่ยนเลข แถวที่ตั้งไว้ชี้ผิดเครื่องแล้ว
3 ไฟร์วอลล์บนเครื่องปลายทางเปิดพอร์ตนั้นไหมข้อแรกคือข้อที่คนพลาดบ่อยที่สุด และเป็นข้อที่แก้ไม่ได้ด้วยตัวเอง
สิ่งที่ยังไม่ได้พิสูจน์ ทั้งสามข้อผ่านแล้วก็ยังอาจติดที่ผู้ให้บริการบล็อก พอร์ตนั้นไว้ ซึ่งพบบ่อยกับพอร์ต 25, 80 และ 443 ในแพ็กเกจสำหรับบ้าน
กรณีที่ 4 — วิดีโอคอลที่เสียงมาแต่ภาพไม่มา
อ่านอย่างไร วิดีโอคอลพยายามต่อตรงระหว่างสองเครื่องก่อนเสมอ เพราะเร็วกว่า และถูกกว่าสำหรับผู้ให้บริการ ถ้าต่อตรงไม่ได้จึงถอยไปใช้เซิร์ฟเวอร์กลาง
อาการที่ทางหนึ่งไปได้อีกทางไปไม่ได้ มักเกิดจาก NAT สองฝั่งเป็นคนละแบบ ฝั่งที่เข้มกว่าจะแมปพอร์ตใหม่ทุกครั้งที่ปลายทางเปลี่ยน ทำให้อีกฝ่ายส่งกลับ มาที่พอร์ตเดิมไม่ได้
สิ่งที่ยังไม่ได้พิสูจน์ ยังไม่รู้ว่าเป็นเรื่อง NAT จริงหรือเป็นเรื่อง ไฟร์วอลล์ที่บล็อก UDP ต้องดูว่าถอยไปใช้เซิร์ฟเวอร์กลางแล้วดีขึ้นไหม ถ้าดีขึ้นแปลว่าปัญหาอยู่ที่การต่อตรง
แล้ว IPv6 จบเรื่องนี้ไหม
IPv6 ใช้เลขที่อยู่ยาว 128 บิต ซึ่งมากพอจะให้ทุกอุปกรณ์บนโลกมีเลขสาธารณะ ของตัวเองได้จริง NAT จึงไม่จำเป็นอีกต่อไปในทางเทคนิค
แต่สองอย่างทำให้มันยังไม่หายไป
หนึ่ง หลายคนเข้าใจว่า NAT คือความปลอดภัย แล้วรู้สึกไม่สบายใจที่ทุกเครื่อง มีเลขสาธารณะ ทั้งที่คำตอบที่ถูกคือใช้ไฟร์วอลล์ ซึ่งทำหน้าที่นั้นได้ดีกว่า และตั้งใจทำ
สอง โลกยังต้องรองรับ IPv4 ต่อไปอีกนาน ตราบใดที่ยังมีปลายทางที่พูด IPv4 อย่างเดียว NAT ก็ยังต้องอยู่
ของชั่วคราวจากปี 1994 จึงน่าจะอยู่กับเราไปอีกนานกว่าที่ใครคิดตอนเขียนมันขึ้นมา
อ้างอิง
เอกสารมาตรฐาน
- RFC 1631 — The IP Network Address Translator (NAT) K. Egevang และ P. Francis, พฤษภาคม 1994, สถานะ Informational — ที่มาของ ทุกคำอ้างในหน้านี้ ทั้งการระบุปัญหา การวางตำแหน่งว่า CIDR คือทางออกระยะสั้น และโพรโทคอลที่เลขยาวกว่าคือระยะยาว และข้อเสียเรื่องแอปที่พกเลข IP ไว้ข้างใน
- RFC 3022 — Traditional IP Network Address Translator มกราคม 2001 แทนที่ RFC 1631 — อธิบายสิ่งที่ใช้กันจริงละเอียดกว่า
- RFC 1918 — Address Allocation for Private Internets ที่มาของสามช่วงส่วนตัว
- RFC 6598 — IANA-Reserved IPv4 Prefix for Shared Address Space ที่มาของ 100.64.0.0/10 ที่ CGNAT ใช้
- RFC 5382 — NAT Behavioral Requirements for TCP ตุลาคม 2008 — ค่าต่ำสุดของอายุแถวในตาราง
- RFC 4787 — NAT Behavioral Requirements for Unicast UDP ฝั่ง UDP ซึ่งอายุสั้นกว่ามาก
- RFC 8445 — Interactive Connectivity Establishment (ICE) วิธีที่วิดีโอคอลใช้เอาชนะ NAT
คู่มือ
ifconfigหรือip addrเทียบกับเลขที่เว็บภายนอกบอก ซึ่งเป็นวิธีที่เร็วที่สุด ในการเห็นว่า NAT กำลังทำงานอยู่netstat -anเพื่อดูว่าตอนนี้มีกี่การเชื่อมต่อกำลังใช้ตารางนั้นอยู่