บางคนอาจจะบอกว่า ก็ 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 เริ่มทำงานในเงื่อนไขพิเศษนี้