Skip to content

NAT Loopback คืออะไร ทำงานอย่างไร และใช้ในโอกาสไหน

บางคนอาจจะบอกว่า ก็ 3Tx คูณ ตามภาพข้างบนนี้ ใครที่ config XTM เป็นแล้ว จะรู้ทันทีว่า เพื่อให้เซิร์ฟเวอร์ตามภาพนี้ทำงานได้ เราจะต้องสร้าง 2 policy ให้กับเซิร์ฟเวอร์ตัวนี้ ได้แก่ Incoming policy และ Outgoing policy

Incoming Policy (จากอินเตอร์เน็ต เข้าหาเซิรืฟเวอร์ที่พอร์ต TCP-888 โดยใช้ SNAT)
From: Any External
To: SNAT 172.16.13.223 -> 10.0.1.3
Service: TCP-888

Outgoing Policy (ให้เซิร์ฟเวอร์ออกเน็ตได้ โดยใช้ IP 172.16.12.223)
From: 10.0.1.3
To: Any External
Service: Any
ซึ่งเราจะสร้าง 1-1 NAT เพื่อบังคับให้ Local IP 10.0.1.3 ออกเน็ตด้วยหมายเลข IP 172.16.13.223 เท่านั้น และหมายเลข IP 172.16.13.223 ก็จะถูกกำหนดไว้เป็น Secondary IP ของ External Interface ของ XTM ด้วยเช่นกัน

สำหรับ Client 10.0.1.2 หากจะติดต่อเซิร์ฟเวอร์ที่หมายเลข IP 10.0.1.3 ก็ไม่ใช่เรื่องยากอะไร เพราะเป็นการติดต่อภายใน Subnet เดียวกัน ไม่มีอะไรวิ่งผ่าน XTM

แต่...

หลาย ๆ ระบบมีข้อจำกัดที่ทำให้ Client ไม่สามารถติดต่อกับเซิร์ฟเวอร์ที่ IP 10.0.1.3 ได้ แต่ไปใช้ 172.16.13.223 แทน เช่น

DNS ที่ Client ใช้อ้างถึงเซิร์ฟเวอร์ ให้คำตอบเป็น Net-IP (แทนที่จะเป็น Local-IP)
ซอฟต์แวร์ที่เขียนให้ทำงานกับเซิร์ฟเวอร์ เจาะจงว่าจะติดต่อกับเซิร์ฟเวอร์ที่ Net-IP ไม่รองรับการติดต่อกับเซิร์ฟเวอร์ด้วย Local-IP
ซึ่ง Policy ทั้ง 2 นี้ จะไม่ช่วยให้ Client สามารถติดต่อกับเซิร์ฟเวอร์ที่ Net-IP (172.16.13.223) ได้

สิ่งที่เราต้องการคือ ให้เกิด connection แบบไหนย้อนกลับ จาก External Interface ให้วนกลับมาที่ Trusted interface

ถ้า Client พยายามติดต่อกับ 172.16.13.223 ที่ TCP-888 จะได้ข้อความใน Traffic Monitor ดังนี้

2015-07-14 13:18:59 Deny 10.0.1.2 172.16.13.223 888/tcp 50894 888 1-Trusted Firebox Denied 52 128 (Unhandled Internal Packet-00) proc_id=”firewall” rc=”101″ msg_id=”3000-0148″ tcp_info=”offset 8 S 2845639353 win 32″ Traffic

วิธีทำให้ Client ใน LAN ติดต่อกับเซิร์ฟเวอร์ด้วย Net-IP ได้ ง่ายอย่างเหลือเชื่อครับ คือใน Incoming policy ที่มี SNAT นั้น ก็เพียงใส่ Any Trust เข้าไปเท่านั้น ตามภาพด้านล่าง

การทำงานเบื้องหลัง

มาติดตามดูกันครับ

อันนี้เป็น Traffic Monitor Log สำหรับการ Access Server จากขา External
2015-07-14 13:41:08 Allow
172.16.13.12 172.16.13.223 888/tcp 57771 888
0-External 1-Trusted
Allowed 64 63 (Server-Incoming-00) proc_id=”firewall” rc=”100″ msg_id=”3000-0148″ dst_ip_nat=”10.0.1.3” tcp_info=”offset 11 S 2455518075 win 65535″ Traffic

ส่วนอันนี้เป็น Traffic Monitor Log สำหรับการ Access Server จาก LAN client (10.0.1.2) ไปยัง Net-IP (172.16.13.223) ของเซิร์ฟเวอร์
2015-07-14 13:40:17 Allow
10.0.1.2 172.16.13.223 888/tcp 51228 888
1-Trusted 1-Trusted
Allowed 52 127 (Server-Incoming-00) proc_id=”firewall” rc=”100″ msg_id=”3000-0148″ src_ip_nat=”10.0.1.1″ dst_ip_nat=”10.0.1.3” tcp_info=”offset 8 S 3358614933 win 32″ Traffic

สิ่งที่น่าสนใจคือ มีการทำ src_ip_nat ปรากฏขึ้นมา โดยไม่ใช่ส่วนหนึ่งของการทำงานของ SNAT (ซึ่งจะ Translate เฉพาะ dst_ip เท่านั้น) หรือ Dynamic NAT (ซึ่งจะทำงานกับ External interface ตามค่า default)

การทำ src_ip_nat เป็นกลไกภายในของ Fireware OS เอง ที่จะเริ่มทำ NAT ให้กับ src_ip เพื่อป้องกันการเกิด Asymmetric routing เรียกสิ่งนี้ว่า NAT loopback

NAT loopback จะเริ่มทำงานโดยอัตโนมัติ เมื่อพบว่า Trusted network จะพยายามเข้าถึง IP ที่อยู่ใน Trusted network ด้วยกัน ผ่านทาง External IP โดยอ้างอิงความสัมพันธ์ที่ระบุเเอาไว้ใน SNAT หรือ 1-1 NAT

มาดูภาพด้านล่างว่า ถ้า XTM ทำ NAT เฉพาะ dst_ip จะเกิด Asymmetric routing ได้อย่างไร และทำไม Loopback NAT (ที่เพิ่มการทำ NAT ของ src_ip ด้วย) จึงทำให้ทุกอย่างทำงานได้อย่างถูกต้อง

เปรียบเทียบเส้นทางที่ 3 (สีแดง) ที่จะเกิดขึ้นหากไม่มีการทำ NAT ที่ src_ip ซึ่งเป็นผลไม่ดีแน่ หากจู่ ๆ client ได้รับการติดต่อกลับมาจากเซิร์ฟเวอร์ในอีกเส้นทางหนึ่ง

ถือเป็นความฉลาดของ Fireware OS ที่ได้มีการออกแบบให้ NAT loopback เริ่มทำงานในเงื่อนไขพิเศษนี้