ในยุคที่ธุรกิจมีหลายสาขา หลายคลังสินค้า หรือมีทีมงานกระจายอยู่คนละพื้นที่ การเชื่อมต่อเครือข่ายระหว่างสำนักงานใหญ่และสาขาให้ปลอดภัย เสถียร และบริหารจัดการง่าย ถือเป็นเรื่องสำคัญอย่างมาก โดยเฉพาะเมื่อระบบงานหลัก เช่น ERP, POS, File Server, NAS, กล้องวงจรปิด หรือฐานข้อมูลส่วนกลาง อยู่ที่สำนักงานใหญ่หรือศูนย์ข้อมูลเพียงแห่งเดียว

เดิมทีองค์กรจำนวนมากใช้ VPN แบบ Manual Site-to-Site ซึ่งผู้ดูแลระบบต้องกำหนด IPsec, Encryption, Pre-Shared Key, Routing, Subnet, Public IP และค่าต่าง ๆ แยกทีละคู่ เมื่อมีเพียงสอง Site ระบบยังพอจัดการได้ แต่เมื่อเพิ่มเป็นห้า สิบ หรือหลายสิบสาขา จำนวน Tunnel และ Policy จะเพิ่มขึ้นอย่างรวดเร็ว ทำให้การแก้ไข การตรวจสอบ และการขยายระบบทำได้ยากขึ้น

SD-WAN หรือ Software-Defined Wide Area Network จึงเข้ามาช่วยลดความซับซ้อน โดยใช้ Controller เป็นศูนย์กลางในการกำหนดนโยบาย เชื่อมต่อ Site และควบคุมเส้นทางระหว่างเครือข่ายหลายแห่ง ผู้ดูแลระบบสามารถมองเห็นสถานะ WAN, Gateway, Tunnel และนโยบายของแต่ละ Site ได้จากจุดเดียว

สำหรับธุรกิจ SME, ออฟฟิศหลายสาขา, ร้านค้า, ร้านอาหาร, โรงแรม, คลังสินค้า, โรงงาน หรือองค์กรที่ต้องการเชื่อมระบบสำนักงานใหญ่กับสาขา TP-Link Omada เป็นโซลูชันที่น่าสนใจ เพราะมี Controller, Gateway, Switch และ Access Point อยู่ใน Ecosystem เดียว ช่วยให้การบริหารระบบเครือข่ายแบบรวมศูนย์ทำได้ง่ายกว่าการใช้อุปกรณ์แยกหลายยี่ห้อ

Omada SD-WAN คืออะไร?

Omada SD-WAN คือระบบเชื่อมต่อเครือข่ายข้าม Site ที่ใช้ Controller ช่วยจัดการ Topology, Tunnel, Network Segment และนโยบายการส่งทราฟฟิกจากส่วนกลาง โดยรูปแบบหลักของระบบคือ Hub-and-Spoke ซึ่งมี Gateway หนึ่งแห่งเป็น Hub และมี Gateway ของสาขาเป็น Spoke

สิ่งสำคัญคือ SD-WAN ไม่ได้หมายถึง VPN เพียงอย่างเดียว VPN มีหน้าที่สร้างช่องทางเข้ารหัสระหว่าง Site แต่ SD-WAN เพิ่มความสามารถด้านการบริหารจากศูนย์กลาง การกำหนด Policy การใช้หลาย WAN การเลือกเส้นทาง และการตรวจสอบสถานะของระบบโดยรวม

ใน Omada ยังมีฟีเจอร์ Auto IPsec ซึ่งช่วยสร้าง Site-to-Site VPN อัตโนมัติระหว่าง Site ที่อยู่ภายใต้ Controller เดียวกัน แต่ Auto IPsec และ SD-WAN ไม่ควรถูกอธิบายว่าเป็นฟีเจอร์เดียวกันทั้งหมด เพราะ SD-WAN รุ่นใหม่มีโครงสร้างและเงื่อนไขเฉพาะ เช่น Hub, Spoke, Public IP Pool และการควบคุมเส้นทางระหว่าง Site

Omada SD-WAN ต่างจาก Auto IPsec และ Manual IPsec อย่างไร?

หัวข้อ Manual IPsec Auto IPsec Omada SD-WAN
การตั้งค่า กำหนด Tunnel และ Parameter ด้วยตนเองทีละคู่ Controller ช่วยสร้าง VPN ระหว่าง Site Controller จัดการ Hub, Spoke, Tunnel และ Policy จากส่วนกลาง
ความเหมาะสม เชื่อมอุปกรณ์ต่างยี่ห้อ หรืองานที่ต้องปรับแต่งละเอียด เครือข่าย Omada จำนวนไม่มากที่ต้องการ VPN แบบง่าย องค์กรหลายสาขาที่ต้องการบริหาร WAN และเส้นทางจากศูนย์กลาง
การขยายสาขา ยิ่งเพิ่ม Site ยิ่งต้องสร้าง Tunnel และ Routing เพิ่ม ง่ายกว่า Manual IPsec ออกแบบมาเพื่อช่วยลดความซับซ้อนของหลาย Site
การเลือกเส้นทาง ขึ้นอยู่กับ Static Route หรือ Policy Routing ที่กำหนดเอง เน้นการสร้าง VPN อัตโนมัติ รองรับการกำหนด Policy และเส้นทางในโครงสร้าง SD-WAN
ข้อจำกัด ดูแลยากเมื่อมีหลาย Tunnel ต้องใช้ Gateway และ Controller ที่รองรับ ต้องใช้ Firmware และ Controller ที่รองรับ SD-WAN โดยตรง

