แก้ปัญหา ZTNA ที่พบบ่อย: Connector Down, App Down และผู้ใช้เข้า App ไม่ได้

บทความนี้รวมอาการที่พบบ่อยของ ZTNA (การเข้า App ภายในผ่าน App Connector) พร้อมวิธีไล่ตามลำดับ อาการ → จุดที่ดู → สาเหตุ → วิธีแก้ → ตรวจซ้ำ สำหรับผู้ดูแลระบบที่ดูแล Athena SASE ประจำวัน ก่อนอ่านบทความนี้ แนะนำให้อ่านภาพรวมวิธีไล่ปัญหาใน วิธีไล่ปัญหา Athena SASE อย่างเป็นขั้นตอน

แยกให้ได้ก่อนว่าเป็นที่ App หรือที่ผู้ใช้

ก่อนทดสอบจากฝั่ง Connector ให้รัน Diagnostics ที่เครื่องผู้ใช้ก่อนทุกครั้ง เพื่อตัดเรื่อง Network หรือ Software บนเครื่องผู้ใช้ออก

Connector ที่เพิ่งติดตั้งยังเป็น Down

อาการ ที่ Core Features › Zero Trust Security › Policies › Connectors แท็บ Connector Apps การ์ดของ Connector แสดงสถานะ Down และช่อง Instances เป็น Pending Installation เมื่อวางเมาส์ที่สถานะจะเห็นข้อความ "No connector instances available or all connections are down."

สาเหตุที่พบบ่อย ยังไม่ได้ติดตั้ง Package บนเครื่อง หรือเครื่อง Connector ติดต่อ Platform และ PoP ขาออกไม่ได้

วิธีแก้และตรวจ

1. ติดตั้งตามขั้นตอนในหน้า Install ของ Connector นั้น (บน Linux: แตกไฟล์ Package โดยไม่เปลี่ยนชื่อไฟล์ เข้าโฟลเดอร์ target แล้วรัน sudo ./install.sh) จากนั้นตรวจว่า Service ทำงานด้วย

   systemctl status connector

   ผลต้องเป็น active (running)

2. ถ้า Service ทำงานแต่การ์ดยัง Down ให้ตรวจการเชื่อมต่อขาออกด้วยคำสั่งบนเครื่อง Connector (บน Windows เปิด URL เดียวกันใน Browser)

   curl http://localhost:18888/get_detect_network

   ผลแต่ละหัวข้อเป็น √ หรือ X ได้แก่ Detect Gateway Connection, Detect DNS, Detect Internet Connection, Connector Login Platform Request (การติดต่อ Platform) และ Connector Access POP Request (การเชื่อม Tunnel ไปที่ PoP)

   

3. ถ้าหัวข้อใดเป็น X ผลจะระบุ IP และ Port ปลายทางที่ต่อไม่ได้ ให้เปิดปลายทางนั้นที่ Firewall ขาออกขององค์กร โดยอ้างอิงรายการปลายทางทั้งหมดจาก System › General Settings › Service Address List ซึ่งแตกต่างกันในแต่ละองค์กร ให้เปิดดูจาก Console ของตนเองเสมอ

4. รันคำสั่งเดียวกันซ้ำจนทุกหัวข้อเป็น √ แล้วกดไอคอน Refresh ที่รายการใน Console สถานะต้องเปลี่ยนเป็น Up

5. เปิดดูแถว Instance ของ Connector ช่อง DNS ต้องเป็น DNS Server ภายในขององค์กร เพราะ Connector ใช้ DNS นี้ Resolve ชื่อ Server ให้ผู้ใช้ ถ้าเครื่อง Ubuntu แสดง 127.0.0.53 ให้ชี้ /etc/resolv.conf ไปที่ไฟล์ของ systemd-resolved แล้ว Restart Connector

   sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
   sudo systemctl restart connector

   

ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร

Connector ที่เคย Up กลายเป็น Down

อาการ ที่ Dashboard › Home Widget Zero Trust Network Access แสดงจำนวน Down ของ Connectors มากกว่า 0 เมื่อคลิกชื่อ Connector จะไปที่หน้า Connectors และปุ่ม Details แสดง Instances เป็น 0 ถ้า Connector นั้นอยู่ใน Connector Group แท็บ Connector Groups จะแสดงสถานะกลุ่มเป็น Partially Up (บาง Connector ยัง Up)

จุดที่ดูใน Console ที่ Logs › System Logs › Platform & System กรอง Log Source เป็น Zero Trust Network Access จะเห็นแถว Warn ที่ระบุชื่อ Connector เช่น Connector ติดต่อ Console กลางไม่ได้ และแถว Info เมื่อกลับมาปกติ

วิธีแก้และตรวจ

1. ที่เครื่อง Connector รัน systemctl status connector ถ้าผลเป็น inactive (dead) แปลว่า Service หยุดทำงาน ให้เริ่ม Service แล้วตรวจซ้ำ

   sudo systemctl start connector
   systemctl status connector

