×
ข้ามไปยังเนื้อหาหลัก

App Connector ของ ZTNA: หลักการทำงาน ข้อกำหนดเครื่อง และการวางแผน High Availability

ปรับปรุงเมื่อ

App Connector คือส่วนประกอบของ Zero Trust Security (ZTNA) ใน Sangfor Athena SASE ที่ติดตั้งไว้ใน Data Center หรือ Cloud ขององค์กร ทำหน้าที่เชื่อม PoP ของ Athena SASE เข้ากับ Server ภายใน และส่งต่อ Traffic ของผู้ใช้ไปยัง App ที่ Publish ไว้ บทความนี้สำหรับผู้ดูแลระบบที่กำลังวางแผนติดตั้ง App Connector ครั้งแรก อธิบายหลักการทำงาน ข้อกำหนดของเครื่อง เงื่อนไขด้าน Network และทางเลือก High Availability ก่อนลงมือติดตั้งตามบทความ Linux หรือ Windows (ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร)

App Connector ทำงานอย่างไร

หน้า Core Features › Zero Trust Security › Policies › Connectors แสดงเส้นทางของข้อมูลไว้ด้านบน: เครื่องผู้ใช้ (PC) → PoP → Zero Trust Policy Check (ตรวจสิทธิ์และความปลอดภัย) → App Connector → Server ภายใน ลำดับการทำงานโดยสรุปคือ

  1. Omnipoint Secure Client บนเครื่องผู้ใช้เชื่อมต่อกับ Athena SASE และผู้ใช้ทำ Authentication
  2. Platform แจ้ง Connector ว่าผู้ใช้เชื่อมต่ออยู่ที่ PoP ใด
  3. Connector สร้าง SSL Tunnel ออกไปหา PoP นั้น
  4. Traffic ของผู้ใช้วิ่งจาก Client ไปที่ PoP ซึ่งตรวจ Zero Trust Policy ก่อน แล้วส่งต่อไปที่ Connector
  5. Connector ทำหน้าที่ Proxy ส่ง Request ต่อไปยัง App ภายใน

Config และ Log วิ่งไปที่ Management Platform ส่วน Traffic ของผู้ใช้วิ่งผ่าน PoP เนื่องจาก Connector เป็นฝ่ายเชื่อมออกไปหา Cloud เอง Server ภายในจึงไม่ต้องมี Public IP และไม่ต้องเปิด Inbound Port ให้ภายนอก

หน้า Connectors แสดงแผนภาพเส้นทาง PC ไป PoP ไป Zero Trust Policy Check ไป App Connector และขั้นตอนเริ่มต้นสามข้อ

สิ่งที่ควรรู้

  • Server ปลายทางจะเห็น Request มาจาก IP ของเครื่อง Connector หาก Server หรือ Firewall ภายในจำกัด Source IP ให้อนุญาต IP ของเครื่อง Connector
  • App Connector กับ Identity Connector เป็นคนละ Package และสร้างจากคนละหน้า App Connector สร้างที่ Zero Trust Security › Policies › Connectors ส่วน Identity Connector (ใช้เชื่อม AD/LDAP ภายในองค์กร) สร้างที่ Identity Management

ข้อกำหนดของเครื่อง Connector

OS เวอร์ชัน CPU / RAM / Disk
Linux (Console ติดป้าย Recommended) CentOS 7.9 ขึ้นไป, Ubuntu 16 ขึ้นไป 4 Core / 8 GB ขึ้นไป / 256 GB ขึ้นไป
Windows Windows 7 ขึ้นไป และ Windows Server 2008 R2 ขึ้นไป 4 Core / 8 GB ขึ้นไป / 256 GB ขึ้นไป
  • ใช้เครื่องเฉพาะทาง หน้า Install ระบุให้ติดตั้งบนระบบที่สะอาด (pure system environment) เพื่อหลีกเลี่ยงผลกระทบจาก Network Policy ของ OS หรือโปรแกรมอื่นบนเครื่อง ติดตั้งร่วมกับ Identity Connector บนเครื่องเดียวกันได้ แต่ไม่ควรติดตั้งบน Server ที่เป็นตัว App
  • DNS ของเครื่อง ต้องชี้ไปที่ DNS Server ภายใน เพราะ App ที่ Publish ด้วยชื่อโดเมนอาศัยการ Resolve ของ Connector
  • ห้ามเปลี่ยนชื่อไฟล์ Package ที่ดาวน์โหลดจาก Console
  • ขนาดเครื่อง เริ่มจากสเปกขั้นต่ำข้างต้น แล้วติดตามคอลัมน์ CPU, Memory และ Bandwidth ของแต่ละ Instance ในหน้า Connectors สำหรับงานขนาดใหญ่แนะนำให้ใช้ Linux และเพิ่ม Instance หรือเพิ่มทรัพยากรของเครื่องตามแนวทางใน แนวทางวางแผนและ Deploy Sangfor Athena SASE ในองค์กร