Omada SD-WAN เหมาะกับองค์กรแบบไหน?

  • บริษัทที่มีสำนักงานใหญ่และหลายสาขา
  • คลังสินค้าหรือโรงงานที่ต้องเชื่อม ERP หรือฐานข้อมูลกับสำนักงานใหญ่
  • ร้านค้า ร้านอาหาร หรือธุรกิจ Franchise หลายแห่ง
  • โรงแรม อาคาร หรือสถานที่ให้บริการที่มีหลาย Site
  • องค์กรที่ต้องการลดความซับซ้อนของ Manual Site-to-Site VPN
  • ธุรกิจที่มีอินเทอร์เน็ตมากกว่าหนึ่งเส้นและต้องการ Load Balance หรือ Failover
  • ทีม IT ที่ต้องการ Monitor Gateway, Switch และ Access Point จาก Controller กลาง
  • องค์กรที่ต้องการกำหนด Policy การเข้าถึงระหว่าง Site จากส่วนกลาง

อย่างไรก็ตาม Omada SD-WAN อาจไม่เหมาะกับระบบที่ต้องใช้ Dynamic Routing ขั้นสูง การทำ Segmentation ที่ซับซ้อนมาก การเชื่อมต่อกับผู้ให้บริการ MPLS หลายราย หรือการควบคุม Application แบบละเอียดระดับ Enterprise Firewall ในกรณีดังกล่าวควรตรวจสอบ Requirement และทำ Proof of Concept ก่อนเลือกใช้งานจริง

สถาปัตยกรรมแบบ Hub-and-Spoke

Omada SD-WAN ใช้รูปแบบ Hub-and-Spoke เป็นหลัก โดย Hub ทำหน้าที่เป็นศูนย์กลาง และ Spoke แต่ละแห่งเชื่อมต่อเข้าหา Hub ก่อน

Hub: ศูนย์กลางของระบบ

Hub มักติดตั้งที่สำนักงานใหญ่ ศูนย์ข้อมูล หรือสถานที่ที่มีระบบกลาง เช่น Server, NAS, ERP, NVR, Active Directory หรือระบบบัญชี โดย Hub ควรมีอินเทอร์เน็ตที่เสถียรและมีทรัพยากรเพียงพอสำหรับรองรับทราฟฟิกจากหลายสาขา

สำหรับการใช้งาน Omada SD-WAN ต้องมีอย่างน้อยหนึ่งอุปกรณ์ในระบบที่มี Public IP และอุปกรณ์ที่ทำหน้าที่ Hub ต้องสามารถใช้ Public IP ตามเงื่อนไขของ Firmware และ Controller ที่รองรับ หาก HQ อยู่หลัง CGNAT และไม่สามารถขอ Public IP ได้ อาจไม่เหมาะสำหรับการเป็น Hub โดยตรง

Spoke: สาขาหรือจุดใช้งานปลายทาง

Spoke คือ Gateway ที่อยู่ตามสาขา คลังสินค้า ร้านค้า หรือโรงงาน โดย Spoke จะเชื่อมต่อเข้าหา Hub ก่อน จากนั้นระบบจึงสามารถควบคุมเส้นทางระหว่าง Spoke ตาม Policy ที่กำหนด

สาขาสามารถใช้อินเทอร์เน็ตแบบ Dynamic IP ได้ในบางรูปแบบ แต่ต้องตรวจสอบว่า Gateway, Firmware, Controller และลักษณะ NAT ของผู้ให้บริการรองรับการเชื่อมต่อที่ออกแบบไว้ หากสาขาอยู่หลัง CGNAT ควรทดสอบจริง เพราะแม้การเชื่อมต่อขาออกอาจทำได้ แต่ความสามารถบางอย่างอาจแตกต่างจาก Site ที่มี Public IP

Spoke-to-Spoke

หากต้องการให้สาขาติดต่อกันเอง ระบบจะต้องสร้างการเชื่อมต่อผ่านโครงสร้างที่ Hub ควบคุม โดย Spoke ทุกแห่งต้องเชื่อมต่อกับ Hub ให้สมบูรณ์ก่อน จึงจะสามารถสร้างเส้นทางหรือ Tunnel ระหว่าง Spoke ตามเงื่อนไขของ SD-WAN ได้

เงื่อนไขสำคัญก่อนใช้งาน Omada SD-WAN

  • Gateway ทุกตัวที่เข้าร่วมต้องเป็นรุ่นและ Hardware Version ที่รองรับ SD-WAN
  • Firmware ของ Gateway ต้องรองรับ SD-WAN และเข้ากันได้กับ Controller Version ที่ใช้งาน
  • Controller ต้องเป็นเวอร์ชันที่รองรับฟีเจอร์ SD-WAN โดยตรง
  • อย่างน้อยหนึ่ง Site ต้องมี Public IP และ Hub ต้องเป็นอุปกรณ์ที่สามารถทำหน้าที่ตามเงื่อนไขของระบบได้
  • WAN ที่นำมาเข้าร่วม SD-WAN ต้องไม่เปิดฟังก์ชัน DMZ
  • LAN Subnet และ Network Segment ของทุก Site ต้องไม่ซ้ำหรือทับซ้อนกัน
  • Spoke ต้องเชื่อมต่อกับ Hub สำเร็จก่อน จึงค่อยตรวจสอบการสื่อสารระหว่าง Spoke
  • ควรสำรอง Configuration ของ Controller และ Gateway ก่อนอัปเดต Firmware
  • ควรทำ Proof of Concept ด้วย Site จำนวนน้อยก่อนขยายใช้งานจริง

ตัวอย่างโครงสร้างระบบ

ส่วนประกอบ สำนักงานใหญ่หรือ Hub สาขาหรือ Spoke
Gateway ER8411, ER707-M2 หรือรุ่นอื่นที่รองรับ SD-WAN และ Throughput ตามขนาดงาน ER605, ER7206, ER707-M2 หรือรุ่นที่รองรับ Firmware SD-WAN
Controller Hardware Controller, Software Controller หรือ Cloud-Based Controller ที่รองรับเวอร์ชันและอุปกรณ์ Gateway ถูก Adopt เข้ามายัง Controller เดียวกันแต่แยกเป็นคนละ Site
Internet แนะนำ Business Internet พร้อม Public IP และ WAN สำรอง Broadband, Business Internet, 4G/5G หรือ Multi-WAN ตามความเหมาะสม
LAN Subnet ตัวอย่าง 10.10.0.0/16 แยกเป็น VLAN ย่อย ตัวอย่าง 10.20.0.0/16, 10.30.0.0/16 โดยแต่ละ Site ไม่ซ้ำกัน
บทบาท Hub, ศูนย์กลางระบบ และจุดควบคุมทราฟฟิก Spoke และจุดใช้งานปลายทาง