2. ถ้า Service ทำงานอยู่ ให้ตรวจว่าเครื่องยังออกอินเทอร์เน็ตและ Resolve DNS ได้ แล้วรัน get_detect_network ตามหัวข้อก่อนหน้า

3. กด Refresh ในหน้า Connectors สถานะต้องกลับเป็น Up และกลุ่มใน Connector Groups กลับเป็น Up

4. ถ้าต้องการดู Latency ระหว่าง Connector กับ PoP ใช้คำสั่ง get_line_info โดย Token คือ 6 ตัวอักษรท้ายของไฟล์ authcode

   curl http://localhost:18888/get_line_info?token=$(tail -c 6 /opt/sangfor/spa-connector/connector/conf/authcode)

   บน Windows เปิดไฟล์ C:\Program Files (x86)\connector\conf\authcode คัดลอก 6 ตัวอักษรท้าย แล้วเปิด http://localhost:18888/get_line_info?token=xxxxxx ใน Browser ผลแสดง popid (PoP ที่ใช้อยู่) now line (Path ที่ใช้อยู่) และทุก Path ที่ใช้ได้ซึ่งขึ้นต้นด้วย ip พร้อมค่า networkUnreachable ถ้าเป็น true ทุก Path ระบบจะแจ้งว่า Connector ผิดปกติ (connector exception) ซึ่งเป็นคนละสถานะกับ Offline

App ขึ้น Down หรือ Unhealthy

อาการ ผู้ใช้เปิด App ผ่าน Workspace แล้ว Browser แจ้งว่าเว็บไม่ส่งข้อมูลกลับมา (เช่น ERR_EMPTY_RESPONSE)

จุดที่ดู

• Core Features › Zero Trust Security › Policies › Apps แท็บ App List ตัวนับด้านบนแยกสถานะ Normal · Unhealthy · Down · Probing · Unknown และเปิดคอลัมน์ App Health Status ได้จากตัวเลือกคอลัมน์ (⋯) ที่หัวตาราง
• ถ้า Connector ที่ App ใช้ยังเป็น Up และ App อื่นบน Server เดียวกันยังเป็น Normal แปลว่าการเชื่อมต่อผ่าน Connector ปกติ สาเหตุอยู่ที่บริการของ App บน Server ปลายทาง
• ที่ Platform & System (Log Source = Zero Trust Network Access) จะมีแถว Warn ที่ระบุว่าการสื่อสารระหว่าง Connector กับที่อยู่ของ App ผิดปกติ และแถว Info เมื่อกลับมา

วิธีแก้ ตรวจและเริ่มบริการของ App บน Server ปลายทาง ถ้ายังไม่แน่ใจ ให้ทดสอบจากเครื่อง Connector ไปที่ IP และ Port ของ App โดยตรง (เช่นด้วย ping, curl หรือ nc) ถ้าเครื่อง Connector เข้าไม่ได้ ให้แก้ที่ Server หรือ Network ภายในก่อน

ตรวจซ้ำ กด Refresh ที่ App List สถานะต้องกลับเป็น Normal แล้วให้ผู้ใช้โหลดหน้า App ใหม่

ผู้ใช้ไม่เห็นไอคอน App และเชื่อมต่อไม่ได้

อาการ ใน Workspace ของผู้ใช้ไม่มีไอคอนของ App นั้น และเมื่อผู้ใช้เปิดโปรแกรมเชื่อมต่อเอง เช่น Remote Desktop ไปที่ IP ของ Server จะได้ข้อความทั่วไปของโปรแกรมว่าเชื่อมต่อไม่ได้ โดยไม่มีหน้าขอรหัสผ่าน

สาเหตุ ผู้ใช้ไม่มีสิทธิ์ใน App นั้น (เรื่องสิทธิ์ ไม่ใช่เรื่อง Network) และจะไม่มีรายการเข้าถึง App นั้นของผู้ใช้ใน ZTNA Logs แท็บ Access Logs

วิธีแก้

1. ไปที่ Core Features › Zero Trust Security › Policies › Apps › App Authorization เลือก App ที่ต้องการทางซ้าย แล้วดูรายการที่ได้สิทธิ์ (User, Department หรือ User Group)

2. ถ้าผู้ใช้จำเป็นต้องใช้ กด Permissions แล้วเลือกผู้ใช้ Department หรือ User Group ในหน้าต่าง Authorize แล้วกด OK หรือเปิดให้ผู้ใช้ส่ง App Access Request และอนุมัติที่ App Approval

3. ถ้าให้สิทธิ์ผ่าน AD Group ให้ย้ายผู้ใช้เข้ากลุ่มใน AD สิทธิ์จะตามมาหลัง User Source Sync ครั้งถัดไป

ตรวจซ้ำ ให้ผู้ใช้กด Refresh ใน Workspace โดยไม่ต้อง Login ใหม่ ไอคอน App จะปรากฏ เมื่อเชื่อมต่ออีกครั้งควรได้หน้าขอบัญชีของ Server ปลายทาง