เงื่อนไขด้าน Network

  • ขาออกไปยัง Athena SASE และ PoP: รายการ Address ที่ต้องอนุญาตอยู่ที่ Platform Management › System › General Settings › Service Address List (หรือลิงก์ Service Address List บนหน้า Connectors) หากไม่มี Firewall ที่คุมขาออก การ์ด Communication Normal ระบุว่าไม่ต้องทำอะไรเพิ่ม หากมี Firewall หรือ Proxy ที่คุมขาออก ให้กด View Addresses (ระบบให้ยืนยันตัวตนด้วยรหัส SMS) แล้วอนุญาตรายการทั้งหมดบนอุปกรณ์นั้น รายการนี้แตกต่างกันในแต่ละองค์กร จึงต้องใช้ข้อมูลจาก Console ขององค์กรเอง
  • ภายในองค์กร: เครื่อง Connector ต้องเข้าถึง IP และ Port ของทุก App ที่จะ Publish และเข้าถึง DNS Server ภายในได้
  • ขาเข้า: ไม่ต้องเปิด Inbound Port หรือ NAT จากอินเทอร์เน็ตมาที่ Connector

ทางเลือก High Availability

สำหรับ Production แนะนำให้มีเครื่อง Connector อย่างน้อย 2 เครื่อง เพื่อไม่ให้เป็น Single Point of Failure ใช้เครื่องเดียวได้เมื่อทรัพยากรจำกัดหรือไม่ต้องการ High Availability Athena SASE มีทางเลือก 2 แบบ

หัวข้อ Active-Active (หลาย Instance ใน Connector เดียว) Active-Standby (Connector Group)
วิธีทำ นำ Package เดิมของ Connector ไปติดตั้งบนเครื่องที่สอง ระบบรวมเป็น Cluster ให้อัตโนมัติ แต่ละเครื่องคือ Instance หนึ่งของ Connector สร้าง Connector หลายตัว (เช่นตัวละ Data Center) แล้วรวมเป็น Connector Group โดยกำหนด Priority
การทำงาน ทุก Instance ทำงานพร้อมกัน ระบบ Load Balance การเชื่อมต่อไปยังแต่ละ Instance โดยอัตโนมัติ เมื่อ Instance หนึ่งหยุด Instance ที่เหลือรับงานต่อ Connector ที่ Priority สูงสุดทำงาน ตัวถัดไปรอรับงานเมื่อตัวหลักใช้งานไม่ได้ และเมื่อตัวหลักกลับมา ระบบกลับไปใช้ตัวหลักตามเดิม
เหมาะกับ หลายเครื่องใน Data Center เดียวกัน (ไม่จำเป็นต้องอยู่ Subnet เดียวกัน ขอเพียงแต่ละเครื่องออกไปหา PoP และเข้าถึง App ได้) App เดียวกันที่เข้าถึงได้จากหลาย Data Center
จำนวนสูงสุด 16 Instance ต่อ Connector และรวมทุก Connector ได้ 128 Instance 8 Connector ต่อ Group (ตามตัวนับบนหน้าจอ) และ 128 Group

หน้า Install ของ Connector ก็แนะนำแบบแรกไว้ในหัวข้อ High Availability Deployment [Recommended] คือให้ติดตั้ง Connector บนเครื่องอีกเครื่องด้วยขั้นตอนเดียวกัน เพื่อให้ทำงานแบบ Active-Active

หน้าต่าง Install ของ Connector แสดงคำสั่งติดตั้ง Connector Status และคำแนะนำ High Availability Deployment