หมายเหตุ: รายชื่อรุ่นด้านบนเป็นเพียงตัวอย่าง ไม่ควรสรุปจากชื่อรุ่นเพียงอย่างเดียวว่ารองรับ SD-WAN เพราะ Hardware Version และ Firmware ของแต่ละภูมิภาคอาจไม่เหมือนกัน ต้องตรวจสอบ Compatibility List และ Release Note ก่อนสั่งซื้อหรืออัปเกรด

การเลือก Omada Gateway ให้เหมาะกับงาน

การเลือก Gateway ไม่ควรดูเฉพาะความเร็วพอร์ตหรือ NAT Throughput เพราะเมื่อเปิด VPN, ACL, DPI, IPS หรือฟีเจอร์ด้าน Security ประสิทธิภาพจริงอาจต่ำกว่าความเร็วอินเทอร์เน็ตที่ระบุไว้

ควรพิจารณาปัจจัยต่อไปนี้ร่วมกัน

  • จำนวนผู้ใช้งานพร้อมกัน
  • จำนวน Site และจำนวน Tunnel ที่ต้องรองรับ
  • VPN Throughput ไม่ใช่เพียง NAT Throughput
  • ปริมาณทราฟฟิกระหว่างสาขา
  • จำนวนกล้อง CCTV และ Bitrate รวม
  • การสำรองข้อมูลระหว่าง Site
  • จำนวน WAN และประเภทพอร์ตที่ต้องใช้
  • ฟีเจอร์ Security ที่จะเปิดใช้งานพร้อมกัน
  • การเติบโตของระบบในอีกสองถึงสามปี

หาก HQ ต้องรับทราฟฟิกจากหลายสาขา ควรเผื่อ Capacity มากกว่าผลรวมการใช้งานปัจจุบัน และควรทดสอบ Throughput ภายใต้ Configuration จริง เพราะค่าจาก Datasheet มักเป็นผลการทดสอบภายใต้เงื่อนไขที่กำหนด

Controller ควรติดตั้งที่ไหน?

Controller ไม่จำเป็นต้องติดตั้งอยู่ที่สำนักงานใหญ่เสมอไป สามารถใช้ Hardware Controller, Software Controller หรือ Cloud-Based Controller ได้ตามรูปแบบงาน แต่ทุก Site ต้องสามารถติดต่อ Controller ได้อย่างต่อเนื่องสำหรับการ Adopt, Provision, Monitoring และเปลี่ยนแปลง Configuration

Hardware Controller

เหมาะกับองค์กรที่ต้องการอุปกรณ์สำเร็จรูป ดูแลง่าย และไม่ต้องจัดเตรียม Server เพิ่ม แต่ควรตรวจสอบจำนวนอุปกรณ์และ Site ที่รองรับก่อนเลือก OC200, OC300 หรือรุ่นที่เหมาะสม

Software Controller

เหมาะกับองค์กรที่มี Server, Virtual Machine หรือระบบ Container อยู่แล้ว ช่วยเพิ่มความยืดหยุ่นด้านทรัพยากรและการสำรองข้อมูล แต่ผู้ดูแลต้องรับผิดชอบระบบปฏิบัติการ ฐานข้อมูล ความปลอดภัย และการอัปเดต Controller

Cloud-Based Controller

เหมาะกับองค์กรที่ต้องการบริหารหลาย Site โดยไม่ติดตั้ง Controller ภายใน แต่ต้องตรวจสอบแพ็กเกจ ฟีเจอร์ License ความเข้ากันได้ของอุปกรณ์ และนโยบายด้านข้อมูลขององค์กรก่อนใช้งาน

ไม่ว่าจะเลือกแบบใด ควรเปิด MFA สำหรับบัญชีผู้ดูแล แยกบัญชีตามหน้าที่ และสำรอง Configuration อย่างสม่ำเสมอ

Cloud Access ไม่เหมือนกับ Cloud-Based Controller

Cloud Access คือการผูก Local Controller หรือ Hardware Controller เข้ากับบัญชี Omada Cloud เพื่อให้ผู้ดูแลเข้าถึง Controller จากภายนอกได้สะดวกขึ้น ขณะที่ Cloud-Based Controller คือ Controller ที่ทำงานอยู่บนระบบ Cloud ของผู้ให้บริการโดยตรง

การเปิด Cloud Access ไม่ได้แปลว่า Controller ภายในเปลี่ยนเป็น Cloud-Based Controller และไม่ได้หมายความว่าการ Adopt อุปกรณ์ทุกกรณีจะทำได้โดยไม่ต้องเตรียม Network Path ผู้ดูแลยังต้องตรวจสอบวิธี Discovery, Inform URL, DNS, Firewall และเส้นทางจากอุปกรณ์ไปยัง Controller ตามรูปแบบที่ใช้งานจริง

การเตรียม L3 Adoption

เมื่ออุปกรณ์อยู่คนละ Subnet หรือคนละ Site กับ Controller จะต้องใช้การ Adopt ผ่าน Layer 3 โดยทำให้อุปกรณ์ทราบที่อยู่ของ Controller และสามารถติดต่อพอร์ตที่จำเป็นได้

วิธีที่ใช้ได้อาจประกอบด้วย

  • กำหนด Inform URL หรือ Controller Hostname/IP ในหน้าอุปกรณ์
  • ใช้ Omada Discovery Utility ในเครือข่ายปลายทาง
  • ใช้ DHCP Option ตามรูปแบบที่ระบบรองรับ
  • ใช้ Cloud-Based Controller และ Zero-Touch Provisioning ในอุปกรณ์ที่รองรับ
  • เชื่อมต่ออุปกรณ์ผ่าน VPN ชั่วคราวเพื่อทำ Adoption