ถ้าผู้ใช้มีสิทธิ์แล้วแต่ยังเข้าไม่ได้ ให้ดู ZTNA Logs แท็บ Access Logs รายการที่ไม่สำเร็จจะมีรหัสต่อท้าย เช่น exit with:500 ซึ่งหมายถึงการสื่อสารกับบริการไม่สำเร็จ อาจเกิดจาก Policy ปฏิเสธการเข้าถึงหรือ Server ตอบไม่ได้

ผู้ใช้เห็นไอคอนแต่ถูก Block พร้อมข้อความแจ้งเหตุผล

อาการ ผู้ใช้มีสิทธิ์และเห็นไอคอน แต่เปิด App แล้วหน้าเว็บไม่ขึ้น และ Client แสดงข้อความระบุรหัส Policy (เช่น P000001) ชื่อ App และที่อยู่ที่ถูกจำกัด

จุดที่ดู ZTNA Logs แท็บ User Logs จะมีรายการ "Application access blocking by ACL" และ "Application authentication" ที่ไม่สำเร็จพร้อมรหัส Policy เดียวกัน (acl check not passed)

สาเหตุ เครื่องของผู้ใช้ไม่ผ่านเงื่อนไขของ App Protection Policy เช่น Policy กำหนดให้ต้องเปิด Windows Firewall

วิธีแก้ ใช้รหัส Policy หา Policy ที่ Zero Trust Security › Policies › Security Policies › App Protection Policies แล้วแก้ที่เครื่องผู้ใช้ให้ผ่านเงื่อนไข หรือปรับ Policy ให้ตรงกับความต้องการ Policy ประเภทนี้มีผลเมื่อผู้ใช้ Login ครั้งถัดไป หลังสร้างหรือแก้ Policy จึงให้ผู้ใช้ Logout แล้ว Login ใหม่

ตรวจซ้ำ เมื่อเครื่องผ่านเงื่อนไข ผู้ใช้เปิด App ได้ตามปกติ และ User Logs บันทึกว่าการตรวจผ่าน

เรียก App ด้วย IP ได้ แต่ด้วยชื่อไม่ได้

ตรวจที่ Zero Trust Security › Policies › Advanced Settings › User Policies ดังนี้

• ผู้ใช้อยู่ใน Objects ของ User Policy ที่ใช้งาน (User Policy ของผู้ใช้มีผลก่อน Policy ของ OU ระดับบน และ Default policy)
• แท็บ Access Settings เปิด Internal DNS Resolution และมีกฎของโดเมนนั้น โดยเลือก Connector ที่ถูกต้อง ระบบจะแสดง DNS Server ของ Connector ที่เลือก
• ถ้าผู้ใช้พิมพ์ชื่อสั้น ให้เปิด Append DNS suffix และกรอกโดเมนขององค์กร
• มี App ที่ครอบคลุม IP ปลายทางหลังการ Resolve และ App นั้นใช้ Connector ที่เข้าถึง Server ได้
• ช่อง DNS ของ Instance ของ Connector เป็น DNS ภายใน (ดูหัวข้อ Connector ด้านบน)

รายละเอียดการตั้งค่าดูได้ที่ การ Resolve ชื่อภายในสำหรับ App ของ ZTNA

ผู้ใช้ Login ไม่สำเร็จ

ถ้า AD ใช้ Windows Server ที่บังคับการเชื่อมต่อแบบเข้ารหัส ให้ตั้ง Encryption Method ของ Auth Source และ User Source เป็น SSL (LDAPS Port 636) และ Domain Controller ต้องมี Certificate สำหรับ LDAPS

ถ้าต้องการรู้ทันทีเมื่อมีปัญหา ให้เปิด Trigger Login Error, Auth Connector Error และ Department Sync Error ใน Alert Settings

ผู้ใช้แจ้งว่าเข้า App ได้แต่ใช้เวลาตอบสนองนาน

วัดทีละช่วง แล้วแก้ที่ช่วงที่ใช้เวลานาน

• แถว Instance ของ Connector แสดง Bandwidth, CPU และ Memory ถ้าใช้เต็มกำลัง ให้เพิ่ม Instance หรือเพิ่มขนาดเครื่อง
• สำหรับผู้ใช้บน Network คุณภาพต่ำ ดูหัวข้อ Poor Network Acceleration ที่ Zero Trust Security › Policies › Advanced Settings › Global Policies (Enable bandwidth optimization และ Reduce network latency) การตั้งค่านี้มีผลกับทั้งองค์กร
• Alert Settings มี Trigger Connector Packet Loss/Latency Error, Insufficient Connector CPU Resources และ Insufficient Connector Memory Resources สำหรับเฝ้าดูล่วงหน้า

ถ้าตรวจครบแล้วยังไม่พบสาเหตุ ให้เก็บผลคำสั่งของ Connector และ Log จาก http://localhost:18888/diag พร้อม Log ของเครื่องผู้ใช้ แล้วส่งต่อให้ทีม Support ของ Sangfor ตาม การเก็บ Log สำหรับแก้ปัญหา