เมื่อติดตั้ง Package เดียวกันบนเครื่องที่สองแล้ว Connector ตัวเดิมจะมี Instance เพิ่มเป็น 2 แถว ทั้งสองแถวควรเป็น Up และใช้ DNS ภายในเดียวกัน

Connector หนึ่งตัวที่มี 2 Instance สถานะ Up ทั้งคู่และใช้ DNS ภายในเดียวกัน

แท็บ Connector Groups อธิบายแบบที่สองด้วยแผนภาพ Normal Scenario และ Abnormal Scenario: ปกติ Connector ตัวแรก (Active) ทำงาน เมื่อตัวแรกใช้งานไม่ได้ ตัวที่สอง (Standby) รับงานแทน

แท็บ Connector Groups แสดงแผนภาพ Active และ Standby ในสถานการณ์ปกติและสถานการณ์ผิดปกติ

App หนึ่งตัวผูกกับ Connector หนึ่งตัว หรือ Connector Group หนึ่งกลุ่ม (ช่อง Connection Method ของ App) High Availability ของ App จึงมาจากจำนวน Instance ของ Connector ที่ใช้ หรือจาก Group ที่จัดลำดับ Priority ไว้

ลำดับการติดตั้งและตั้งค่า

ก่อนเริ่ม ให้มี Subscription ของ ZTNA, ผู้ใช้และการ Authentication พร้อมใช้งาน และติดตั้ง Omnipoint Secure Client บนเครื่องผู้ใช้แล้ว จากนั้นทำตามลำดับนี้ (Widget ของ ZTNA ที่หน้า Home ก็แนะนำลำดับเดียวกันนี้ขณะที่ยังไม่ได้ตั้งค่า)

  1. เตรียมข้อมูล App ที่จะ Publish ให้ครบ: ชื่อ, Protocol, IP หรือชื่อโดเมน, Port และผู้ใช้หรือ User Group ที่ต้องเข้าถึง
  2. เตรียมเครื่อง Connector และอนุญาต Service Address List บน Firewall ขาออก
  3. สร้างและติดตั้ง App Connector: บน Linux หรือ บน Windows
  4. ทำ High Availability: ติดตั้ง Instance ที่สอง หรือสร้าง Connector Group
  5. Publish App ภายใน แล้วให้สิทธิ์ผู้ใช้ด้วย App Authorization
  6. ตั้งค่า DNS ภายใน และ Security Policy ตามความต้องการ

การติดตามสถานะ Connector

  • Dashboard › Home Widget Zero Trust Network Access แสดงจำนวน App, Connector และ Connector Group รวมถึงรายการที่ Down เหมาะสำหรับตรวจเป็นประจำ
  • หน้า Connectors แต่ละการ์ดแสดง Status (Up / Down), จำนวน Instance และ App ที่ผูกอยู่ ขยายการ์ดเพื่อดู Instance ทีละแถว พร้อม Operating System, DNS, Software Version, Deployment Mode, Last Heartbeat, Bandwidth, CPU และ Memory คำอธิบายบนหน้าเดียวกันระบุสถานะของ Instance คือ Connected (การเชื่อมต่อและ Tunnel ปกติ) และ Abnormal Tunnel (เชื่อมต่อได้แต่ Tunnel ผิดปกติ)
  • การแจ้งเตือน ตั้งได้ที่ Platform Management › System › Alert and Monitor › Alert Settings ซึ่งมีเงื่อนไขด้าน O&M เกี่ยวกับ Connector เช่น การเชื่อมต่อระหว่าง Connector กับ PoP, Packet Loss/Latency, CPU, Memory และ Internal App Connectivity Error โดยแจ้งทาง Email
  • เมื่อ Connector ไม่ขึ้น Up ให้เปิดลิงก์ More About Troubleshooting บนหน้า Connectors และทดสอบจากตัว Connector ด้วย http://localhost:18888/get_detect_network ตามรายละเอียดในบทความการติดตั้ง

บทความที่เกี่ยวข้อง

ข้อคิดเห็น

0 ข้อคิดเห็น

โปรด ลงชื่อเข้าใช้ เพื่อแสดงข้อคิดเห็น