หากใช้ Local Controller ที่อยู่หลัง Router หรือ Firewall อาจต้องทำ Port Forwarding เฉพาะพอร์ตที่จำเป็น แต่ไม่ควรเปิดพอร์ตทั้งหมดตามรายการจากบทความเก่าโดยไม่ตรวจสอบ เพราะพอร์ตที่ใช้แตกต่างตาม Controller Version ชนิดอุปกรณ์ และรูปแบบการจัดการ ควรอ้างอิงเอกสาร Port ของเวอร์ชันที่ติดตั้งจริง

แนวทางที่แนะนำคือใช้ FQDN เช่น omada.company.com แทนการกำหนด Public IP โดยตรง เพื่อให้สามารถเปลี่ยน IP หรือย้าย Controller ได้ง่ายขึ้น และควรใช้ DNS Record ที่ควบคุมโดยองค์กร

Fixed Public IP, Dynamic IP, DDNS และ CGNAT

Fixed Public IP

เหมาะสำหรับ Hub หรือ Site สำคัญ เพราะตำแหน่งปลายทางไม่เปลี่ยน ทำให้การเชื่อมต่อ การตรวจสอบ และการแก้ปัญหาง่ายกว่า หากเป็นระบบธุรกิจที่ต้องออนไลน์ตลอดเวลา แนะนำให้ใช้ Business Internet ที่มี Public IP และ SLA ชัดเจน

Dynamic Public IP

บางรูปแบบสามารถใช้งานร่วมกับ DDNS ได้ แต่ควรตรวจสอบว่า SD-WAN, VPN และ Gateway รุ่นที่ใช้งานรองรับตาม Requirement หรือไม่ การเปลี่ยน IP อาจทำให้ Tunnel ต้องสร้างใหม่และเกิด Downtime ชั่วคราว

CGNAT

CGNAT คือกรณีที่ผู้ให้บริการนำลูกค้าหลายรายมาใช้ Public IP ร่วมกัน ทำให้ Gateway ไม่ได้รับ Public IP จริงและไม่สามารถรับการเชื่อมต่อจากอินเทอร์เน็ตโดยตรงได้ หาก Site ที่ต้องการทำ Hub อยู่หลัง CGNAT ควรขอ Public IP จาก ISP หรือย้ายบทบาท Hub ไปยัง Site ที่มี Public IP

การเห็น IP ในหน้าเว็บตรวจสอบ Public IP ไม่ได้ยืนยันว่า WAN ของ Gateway ได้รับ Public IP เดียวกัน ควรเปรียบเทียบ IP ที่หน้า WAN ของ Gateway กับ IP ที่อินเทอร์เน็ตมองเห็น หากไม่ตรงกันมีโอกาสอยู่หลัง NAT หรือ CGNAT

การออกแบบ IP Address และ VLAN

ปัญหาที่พบบ่อยที่สุดในการเชื่อมหลาย Site คือแต่ละสาขาใช้ Subnet ซ้ำกัน เช่น ทุกแห่งใช้ 192.168.1.0/24 เมื่อสร้าง VPN แล้ว Router จะไม่ทราบว่าปลายทางอยู่ Local LAN หรืออยู่ Site อื่น

ควรวาง IP Plan ตั้งแต่ต้นและแบ่งช่วงให้แต่ละ Site อย่างชัดเจน เช่น

Site Network หลัก ตัวอย่าง VLAN การใช้งาน
HQ 10.10.0.0/16 10 Office, 20 Server, 30 CCTV, 99 Management ศูนย์กลางระบบ
Warehouse 1 10.20.0.0/16 10 Office, 30 CCTV, 40 Scanner, 50 Guest คลังสินค้าสาขาแรก
Branch 2 10.30.0.0/16 10 Office, 30 CCTV, 50 Guest สำนักงานสาขา
Branch 3 10.40.0.0/16 10 Office, 40 POS, 50 Guest ร้านค้าหรือสาขาย่อย

หมายเลข VLAN สามารถใช้ซ้ำกันระหว่าง Site ได้หาก Network Address ไม่ซ้ำ แต่ควรมีมาตรฐานเดียวกันเพื่อให้ทีม IT เข้าใจง่าย เช่น VLAN 10 คือ Office ทุก Site และ VLAN 50 คือ Guest ทุก Site

เลือก Network ใดให้ข้าม SD-WAN

ไม่ควรนำทุก VLAN เข้า Tunnel โดยอัตโนมัติ ควรเลือกเฉพาะ Network ที่จำเป็นต่อธุรกิจ เช่น

  • Office VLAN ของสาขาเข้าถึง ERP ที่ HQ
  • POS VLAN เข้าถึง Application Server หรือฐานข้อมูล
  • CCTV VLAN ส่งภาพไปยัง NVR หรือ NAS ที่กำหนด
  • Management VLAN เปิดให้เฉพาะทีม IT
  • Guest VLAN ออกอินเทอร์เน็ตที่สาขาและห้ามข้าม SD-WAN
  • IoT VLAN เข้าถึงเฉพาะ Server ที่จำเป็น

การลดจำนวน Network ที่ข้าม Tunnel ช่วยลด Broadcast ที่ไม่จำเป็น ลดความเสี่ยง และทำให้ Troubleshooting ง่ายขึ้น

ขั้นตอนตั้งค่า Omada SD-WAN แบบ Hub-and-Spoke

ชื่อเมนูอาจแตกต่างตาม Controller Version แต่หลักการทำงานควรเป็นดังนี้

