บทความโดย ดร. วิรินทร์ เมฆประดิษฐสิน
ก่อนที่เราจะก้าวเข้าสู่ยุค SD-WAN ที่ชาญฉลาดในปัจจุบัน การบริหารจัดการโครงข่ายระยะไกลหรือ Traditional WAN (Legacy WAN) มีความซับซ้อนและเป็นภาระอย่างยิ่งสำหรับวิศวกรเครือข่าย
สำหรับท่านที่อยู่ในวงการ Network มานาน คงจะจำภาพการคอนฟิก Router ทีละตัวผ่าน CLI ได้ดี ซึ่งลักษณะเด่นและข้อจำกัดของมันมีดังนี้
1. สถาปัตยกรรมแบบ Router-Centric (Hardware-Defined)
ในยุคนั้น “ความฉลาด” ทั้งหมดอยู่ที่ตัวอุปกรณ์ขอบ (Edge Router) แต่ละตัว
- Decentralized Control: การตัดสินใจส่งข้อมูล (Forwarding Decision) เกิดขึ้นที่ Router แต่ละตัวแบบอิสระ ผ่านตาราง Routing Table (เช่น OSPF, BGP)
- Static Configuration: หากต้องการเพิ่มสาขาใหม่ หรือเปลี่ยนนโยบายความปลอดภัย ท่านต้อง Remote เข้าไปจัดการทีละโหนด ซึ่งเสี่ยงต่อการเกิด Human Error และใช้เวลานาน (Manual Provisioning)
2. การพึ่งพาสายสัญญาณ MPLS เป็นหลัก
Traditional WAN เน้นการเชื่อมต่อที่ “เชื่อถือได้” ผ่านวงจรเช่าเหมาจ่าย
- Reliability vs. Cost: MPLS (Multi-Protocol Label Switching) ให้ท่านภาพสัญญาณ (SLA) ที่ดีเยี่ยม แต่มีราคาแพงมากและแบนด์วิดท์ต่ำเมื่อเทียบกับราคา
- Rigidity: การขยายแบนด์วิดท์ MPLS มักใช้เวลานานหลายสัปดาห์หรือเป็นเดือนในการติดตั้งจากผู้ให้บริการ (ISP)
3. ปรากฏการณ์ Backhauling (Hairpinning)
นี่คือจุดอ่อนสำคัญเมื่อองค์กรเริ่มใช้ Cloud
- Centralized Internet: ทราฟฟิกอินเทอร์เน็ตจากสาขา (Branch) จะไม่ได้รับอนุญาตให้ออกเน็ตโดยตรง แต่ต้องวิ่งผ่านสาย MPLS กลับมาที่ Headquarter (HQ) เพื่อผ่าน Firewall ส่วนกลางก่อน แล้วจึงออกสู่อินเทอร์เน็ต
- Latency Issue: การดึงทราฟฟิกอ้อมไปอ้อมมาทำให้เกิดความหน่วงสูง (Latency) และทำให้สาย MPLS ที่แพงอยู่แล้วเต็มไปด้วยทราฟฟิกที่ไม่จำเป็น เช่น YouTube หรือ Microsoft 365
4. ขาดความสามารถในการรับรู้แอปพลิเคชัน (Application Unawareness)
Router สมัยก่อนมองเห็นแค่ IP และ Port (Layer 3/4)
- Blind Routing: มันไม่รู้ว่าแพ็กเก็ตที่ส่งมาคือวิดีโอคอล (Critical) หรือการดาวน์โหลดไฟล์ทั่วไป (Non-critical) ทำให้การทำ QoS (Quality of Service) ซับซ้อนและไม่ยืดหยุ่นพอที่จะปรับตามสภาวะโครงข่ายที่เปลี่ยนแปลงไปแบบ Real-time
ในแบบจำลองเก่า แอปพลิเคชันต่าง ๆ จะถูกติดตั้งไว้ที่ Data Center (ศูนย์ข้อมูลหลัก) ขององค์กร โดยมีเครือข่ายบริเวณกว้าง (WAN) ทำหน้าที่เชื่อมต่อสาขาต่าง ๆ เข้ากับศูนย์ข้อมูลนี้
1. การทำงานของระบบ (How it works)
- การเข้าถึงแอปพลิเคชัน: แอปที่สำคัญที่สุดคือระบบขายหน้าร้าน (POS – Point of Sale) ซึ่งถูกโฮสต์ไว้ที่ Data Center ผู้ใช้งานที่สาขา (Store) จะเข้าถึงระบบนี้ผ่านวงจร MPLS เป็นหลัก
- ระบบสำรอง: จะมีลิงก์อินเทอร์เน็ต (INET) สำรองไว้ในโหมด “Active-Standby” คือจะปล่อยว่างไว้เฉย ๆ และจะถูกนำมาใช้ก็ต่อเมื่อวงจรหลัก (MPLS) เกิดขัดข้องเท่านั้น
- การใช้อินเทอร์เน็ต: เมื่อพนักงานที่สาขาต้องการเข้าเว็บหรือใช้อินเทอร์เน็ต ทราฟฟิกข้อมูลจะต้องถูกส่งวิ่งกลับไปที่ Data Center ก่อน เพื่อผ่านระบบรักษาความปลอดภัยกลาง แล้วจึงค่อยออกสู่อินเทอร์เน็ต (เรียกว่าการทำ Backhauling)
2. ข้อจำกัดและลักษณะเฉพาะ
- ยึดติดกับฮาร์ดแวร์ (Hardware-centric): เครือข่ายแบบนี้มีความตายตัว (Static) การจะเปิดสาขาใหม่แต่ละครั้งต้องใช้เวลาเตรียมการหลายสัปดาห์ ทั้งการสั่งวงจร WAN และการตั้งค่าอุปกรณ์แบบ “Manual” ทีละกล่อง
- ขอบเขตความปลอดภัย (Security Perimeter): มีการแบ่งแยกชัดเจนว่าสิ่งที่อยู่ในเครือข่ายองค์กรคือ “พื้นที่ปลอดภัย” (Trusted) ส่วนอินเทอร์เน็ตภายนอกคือ “พื้นที่ไม่ปลอดภัย” (Untrusted)
- การรวมศูนย์ความปลอดภัย: อุปกรณ์ป้องกันต่าง ๆ เช่น Firewall, IPS, และ Proxy จะถูกติดตั้งรวมกันไว้ที่ Data Center เพียงแห่งเดียว เพื่อตรวจสอบข้อมูลทุกอย่างที่เข้า-ออก
จากภาพที่ 1.1 จะเห็นว่า
- ด้านซ้าย: คือกลุ่มผู้ใช้งาน (Users), กล้องวงจรปิด และระบบต่าง ๆ ในร้านสาขา (Store-1 ถึง Store-N)
- ตรงกลาง: คือเส้นทางการเชื่อมต่อผ่าน MPLS (เส้นหลัก) และ INET (เส้นสำรอง)
- ด้านขวา: คือศูนย์ข้อมูล (Data Center) ซึ่งเป็นที่เก็บ Servers, Applications และเป็นจุดทางออกอินเทอร์เน็ต (Internet Access) เพียงจุดเดียวของทั้งองค์กร
ภาพที่ 1.1 แสดง Traditional network
แม้ว่าโมเดลนี้จะไม่มีประสิทธิภาพมากนัก แต่มันก็ทำงานได้ค่อนข้างดีมาเป็นเวลานาน ทั้งหมดนี้เป็นไปได้เพราะแอปพลิเคชัน ฐานข้อมูล และข้อมูลสำคัญของบริษัทต่างๆ ยังคงถูกโฮสต์ไว้ในศูนย์ข้อมูล (Data Center) และ ขอบเขตของเครือข่าย (Network Perimeter) ถูกกำหนดไว้อย่างดีและมีความตายตัว (Static) มาก ทราฟฟิกส่วนใหญ่มีปลายทางอยู่ที่ตำแหน่งเดียวที่ระบุไว้อย่างชัดเจน (นั่นคือศูนย์ข้อมูล) ซึ่งทำหน้าที่เป็นช่องทางออก (Gateway) สู่อินเทอร์เน็ตด้วย
และแล้ว “พับลิกคลาวด์” (Public Cloud) ก็มาถึง
ในช่วงกลางทศวรรษ 2010 องค์กรต่าง ๆ เริ่มตระหนักถึงประโยชน์ของการประมวลผลแบบคลาวด์ ซึ่งช่วยในการประหยัดต้นทุนและมีความสามารถในการขยายระบบได้อย่างรวดเร็ว (Dynamic Scalability) คลาวด์ถือเป็นการเปลี่ยนผ่านทางความคิด (Paradigm Shift) ครั้งสำคัญในอุตสาหกรรม และได้เปลี่ยนวิธีที่องค์กรคิดเกี่ยวกับโครงสร้างพื้นฐานด้านไอทีของตน แอปพลิเคชันต่าง ๆ เริ่ม ย้ายออกจากศูนย์ข้อมูล และเข้าไปสู่พับลิกคลาวด์ในอัตราที่เพิ่มสูงขึ้นเรื่อย ๆ แอปพลิเคชันบางตัวในปัจจุบันถึงกับถูกพัฒนาขึ้นบนคลาวด์โดยตรง (เรียกว่า Cloud-native หรือ แอปที่เกิดบนคลาวด์)
อย่างไรก็ตาม เครือข่ายบริเวณกว้างแบบดั้งเดิม (Traditional WAN) ถูกออกแบบมาเพื่อเชื่อมต่อผู้ใช้ที่สาขาทางไกลเข้ากับแอปพลิเคชันที่โฮสต์อยู่ในศูนย์ข้อมูล แม้ว่าในปัจจุบันบริการบางอย่างจะถูกโฮสต์ไว้บนพับลิกคลาวด์และอินเทอร์เน็ตแล้วก็ตาม แต่ทราฟฟิกจากสาขาทางไกลก็ยังคงต้องวิ่งไปที่ศูนย์ข้อมูลก่อน จากนั้นจึงจะถูกส่งต่อไปยังพับลิกคลาวด์และส่งกลับมา ดังที่แสดงในภาพที่ 1.2
ภาพที่ 1.2 การเชื่อมต่อของเครือข่ายแบบเก่ากับ Data Center และ Internet
ในช่วงเวลาเดียวกันนั้น โมเดลที่เปลี่ยนอุตสาหกรรมอีกรูปแบบหนึ่งก็ได้อุบัติขึ้น เรียกว่า Software as a Service (SaaS) องค์กรทุกรูปแบบและทุกขนาดเริ่มย้ายออกจากระบบที่ติดตั้งในพื้นที่ (On-premises) และหันไปใช้แอปพลิเคชันทางธุรกิจในรูปแบบบริการผ่านอินเทอร์เน็ต ตัวอย่างของแอปพลิเคชันที่เป็น Native ทางอินเทอร์เน็ต ได้แก่ Office 365, Google Workplace, Salesforce และอื่น ๆ
ผลจาก SaaS และพับลิกคลาวด์ (Public Cloud) ทำให้ในปัจจุบันทราฟฟิกข้อมูลส่วนใหญ่ที่สาขาทางไกลมีปลายทางอยู่ที่ “อินเทอร์เน็ต” แทนที่จะเป็น “ศูนย์ข้อมูล” (Data Center) สิ่งนี้ได้เปลี่ยนขอบเขตของเครือข่ายบริเวณกว้าง (WAN) และขอบเขตด้านความปลอดภัยไปอย่างสิ้นเชิง ทีมเครือข่ายและความปลอดภัยเริ่มตระหนักว่า สถาปัตยกรรม WAN แบบดั้งเดิมนั้นไม่มีความพร้อมเพียงพอที่จะมอบการเชื่อมต่อจาก “สาขาสู่อินเทอร์เน็ต” (Branch-to-Internet) และ “สาขาสู่คลาวด์ใด ๆ” (Branch-to-any-cloud) ได้อย่างน่าเชื่อถือและปลอดภัย เนื่องจากเทคโนโลยีเครือข่ายแบบเก่านั้นไม่ได้ถูกสร้างขึ้นโดยคำนึงถึงแอปพลิเคชันบนคลาวด์เป็นหลัก จึงไม่สามารถมอบท่านสมบัติด้านการขยายตัว (Scalability) ความยืดหยุ่น และความปลอดภัยที่องค์กรในปัจจุบันต้องการได้
ความท้าทายหลักที่องค์กรต้องเผชิญเมื่อใช้คลาวด์และ SaaS คือ WAN แบบดั้งเดิมไม่ได้ใช้ระบบรักษาความปลอดภัยที่สาขาทางไกล ทราฟฟิกของผู้ใช้ทั้งหมดถูกกำหนดให้ต้องส่งไปตรวจสอบที่ระบบความปลอดภัย (Security Stack) ของศูนย์ข้อมูลก่อน จากนั้นจึงจะถูกส่งออกไปสู่อินเทอร์เน็ตและส่งกลับมา ดังที่แสดงในภาพที่ 1.3
ภาพที่ 1.3 แสดงปัญหา Backhauling จากการส่งทราฟฟิกอินเทอร์เน็ตกลับไปที่ศูนย์ข้อมูล
อย่างไรก็ตาม การส่งทราฟฟิกอินเทอร์เน็ตกลับไปที่ศูนย์ข้อมูล (Backhauling) ก่อให้เกิด คอขวด (Bottleneck) และความไม่มีประสิทธิภาพหลายประการ เช่น
- มีค่าความหน่วง (Latency) สูงขึ้น และการเชื่อมต่อไม่น่าเชื่อถือ เนื่องด้วยระยะทางทางภูมิศาสตร์ที่ห่างกันระหว่างสาขาและศูนย์ข้อมูล
ผลกระทบจากการส่งทราฟฟิกกลับไปที่ศูนย์ข้อมูล
- ขอบเขตความเสียหายกว้างขึ้น (Larger fault domains): และการต้องพึ่งพาศูนย์ข้อมูลมากเกินไป (อาจกลายเป็นจุดที่ถ้าพังจุดเดียว ระบบจะล่มทั้งหมด หรือ Single point of failure)
- คอขวดของแบนด์วิดท์: เกิดขึ้นที่ลิงก์ WAN ของศูนย์ข้อมูล
- คอขวดด้านประสิทธิภาพ: เกิดขึ้นที่ระบบความปลอดภัย (Security Stack) ของศูนย์ข้อมูล
- ไม่สามารถใช้บริการ DNS และ Geo-location ที่สาขาได้: (เช่น การเข้าเว็บแล้วถูกส่งไป Server ที่อยู่ไกลกว่าความเป็นจริงเพราะระบบคิดว่าเราอยู่ที่ศูนย์ข้อมูล)
- สรุปประเด็นสำคัญ: ประสบการณ์การใช้งานแอปพลิเคชันแย่ลง ซึ่งส่งผลให้พนักงานไม่มีประสิทธิภาพในการทำงาน ลูกค้าไม่พอใจ และสูญเสียรายได้
ทำไมไม่ปล่อยให้สาขาเชื่อมต่ออินเทอร์เน็ตโดยตรง?
ทางออกหนึ่งที่ฟังดูสมเหตุสมผลสำหรับปัญหา “การส่งทราฟฟิกกลับไปยังศูนย์ข้อมูล” คือการอนุญาตให้สาขาส่งทราฟฟิกออกสู่อินเทอร์เน็ตได้โดยตรงผ่านวงจรอินเทอร์เน็ตในพื้นที่นั้น ๆ ทีมเครือข่ายสามารถทำได้ง่าย ๆ โดยการตั้งค่าเส้นทางเริ่มต้น (Default Route) ไปยังผู้ให้บริการอินเทอร์เน็ต (ISP) ในพื้นที่และเปิดใช้งาน NAT ซึ่งจะช่วยลดค่าความหน่วง (Latency) และยกระดับประสบการณ์การใช้งานแอปพลิเคชันคลาวด์ได้อย่างมาก
อย่างไรก็ตาม การข้ามระบบความปลอดภัยส่วนกลางและเปิดให้สาขาเข้าถึงอินเทอร์เน็ตได้ทั้งหมด ทำให้องค์กรเสี่ยงต่อภัยคุกคามทางไซเบอร์ที่ร้ายแรง เช่น
- ผู้ใช้เข้าถึงเว็บไซต์หรือแหล่งเก็บข้อมูลที่ไม่ได้รับอนุญาต
- การจารกรรมข้อมูลลูกค้าหรือข้อมูลลับขององค์กร
- การโจมตีแบบ Phishing และ Spearfishing (การหลอกลวงเพื่อขโมยข้อมูล)
- ไวรัส, สปายแวร์ และโทรจัน
- มัลแวร์เรียกค่าไถ่ (Ransomware)
- สรุปประเด็นสำคัญ: ประสบการณ์ลูกค้าแย่ลง เสื่อมเสียชื่อเสียงแบรนด์ และอาจมีความรับผิดชอบทางกฎหมายตามมา
ดังนั้น หากองค์กรต้องการให้สาขาออกอินเทอร์เน็ตได้เอง (Local Internet Exit) องค์กรจะต้องติดตั้งอุปกรณ์รักษาความปลอดภัย (Firewalls, IPS, Proxies ฯลฯ) ไว้ที่ทุก ๆ สาขา
ทว่า ในสถาปัตยกรรม WAN แบบดั้งเดิมที่ยึดฮาร์ดแวร์เป็นหลัก นั่นหมายถึงการต้องติดตั้งอุปกรณ์รักษาความปลอดภัยที่เป็นเครื่องจริง (Hardware Appliances) หนึ่งเครื่องหรือหลายเครื่องในแต่ละสาขา ท่านคงจินตนาการได้ว่าแนวทางนี้จะมี ค่าใช้จ่ายสูง ล่าช้า และไม่สามารถขยายระบบได้ (Unscalable) สำหรับองค์กรที่มีสาขาหลายพันแห่ง วิธีนี้แทบจะเป็นไปไม่ได้เลยในทางปฏิบัติ
ความท้าทายไม่ได้หยุดอยู่แค่เรื่องความปลอดภัย เราต่างรู้ดีว่าวงจรอินเทอร์เน็ตไม่มีการรับประกันท่านภาพ (QoS) และเส้นทางบนอินเทอร์เน็ตอาจเกิดประสิทธิภาพถดถอยได้ทุกเมื่อ หากองค์กรต้องเชื่อมต่อกับแอปพลิเคชันที่สำคัญต่อธุรกิจผ่านอินเทอร์เน็ต ทีมเครือข่ายจะรับประกันท่านภาพการใช้งาน (Quality of Experience) ของแอปพลิเคชันได้อย่างไร?
ภาพที่ 1.4 แอปพลิเคชันย้ายออกจากศูนย์ข้อมูล
ความรับผิดชอบที่เปลี่ยนไปของวิศวกรเครือข่าย
ในที่สุดแล้ว พวกเราในฐานะวิศวกรเครือข่ายมีหน้าที่รับผิดชอบในการ รับประกันประสิทธิภาพเครือข่ายของทุกแอปพลิเคชัน ที่องค์กรต้องพึ่งพา ไม่ว่าเราจะเป็นเจ้าของเส้นทางเครือข่ายเหล่านั้นหรือไม่ก็ตาม อย่างไรก็ตาม เมื่อมีพับลิกคลาวด์และ SaaS เข้ามา เรากลับต้องมารับผิดชอบทั้งเครือข่ายภายในของเราเอง, ผู้ให้บริการอินเทอร์เน็ต (ISPs), ไปจนถึงเครือข่ายของผู้ให้บริการคลาวด์และ SaaS รวมถึง ISPs ที่พวกเขาใช้ด้วย ฝั่งธุรกิจเขาไม่สนใจหรอกว่าจะมีแพ็กเกจข้อมูลสูญหาย (Packet Loss) บนอินเทอร์เน็ตหรือไม่ (ทั้งที่เราไม่ได้เป็นคนคุมอินเทอร์เน็ต) พวกเขาแค่ต้องการให้แอปพลิเคชันใช้งานได้ก็พอ
เราจำเป็นต้องมี ความสามารถในการมองเห็น (Visibility) เส้นทางเครือข่ายที่วิ่งผ่านอินเทอร์เน็ตไปยังผู้ให้บริการ SaaS และคลาวด์ และเราต้องการเครือข่ายที่สามารถ เปลี่ยนเส้นทางใหม่ (Reroute) ได้ทันทีเมื่อประสิทธิภาพเครือข่ายภายนอกลดลง แต่สิ่งนี้ทำได้ยากมากหากยังใช้เทคโนโลยีการเลือกเส้นทาง (Routing) และการสลับสัญญาณ (Switching) แบบดั้งเดิม
และแล้ว “การทำงานจากทางไกล” (Remote Work) ก็มาถึง
นอกเหนือจาก SaaS และพับลิกคลาวด์แล้ว ยังมีแนวโน้มทางเทคโนโลยีอีกอย่างหนึ่งที่สร้างความท้าทายใหม่ให้กับ WAN นั่นคือ การทำงานจากที่ไหนก็ได้ (Working from anywhere) ได้กลายเป็นมาตรฐานชั่วข้ามคืน การประชุมออนไลน์ การสัมมนาทางไกล หรือแม้แต่การนั่งทำงานจากร้านกาแฟแถวบ้าน กลายเป็นกิจวัตรปกติในยุคนี้ การนำเทคโนโลยีเซลลูลาร์บรอดแบนด์ใหม่ ๆ เช่น 4G/5G มาใช้ ช่วยให้สามารถเข้าถึงเครือข่ายที่มีแบนด์วิดท์สูงและความหน่วงต่ำในสถานที่ใหม่ ๆ ที่เมื่อก่อนไม่สามารถนั่งทำงานได้
ภาพที่ 1.5 การประยุกต์ใช้งาน security ที่ Remote site
วิเคราะห์จากภาพที่ 1.5 การติดตั้งระบบความปลอดภัยที่สาขา
ในรูปนี้แสดงภาพความพยายามที่จะแก้ปัญหาด้วยวิธีเดิม (Legacy Approach)
- Users located everywhere: ผู้ใช้งานกระจายอยู่ทุกที่ ทั้งที่บ้าน (SoHo), สาขา (Branch), วิทยาเขต (Campus) รวมถึงใช้อุปกรณ์ส่วนตัว (BYOD) และ IoT
- Applications hosted everywhere: แอปฯ กระจายอยู่ทั้งบน IaaS (AWS, Azure), SaaS และ On-prem ที่ Data Center
- The Struggle: การพยายามติดตั้ง Firewall ไว้ที่ทุกจุดเชื่อมต่อ (สาขา, แคมปัส, บ้าน) เพื่อให้ออกอินเทอร์เน็ตได้โดยตรง แต่นี่คือภาระมหาศาลในการจัดการและมีค่าใช้จ่ายสูงมาก
ปัจจุบันพนักงานใช้อุปกรณ์ส่วนตัวที่หลากหลายในการเชื่อมต่อเครือข่าย เพื่อเข้าถึงแอปพลิเคชันที่สำคัญต่อธุรกิจและข้อมูลลับขององค์กร การทำงานจากทางไกล (Remote working) ได้เปลี่ยนขอบเขตของเครือข่ายบริเวณกว้าง (WAN) และข้อกำหนดด้านความปลอดภัยไปอย่างสิ้นเชิง
ทีมความปลอดภัยต้องเผชิญกับความท้าทายอันใหญ่หลวงในการรักษาความปลอดภัยของขอบเขตเครือข่ายตั้งแต่เริ่มมีการนำพับลิกคลาวด์มาใช้ อย่างไรก็ตาม เมื่อพนักงานทำงานจากทางไกลและเข้าถึงแอปพลิเคชันจากทุกที่ การมอบความปลอดภัยแบบต้นทางถึงปลายทาง (End-to-end security) และการรับประกันท่านภาพการใช้งาน (Quality of experience) ให้สมบูรณ์แบบนั้นกลายเป็นเรื่องที่เป็นไปไม่ได้ด้วยเทคโนโลยีเครือข่ายที่มีอยู่เดิม พนักงานแต่ละคนที่ทำงานจากที่บ้านหรือร้านกาแฟในห้างสรรพสินค้า ต่างต้องการการเข้าถึงแอปพลิเคชันสำคัญและข้อมูลองค์กรที่โฮสต์ไว้ทั้งแบบ On-prem หรือบนคลาวด์อย่างปลอดภัย
ในสถาปัตยกรรม WAN แบบดั้งเดิม พนักงานที่ทำงานทางไกลจะเข้าถึงเครือข่ายองค์กรผ่าน SSL VPN (เช่น Cisco AnyConnect) ไปยังศูนย์ข้อมูล (Data Center) แต่ด้วยการที่แอปพลิเคชันจำนวนมากถูกโฮสต์ไว้นอกสถานที่ (Off-prem) และใช้งานในรูปแบบบริการ การส่งทราฟฟิกของผู้ทำงานทางไกลกลับไปที่ศูนย์ข้อมูล (Backhauling) แล้วจึงค่อยออกสู่อินเทอร์เน็ต ก่อให้เกิดความไม่มีประสิทธิภาพมากมาย เช่น ประสบการณ์การใช้งานแอปพลิเคชันที่แย่ลง และการเชื่อมต่อที่ไม่น่าเชื่อถือ แม้ว่าเทคนิคที่เรียกว่า “split-tunneling” จะช่วยให้ผู้ใช้ VPN เข้าถึงอินเทอร์เน็ตโดยตรงจากที่บ้านพร้อมกับเข้าถึงเครือข่ายองค์กรผ่าน VPN ไปด้วยได้ แต่วิธีนี้ก็ทำให้องค์กรเสี่ยงต่อช่องโหว่ด้านความปลอดภัยที่ร้ายแรง
สรุปประเด็นสำคัญคือ: พับลิกคลาวด์และ SaaS ได้ผลักดันให้ “แอปพลิเคชัน” หลุดออกไปนอกขอบเขตของ WAN แบบเดิม ส่วนการทำงานทางไกลก็ได้ผลักดันให้ “ผู้ใช้งาน” ออกไปไกลเกินกว่าขอบเขตเครือข่ายแบบเดิมเช่นกัน ตอนนี้ทีมเครือข่ายและความปลอดภัยจึงต้องเผชิญกับความท้าทายครั้งใหญ่ในการปกป้อง WAN ขององค์กรที่มีผู้ใช้งานอยู่บน อุปกรณ์ใดก็ได้ จากที่ไหนก็ได้ และเข้าถึงแอปพลิเคชันบนพับลิกคลาวด์ใดก็ได้
ทั้งหมดนี้นำไปสู่สภาวะ “เครือข่ายกระจัดกระจาย” (Network Sprawl)
เป็นเวลาหลายปีที่เครือข่ายถูกติดตั้งและใช้งานด้วยการจัดการแบบแมนนวล (Manual) ในสภาพแวดล้อม WAN แบบดั้งเดิม การจะทำให้เครือข่ายทำงานได้ตามสถานะที่ต้องการ อุปกรณ์เครือข่ายแต่ละตัวจะต้องถูกปรับแต่งค่า (Configure) ทีละตัวโดยผู้ดูแลระบบเครือข่ายผ่าน CLI (Command Line Interface) ในลักษณะที่ยึดอุปกรณ์ฮาร์ดแวร์เป็นหลักแบบ “กล่องต่อกล่อง” (Box-to-box) ดังที่จะแสดงในภาพที่ 1.5
ประเด็นน่าสนใจ
- Split-tunneling: เป็นจุดที่น่ากังวล เพราะถึงจะเร็วขึ้น (เพราะไม่ต้องวิ่งอ้อมไป Data Center) แต่ข้อมูลที่ออกเน็ตไปตรง ๆ นั้นไม่มี Firewall องค์กรคอยคุม
- Box-to-box configuration: นี่คือ “ฝันร้าย” ของคนทำงาน Network ครับ เพราะถ้ามี 100 สาขา ก็ต้องพิมพ์คำสั่งเดิม ๆ 100 ครั้ง โอกาสพลาดสูงมาก
ภาพที่ 1.6 แบบจำลองการทำงานแบบกระจายศูนย์
การบริหารจัดการเครือข่ายแบบกระจายศูนย์
ในยุคของเครือข่ายแบบดั้งเดิม ผู้ใช้งาน (วิศวกร) จะต้อง ตั้งค่าอุปกรณ์ทีละชิ้น (Individual Components) เพื่อให้ระบบ (เครือข่าย) ทำงานได้ ลองนึกถึงสมัยก่อนของคอมพิวเตอร์ส่วนบุคคล (PC) การจะติดตั้งฮาร์ดแวร์หรือซอฟต์แวร์ใหม่ ผู้ใช้ต้องตั้งค่าองค์ประกอบแต่ละส่วนของ PC เอง ตัวอย่างเช่น หากท่านซื้อซาวด์การ์ด (Sound Card) มาใหม่ ท่านต้องติดตั้งการ์ดลงไป จากนั้นไปที่เว็บไซต์ของผู้ผลิตเพื่อดาวน์โหลดไดรเวอร์ (Drivers) สำหรับระบบปฏิบัติการของท่าน แล้วท่านก็ต้องติดตั้งไดรเวอร์และแก้ปัญหาความไม่เข้ากัน (Incompatibility) ต่างๆ กว่าที่ท่านจะได้เริ่มฟังเพลงในที่สุด
ภาพที่ 1.7 คอมพิวเตอร์ในฐานะระบบ
ทีนี้ลองเปรียบเทียบกับกระบวนการในปัจจุบัน ท่านแค่เสียบอุปกรณ์ฮาร์ดแวร์ชิ้นใหม่เข้าไป แล้วเครื่อง PC จะจัดการทุกอย่างที่เหลือให้เอง ท่านเพียงแค่ แสดงความจำนง (Signify the intent) ว่าต้องการฟังเพลง แล้วระบบปฏิบัติการจะจัดการตั้งค่าองค์ประกอบพื้นฐานทั้งหมดที่จำเป็นในการเล่นเพลงให้ ดังที่แสดงในภาพที่ 1.7 ท่านกำลังใช้งานคอมพิวเตอร์ในฐานะ “ระบบเดียว” ไม่ใช่ในฐานะกลุ่มของอุปกรณ์ที่แยกส่วนกัน
ผู้ให้บริการพับลิกคลาวด์ (Public Cloud) ก็ใช้โมเดลการทำงานแบบเดียวกันนี้ เมื่อท่านต้องการสร้างเราเตอร์ใหม่หรือสร้างวงเครือข่ายย่อย (Subnet) ใหม่บนคลาวด์ ท่านเพียงแค่ประกาศความต้องการของท่าน (Declare your intent) แล้วผู้ให้บริการคลาวด์จะจัดการตั้งค่าส่วนประกอบพื้นฐานทั้งหมดที่อยู่เบื้องหลังให้เองโดยที่ท่านไม่ต้องลงมือทำทีละส่วน
สรุปประเด็นสำคัญ: การบริหารจัดการตามเป้าหมาย (Intent-Based)
- แบบเดิม (Manual/Decentralized): ท่านต้องรู้ “วิธีการ” (How) และต้องไปแก้คำสั่งที่ Switch, Router, Firewall ทีละตัว
- แบบใหม่ (System/Intent-Based): ท่านบอกแค่ “ความต้องการ” (What) เช่น “อยากให้สาขาคุยกับคลาวด์ได้” แล้วระบบ (เช่น SD-WAN Controller) จะไปสั่งงานอุปกรณ์ทั้งหมดในเครือข่ายให้ทำงานสอดประสานกันเองเหมือนเป็นระบบเดียว
ทำไมเราถึงไม่นำตรรกะนี้มาใช้กับเครือข่ายบริเวณกว้าง (WAN)? ทำไมเครือข่ายถึงไม่สามารถถูกมองและบริหารจัดการ ในฐานะระบบหนึ่งเดียว (As a system)? ทำไมเรายังต้องใช้งานมันในลักษณะที่เป็นกลุ่มของอุปกรณ์แยกชิ้น เช่น เราเตอร์, สวิตช์ และไฟร์วอลล์ เหมือนดังที่แสดงในภาพที่ 1.8
ภาพที่ 1.8 เครือข่ายที่ทำงานในฐานะระบบ
- ผู้ใช้งานระบุความจำนง (Signify intent): เพื่อเข้าใช้งานระบบ (เครือข่าย)
- ระบบจะตั้งค่าองค์ประกอบพื้นฐานทั้งหมด (Configure all underlying components): ซึ่งก็คืออุปกรณ์เครือข่ายต่าง ๆ ให้โดยอัตโนมัติ
โมเดลการทำงานแบบกระจายศูนย์ (Decentralized) ที่ใช้ในสภาพแวดล้อมเครือข่ายแบบดั้งเดิม ได้กลายเป็นปัญหาสำคัญในปัจจุบัน เราทุกคนเห็นแล้วว่าการผสมผสานระหว่างเทคโนโลยีเครือข่ายและความปลอดภัยนั้นเติบโตขึ้นอย่างไม่หยุดยั้ง ทั้งขนาด (Scale), ความซับซ้อน และความเร็วในการทำงานของแผนกเครือข่ายและความปลอดภัยต่างก็เพิ่มขึ้นอย่างต่อเนื่อง
ผู้ผลิตอุปกรณ์ (Vendors) ต่างตระหนักดีว่าลูกค้าเริ่มหยุดซื้อโซลูชันของตน เพราะมันกลายเป็นเรื่องที่ซับซ้อนเกินไปในการออกแบบ, ติดตั้ง, ใช้งาน และการปลดระวางแต่ละองค์ประกอบของเครือข่ายและระบบความปลอดภัย ยิ่งไปกว่านั้น การเลือกซื้อและการจัดซื้อก็กลายเป็นเรื่องที่ซับซ้อนอย่างเหลือเชื่อ มีผลิตภัณฑ์นับพันรายการ, รหัสสินค้า (Part numbers), คู่มือการสั่งซื้อ, รูปแบบลิขสิทธิ์ (Licensing), และการบริการหลังการขาย ฯลฯ องค์กรในปัจจุบันต้องการโซลูชันที่เป็นหนึ่งเดียว (Unified Solution) ที่สามารถมอบท่านสมบัติทั้งด้านเครือข่ายและความปลอดภัย และถูกบริหารจัดการในรูปแบบ “ระบบ” ไม่ใช่กลุ่มของอุปกรณ์ที่แยกส่วนกัน
นอกจากนี้ การใช้ระบบอัตโนมัติ (Automation) ในการติดตั้งและดูแลโครงสร้างพื้นฐานได้เปลี่ยนจากสิ่งที่ “มีก็ดี” (Good to have) กลายเป็น “ความจำเป็น” (Necessity) แนวทางการทำงานแบบ DevOps กล่าวไว้ว่า วิศวกรเครือข่ายและความปลอดภัยควรให้ความสำคัญกับงานเชิงกลยุทธ์ที่สำคัญ มากกว่าที่จะมาเสียเวลากับงานทำซ้ำแบบแมนนวล ทุกวันนี้ ผู้นำองค์กรต้องการสภาพแวดล้อมเครือข่ายที่คล่องตัว (Agile) และเป็นอัตโนมัติ ซึ่งสามารถทำงานในฐานะระบบและตอบสนองต่อความต้องการทางธุรกิจได้อย่างรวดเร็ว
ความต้องการ WAN ยุคใหม่ (The need for a next-generation WAN)
แนวโน้มยุคใหม่ทั้งหมดในอุตสาหกรรมไอทีเหล่านี้มีสิ่งหนึ่งที่เหมือนกัน นั่นคือ พวกเขาต้องการเครือข่ายยุคใหม่ (Next-generation networks) สถาปัตยกรรม WAN แบบดั้งเดิมไม่สามารถทำงานได้ดีอีกต่อไปในโลกดิจิทัลที่แอปพลิเคชันอยู่นอกศูนย์ข้อมูล และผู้ใช้งานแอปฯ เหล่านั้นใช้อุปกรณ์พกพาที่หลากหลายและเข้าถึงข้อมูลที่ละเอียดอ่อนจากทุกที่ แต่ละแนวโน้มของเทคโนโลยียุคใหม่ เช่น คลาวด์, ระบบอัตโนมัติ และการทำงานทางไกล ต่างสร้างข้อกำหนดใหม่ๆ ให้กับโครงสร้างพื้นฐานของเครือข่าย
หมดยุคที่เครือข่ายถูกมองว่าเป็นเพียง “กลุ่มของท่อส่งข้อมูล” ที่ให้การเชื่อมต่อระหว่างไซต์เท่านั้น องค์กรต่างๆ ตระหนักแล้วว่าเครือข่ายคือองค์ประกอบของโครงสร้างพื้นฐานที่เป็นหัวใจสำคัญต่อกลยุทธ์การเติบโตและความปลอดภัยโดยรวม และช่วยเพิ่มผลลัพธ์ทางธุรกิจ