ขั้นตอนที่ 1: ตรวจสอบ Compatibility

  1. ตรวจสอบรุ่นและ Hardware Version ของ Gateway ทุกตัว
  2. ตรวจสอบ Firmware ที่รองรับ SD-WAN
  3. ตรวจสอบ Controller Version ที่รองรับ Firmware ดังกล่าว
  4. สำรอง Configuration ก่อนอัปเดต
  5. อัปเดตทีละ Site และตรวจสอบสถานะก่อนดำเนินการต่อ

ขั้นตอนที่ 2: สร้าง Site ใน Controller

  1. สร้าง Site สำหรับ HQ
  2. สร้าง Site แยกสำหรับแต่ละสาขา
  3. กำหนดชื่อให้สื่อความหมาย เช่น HQ-BKK, WH-01 หรือ Branch-CNX
  4. กำหนด Time Zone, Location และสิทธิ์ผู้ดูแลให้ถูกต้อง

ขั้นตอนที่ 3: Adopt Gateway

  1. ตรวจสอบว่า Gateway ออกอินเทอร์เน็ตได้
  2. ทำให้ Gateway ติดต่อ Controller ได้ผ่านวิธี Adoption ที่เลือก
  3. Adopt Gateway เข้า Site ที่ถูกต้อง
  4. รอให้สถานะเป็น Connected ก่อน Provision ค่าอื่น
  5. ตรวจสอบ WAN, LAN, VLAN และ DHCP หลัง Adoption

ขั้นตอนที่ 4: กำหนด Hub

  1. เลือก Gateway ที่มี Public IP และ Internet เสถียรเป็น Hub
  2. เลือก WAN ที่จะเข้าร่วม SD-WAN
  3. ตรวจสอบว่า WAN ดังกล่าวไม่ได้เปิด DMZ
  4. กำหนด Public IP Pool หรือข้อมูล Public IP ตามหน้าจอของ Controller
  5. กำหนด Network Segment ของ HQ ที่ต้องการให้เข้าถึงผ่าน SD-WAN

ขั้นตอนที่ 5: เพิ่ม Spoke

  1. เลือก Site และ Gateway ของสาขาเป็น Spoke
  2. เลือก WAN ที่ต้องการใช้เชื่อมต่อ
  3. กำหนด Network Segment ของสาขาที่ต้องการนำเข้าสู่ระบบ
  4. ตรวจสอบว่าไม่มี Subnet ซ้ำกับ Hub หรือ Spoke อื่น
  5. รอให้ Spoke เชื่อมต่อ Hub สำเร็จ

ขั้นตอนที่ 6: กำหนด Policy

  1. ระบุ Source Site, Source Network และ Destination Site
  2. เลือก Application หรือ Service ที่ต้องการอนุญาต หากระบบรองรับ
  3. กำหนดเส้นทางหลักและเส้นทางสำรอง
  4. กำหนดให้ทราฟฟิกออกอินเทอร์เน็ตที่สาขาหรือผ่าน HQ ตาม Requirement
  5. บันทึกและรอ Controller Provision Configuration

ขั้นตอนที่ 7: ตรวจสอบผล

  1. ตรวจสอบสถานะ Hub และ Spoke
  2. ตรวจสอบ Tunnel และ Route
  3. ทดสอบ Ping ระหว่าง Gateway ก่อน
  4. ทดสอบจาก Client ไปยัง Server จริง
  5. ทดสอบ DNS, Application Port และ File Transfer
  6. ตรวจสอบ Log หากมีการ Drop หรือ Route ผิด

Multi-WAN: Load Balance และ Failover

การมี WAN สองเส้นไม่ได้ทำให้ระบบทนทานโดยอัตโนมัติ ต้องกำหนดวิธีตรวจสอบเส้นทางและทดสอบ Failover จริง

Load Balance

Load Balance กระจาย Session ออกหลาย WAN ตามสัดส่วนที่กำหนด ไม่ได้รวมความเร็วของ Connection เดียวให้สูงขึ้นเป็นผลรวมเสมอไป ตัวอย่างเช่น การดาวน์โหลดไฟล์หนึ่ง Session อาจยังออกเพียง WAN เดียว แต่ผู้ใช้หลายคนจะถูกกระจายไปยังหลายเส้น

Failover ใช้ WAN หลักเป็นปกติและเปลี่ยนไป WAN สำรองเมื่อ Online Detection ระบุว่าเส้นหลักใช้งานไม่ได้ ควรกำหนดเป้าหมายตรวจสอบมากกว่าหนึ่งแห่งเพื่อหลีกเลี่ยง False Positive หรือ False Negative

ข้อควรรู้เมื่อ WAN สลับเส้น

  • Public IP อาจเปลี่ยน ทำให้ Session เดิมหลุด
  • VPN Tunnel อาจต้องสร้างใหม่
  • Application ที่อ้างอิง Source IP อาจต้อง Login ใหม่
  • VoIP, Video Conference และ Remote Desktop อาจสะดุด
  • ควรทดสอบ Failover และ Failback แยกกัน

Policy Routing และ Internet Breakout

Policy Routing ใช้กำหนดว่าทราฟฟิกประเภทใดควรออก WAN ใดหรือผ่านเส้นทางใด ตัวอย่างเช่น

  • ERP และ POS ออก WAN1
  • Guest Wi-Fi ออก WAN2
  • Video Conference ใช้เส้นที่ Latency ต่ำกว่า
  • Backup ใช้ WAN สำรองในช่วงกลางคืน
  • ทราฟฟิกไป Server ที่ HQ วิ่งผ่าน SD-WAN

Local Internet Breakout หมายถึงให้สาขาออกอินเทอร์เน็ตผ่าน ISP ของสาขาโดยตรง เหมาะกับ Microsoft 365, Google Workspace, YouTube และบริการ Cloud ทั่วไป ช่วยลดโหลดที่ HQ

Central Internet Breakout หมายถึงส่งทราฟฟิกจากสาขาผ่าน Tunnel ไปออกอินเทอร์เน็ตที่ HQ เหมาะกับองค์กรที่ต้องการตรวจสอบ Log, Web Filtering หรือ Security จากจุดเดียว แต่จะเพิ่ม Bandwidth และ Latency ที่ Hub

องค์กรจำนวนมากใช้แบบผสม โดยให้ระบบภายในวิ่งผ่าน SD-WAN ส่วน Internet ทั่วไปออกที่สาขา และบังคับเฉพาะบริการสำคัญให้ผ่าน HQ

การออกแบบ Firewall และ ACL ระหว่าง Site

การสร้าง Tunnel สำเร็จไม่ได้หมายความว่าควร Allow ทุกเครือข่ายเข้าถึงกัน ควรใช้หลัก Least Privilege และกำหนดสิทธิ์ตามหน้าที่

ต้นทาง ปลายทาง แนวทาง
Office VLAN สาขา ERP Server ที่ HQ Allow เฉพาะ IP และ Port ของ ERP
Guest Wi-Fi Private Network ทุก Site Deny
CCTV VLAN NVR หรือ NAS Allow เฉพาะปลายทางและ Port ที่จำเป็น
IoT หรือ Scanner Application Server Allow เฉพาะ Service ที่ใช้งาน
IT Admin VLAN Gateway, Switch และ AP Allow Management เฉพาะทีม IT
Branch-to-Branch สาขาอื่น Deny เป็นค่าเริ่มต้นและเปิดเฉพาะกรณีจำเป็น

ควรจัดลำดับ Rule ให้ถูกต้อง ตรวจสอบ Direction ของ ACL และทดสอบทั้ง Allow และ Deny ไม่ใช่ทดสอบเฉพาะว่าระบบที่ต้องการใช้งานได้หรือไม่

DNS สำคัญพอ ๆ กับ Routing

หลายกรณี Ping IP ข้าม Site ได้ แต่เปิด ERP หรือ File Server ด้วยชื่อไม่ได้ สาเหตุมักมาจาก DNS ไม่ใช่ VPN

ควรวางแผนดังนี้

  • กำหนด DNS Server ที่ Client สาขาสามารถเข้าถึงได้
  • เปิด Firewall เฉพาะ TCP/UDP 53 ไปยัง DNS Server ที่กำหนด
  • ตรวจสอบ Internal DNS Zone และชื่อเครื่อง
  • ใช้ Conditional Forwarder หากมีหลาย Domain
  • ตรวจสอบว่า DHCP ของแต่ละ Site แจก DNS ถูกต้อง
  • หลีกเลี่ยงการใช้ชื่อเดียวกันกับ Public Domain โดยไม่มีแผน Split DNS

MTU, MSS และปัญหา Ping ได้แต่เปิดไฟล์ไม่ได้

VPN เพิ่ม Header ให้ Packet ทำให้ขนาดข้อมูลที่ส่งได้จริงลดลง หาก MTU ไม่เหมาะสมอาจเกิดอาการ Ping Packet เล็กได้ แต่เปิดเว็บไซต์บางแห่งไม่ได้ ดาวน์โหลดไฟล์ค้าง หรือ Remote Desktop หลุดเป็นช่วง ๆ

แนวทางตรวจสอบคือ

  • ทดสอบ Ping แบบกำหนดขนาด Packet และห้าม Fragment
  • ตรวจสอบ WAN ที่ใช้ PPPoE ซึ่งมักมี MTU ต่ำกว่า Ethernet ปกติ
  • ตรวจสอบ MSS Clamping หาก Gateway รองรับ
  • ตรวจสอบว่า Firewall ระหว่างทาง Block ICMP Fragmentation Needed หรือไม่
  • ทดสอบ File Transfer จริง ไม่ควรใช้ Ping เพียงอย่างเดียว

CCTV และการสำรองข้อมูลข้าม Site

กล้องวงจรปิดและ Backup เป็นทราฟฟิกต่อเนื่องที่กิน Bandwidth สูง หากส่งภาพหรือสำรองข้อมูลทั้งหมดกลับ HQ อาจทำให้ ERP, POS หรือ Video Conference ช้าลง

ก่อนออกแบบควรคำนวณ

  • จำนวนกล้อง
  • Bitrate ต่อกล้อง
  • จำนวน Stream ที่ส่งพร้อมกัน
  • Upload Speed ของสาขา
  • ช่วงเวลาที่ทำ Backup
  • Recovery Point Objective และ Recovery Time Objective

ควรใช้ QoS หรือ Bandwidth Control แยกทราฟฟิกสำคัญ และตั้ง Backup ให้วิ่งนอกเวลาทำการ หากต้องดูภาพจากส่วนกลางเป็นครั้งคราว อาจไม่จำเป็นต้องส่ง Recording ทั้งหมดกลับ HQ ตลอดเวลา

Monitoring ที่ควรทำ

  • สถานะ Hub, Spoke และ Tunnel
  • สถานะ WAN และ Public IP
  • Latency, Jitter และ Packet Loss ระหว่าง Site
  • Bandwidth Upload และ Download ของแต่ละ WAN
  • CPU และ Memory ของ Gateway
  • จำนวน Session และ VPN Tunnel
  • Event เมื่อ WAN Down, Tunnel Down หรือ Device Disconnected
  • Configuration Change Log
  • Firmware และ Controller Version
  • ผลการ Backup Configuration

หากองค์กรมีระบบ Monitoring อยู่แล้ว สามารถพิจารณา SNMP, Syslog หรือ Alert Integration ตามความสามารถของอุปกรณ์และ Controller Version ที่ใช้งาน

ตัวอย่าง Use Case: เชื่อม HQ กับคลังสินค้า

ความต้องการ แนวทางออกแบบ
พนักงานคลังใช้ ERP ที่ HQ นำ Office VLAN เข้าสู่ SD-WAN และเปิดเฉพาะ IP/Port ของ ERP
Scanner ส่งข้อมูลเข้า Application Server แยก Scanner VLAN และ Allow เฉพาะ Server ที่กำหนด
กล้องบันทึกที่สาขาและดูจาก HQ เปิดเฉพาะการเข้าถึง NVR หรือกล้องที่จำเป็น ไม่ส่งทุก Stream ตลอดเวลา
อินเทอร์เน็ตสาขาต้องไม่ล่มง่าย ใช้ WAN1 เป็น Business Internet และ WAN2 เป็น Broadband หรือ 5G พร้อม Failover
Guest Wi-Fi ห้ามเข้าระบบองค์กร แยก Guest VLAN, ออกอินเทอร์เน็ตที่สาขา และ Deny Private Network
ทีม IT บริหารจากส่วนกลาง Adopt Gateway, Switch และ AP เข้า Controller เดียวกันโดยแยก Site

ข้อผิดพลาดที่พบบ่อย

  • Subnet ซ้ำกัน: ทำให้ Route ไปปลายทางไม่ถูกต้อง
  • เข้าใจว่า Auto IPsec เท่ากับ SD-WAN ทุกอย่าง: ทำให้เลือกเมนูและออกแบบผิด
  • Hub ไม่มี Public IP: ทำให้ไม่ผ่าน Requirement ของระบบ
  • WAN ที่ใช้ SD-WAN เปิด DMZ อยู่: ขัดกับเงื่อนไขการใช้งาน
  • Firmware หรือ Hardware Version ไม่รองรับ: เมนู SD-WAN ไม่ปรากฏหรือทำงานไม่ครบ
  • Adopt ผิด Site: ทำให้ LAN, VLAN และ Policy ถูก Provision ผิดพื้นที่
  • เลือก Gateway จาก NAT Throughput อย่างเดียว: VPN Throughput ไม่เพียงพอ
  • Allow Any-to-Any: เพิ่มความเสี่ยงเมื่อสาขาใดสาขาหนึ่งถูกโจมตี
  • ทดสอบแค่ Ping: ไม่พบปัญหา DNS, MTU หรือ Application Port
  • ไม่ทดสอบ WAN Failover: มีเส้นสำรองแต่ใช้งานจริงไม่ได้
  • Online Detection ตรวจเพียงเป้าหมายเดียว: ทำให้สลับ WAN ผิดพลาด
  • ส่ง CCTV หรือ Backup เต็ม Bandwidth: กระทบระบบงานหลัก
  • เปิดพอร์ต Controller กว้างเกินไป: เพิ่มพื้นผิวการโจมตีจากอินเทอร์เน็ต
  • ไม่มี Configuration Backup: กู้ระบบยากเมื่อ Controller เสียหรืออัปเดตผิดพลาด

แนวทาง Troubleshooting

Gateway สาขาไม่ปรากฏใน Controller

  1. ตรวจสอบว่า Gateway ออกอินเทอร์เน็ตและ Resolve DNS ได้
  2. ตรวจสอบ Inform URL หรือ Controller Hostname/IP
  3. ตรวจสอบ Firewall และ Port ที่จำเป็นตาม Controller Version
  4. ตรวจสอบว่าอุปกรณ์ไม่ได้ถูก Adopt อยู่กับ Controller อื่น
  5. ตรวจสอบ Time และ NTP ของอุปกรณ์

Tunnel ขึ้นแต่สื่อสารข้าม Site ไม่ได้

  1. ตรวจสอบว่า Subnet ไม่ซ้ำกัน
  2. ตรวจสอบ Route และ Network Segment ที่เลือกเข้าสู่ SD-WAN
  3. ตรวจสอบ ACL และ Firewall ทั้งสองฝั่ง
  4. ตรวจสอบ Firewall บน Server หรือ Client ปลายทาง
  5. ทดสอบจาก Gateway ไป Gateway แล้วค่อยทดสอบ Client

Ping IP ได้แต่เปิดระบบด้วยชื่อไม่ได้

  1. ตรวจสอบ DNS ที่ Client ได้รับจาก DHCP
  2. ทดสอบ nslookup ไปยัง DNS Server
  3. ตรวจสอบ TCP/UDP 53
  4. ตรวจสอบ DNS Zone และชื่อ Record

ใช้งานได้แต่ช้าหรือหลุด

  1. ตรวจสอบ Latency, Jitter และ Packet Loss
  2. ตรวจสอบ Upload Speed ของทั้งสอง Site
  3. ตรวจสอบ CPU และ Session ของ Gateway
  4. ตรวจสอบ MTU และ MSS
  5. ปิดหรือจำกัด Backup และ CCTV ชั่วคราวเพื่อทดสอบ
  6. ตรวจสอบ QoS, Bandwidth Control และ Rate Limit

WAN สำรองไม่ทำงาน

  1. ตรวจสอบ Link และ IP ของ WAN สำรอง
  2. ตรวจสอบ Gateway และ DNS ของ WAN สำรอง
  3. ตรวจสอบ Online Detection
  4. ทดสอบถอดสาย WAN หลักจริง
  5. ตรวจสอบว่า VPN หรือ SD-WAN สามารถสร้าง Tunnel ผ่าน WAN สำรองได้

Checklist ก่อนเปิดใช้งานจริง

  • Gateway ทุก Site อยู่ใน Compatibility List
  • Firmware และ Controller Version เข้ากันได้
  • สำรอง Configuration ก่อนอัปเดต
  • Hub มี Public IP และ WAN ไม่เปิด DMZ
  • แต่ละ Site ใช้ Subnet ไม่ซ้ำกัน
  • Gateway ถูก Adopt เข้า Site ที่ถูกต้อง
  • LAN, VLAN และ DHCP ถูกต้อง
  • เลือก Network Segment เข้าสู่ SD-WAN เท่าที่จำเป็น
  • Hub และ Spoke แสดงสถานะ Connected
  • ทดสอบ Route ทั้งสองทิศทาง
  • ทดสอบ DNS และ Application จริง
  • Firewall และ ACL ใช้หลัก Least Privilege
  • Guest Wi-Fi ไม่เข้าถึง Private Network
  • ทดสอบ Load Balance, Failover และ Failback
  • ทดสอบ WAN สำรองกับ VPN หรือ SD-WAN จริง
  • ตรวจสอบ VPN Throughput ภายใต้โหลด
  • มี Alert สำหรับ WAN Down, Tunnel Down และ Device Offline
  • สำรอง Controller Configuration
  • มี IP Plan, VLAN Plan, Firewall Matrix และ Network Diagram
  • มีแผน Rollback หาก Cutover ไม่สำเร็จ

คำแนะนำด้าน Security

  • เปิด MFA สำหรับบัญชี Omada Cloud และบัญชีผู้ดูแลที่รองรับ
  • ใช้บัญชีแยกตามบุคคล ไม่ใช้ Admin Account ร่วมกัน
  • กำหนด Role ให้พนักงานเข้าถึงเฉพาะ Site ที่รับผิดชอบ
  • ไม่เปิด Controller Management Port สู่อินเทอร์เน็ตเกินความจำเป็น
  • จำกัด Source IP สำหรับ Remote Management หากทำได้
  • ใช้ HTTPS และ Certificate ที่เชื่อถือได้
  • แยก Management VLAN ออกจาก User VLAN
  • Deny Guest, IoT และ CCTV ไม่ให้เข้าถึง Management Network
  • อัปเดต Firmware หลังตรวจสอบ Release Note และ Backup แล้ว
  • ตรวจสอบ Log การ Login และ Configuration Change
  • ทบทวน Firewall Rule เป็นระยะและลบ Rule ที่ไม่ใช้งาน
  • สำรอง Configuration ไปยังพื้นที่ที่แยกจาก Controller

Omada SD-WAN มีข้อจำกัดอะไรบ้าง?

แม้ Omada SD-WAN จะช่วยลดความซับซ้อนและเหมาะกับธุรกิจหลายสาขา แต่ควรเข้าใจข้อจำกัดก่อนเลือกใช้งาน

  • ไม่ใช่ Gateway ทุก Hardware Version จะรองรับ SD-WAN
  • ต้องใช้ Firmware และ Controller Version ที่รองรับตรงกัน
  • Hub ต้องเป็น Site ที่มี Public IP ตามเงื่อนไขของระบบ
  • Network Segment ของทุก Site ห้ามซ้ำกัน
  • WAN ที่เข้าร่วม SD-WAN ห้ามเปิด DMZ
  • Feature Set อาจแตกต่างตาม Controller Version
  • ไม่ควรใช้แทน Enterprise SD-WAN โดยไม่เทียบ Requirement เช่น Dynamic Routing, Application Visibility, SLA-Based Steering และ Security Inspection
  • การเปลี่ยน WAN ยังอาจทำให้ Session เดิมหลุด แม้ระบบจะ Failover ได้
  • Controller ช่วยจัดการ Configuration แต่ไม่ได้ทำให้ Bandwidth, Latency หรือคุณภาพ ISP ดีขึ้นเอง

สรุป

การเชื่อมสำนักงานใหญ่และสาขาด้วย TP-Link Omada SD-WAN ช่วยลดความซับซ้อนของการดูแลเครือข่ายหลาย Site โดยนำการกำหนด Hub, Spoke, Network Segment, Policy และ Monitoring มาไว้ที่ Controller กลาง เหมาะกับธุรกิจที่ต้องการเชื่อม ERP, POS, File Server, NAS, CCTV หรือระบบงานภายในระหว่างหลายพื้นที่

อย่างไรก็ตาม Omada SD-WAN ไม่ใช่เพียงการกดสร้าง VPN แล้วจบ ระบบจะทำงานได้ดีเมื่อเริ่มจากการออกแบบที่ถูกต้อง ได้แก่ การเลือก Gateway จาก VPN Throughput, การวาง IP Plan และ VLAN ไม่ให้ซ้ำกัน, การเตรียม Public IP สำหรับ Hub, การตรวจสอบ Firmware Compatibility, การกำหนด Firewall แบบ Least Privilege และการทดสอบ Failover ภายใต้สถานการณ์จริง

องค์กรที่มีระบบไม่ซับซ้อนมากและต้องการบริหาร Gateway, Switch และ Access Point ใน Ecosystem เดียว สามารถใช้ Omada เป็นโซลูชันที่คุ้มค่าได้ แต่ควรทำ Proof of Concept และตรวจสอบ Requirement ก่อนนำไปใช้กับระบบสำคัญ หากออกแบบอย่างรอบคอบ Omada SD-WAN จะช่วยให้เครือข่ายหลายสาขามีความปลอดภัย เสถียร และดูแลต่อได้ง่ายขึ้นอย่างชัดเจน

แหล่งข้อมูลสำหรับตรวจสอบก่อนติดตั้ง

  • เอกสาร How to Configure SD-WAN via Omada Controller ของ TP-Link ตาม Controller Version ที่ใช้งาน
  • Omada Cloud SDN Platform Compatibility List
  • Release Note ของ Gateway Firmware แต่ละ Hardware Version
  • Omada Controller User Guide และรายการพอร์ตที่ใช้ตามเวอร์ชันจริง
  • Datasheet ของ Gateway สำหรับตรวจสอบ VPN Throughput และจำนวน Tunnel

ต้องการปรึกษาผู้เชี่ยวชาญ หรือขอใบเสนอราคา สามารถติดต่อได้ที่
E-Mail: [email protected]
Line@: @sync.co.th

ทางบริษัทฯ ขอสงวนสิทธิ์ในการรับผิดชอบใด ๆ อันเนื่องจากข้อผิดพลาดทางการพิมพ์ (ผิด/ตก)
*** สงวนสิทธิ์ในบทความนี้ โดย บริษัท ซิงค์เทค โซลูชั่น จำกัด ห้ามมิให้คัดลอก ดัดแปลง ทำซ้ำ โดยไม่ได้รับอนุญาตจากทางบริษัทเป็นลายลักษณ์อักษร ***