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

การใช้ชื่อโดเมนภายในกับ ZTNA: fake IP, Internal DNS Resolution และ Append DNS suffix

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

ผู้ใช้มักเรียกระบบภายในด้วยชื่อ เช่น intranet.example.local แต่เครื่องที่อยู่นอกองค์กรใช้ Public DNS ซึ่งไม่รู้จักชื่อภายใน บทความนี้อธิบายวิธีทำให้ชื่อโดเมนภายในใช้งานได้ผ่าน Zero Trust Security (ZTNA) ของ Sangfor Athena SASE ทั้งการ Publish App ด้วยชื่อโดเมนพร้อม fake IP, การใช้ Internal DNS Resolution ใน User Policy, การใช้ชื่อสั้นด้วย Append DNS suffix รวมถึงวิธีทดสอบและแก้ปัญหา เหมาะสำหรับผู้ดูแลระบบที่ Publish App แล้ว ค่าในภาพเป็นค่าตัวอย่าง ให้เปลี่ยนเป็นค่าขององค์กร

วิธีทำให้ชื่อภายในใช้งานได้

วิธี การทำงาน เหมาะกับ
Publish App ด้วยชื่อโดเมน (Enable fake IP) Client ได้ IP เสมือนของชื่อนั้น Traffic เข้า Tunnel แล้ว Connector เป็นผู้ Resolve หา IP จริงและส่งต่อไปยัง Server ไม่ต้องการเปิดเผย IP จริง, หลายชื่อชี้ไปที่ IP เดียวกัน, Publish แบบ Wildcard หรือชื่อที่ Resolve เป็น IPv6
Publish App ด้วย IP + Internal DNS Resolution ใน User Policy DNS Query ของโดเมนที่กำหนดวิ่งผ่าน Connector ไปที่ DNS Server ภายใน Client ได้ IP จริง แล้ว Traffic จะ Match กับ App ที่ Publish ด้วย IP นั้น App ที่ Publish ด้วย IP หรือช่วง IP อยู่แล้ว และองค์กรที่มีชื่อภายในจำนวนมาก
Append DNS suffix (ใช้คู่กับวิธีที่สอง) ผู้ใช้พิมพ์ชื่อสั้นใน Browser ระบบต่อท้าย Suffix ให้เป็นชื่อเต็ม ผู้ใช้ที่คุ้นกับการพิมพ์ชื่อสั้นจากเครื่องที่ Join Domain

Resolve ชื่อได้ ไม่ได้แปลว่ามีสิทธิ์: DNS บอกเพียงปลายทาง ผู้ใช้ยังเข้าได้เฉพาะ IP และ Port ที่ Publish เป็น App และได้รับสิทธิ์เท่านั้น เช่น ชื่อของ File Server Resolve ได้ แต่ถ้าไม่ได้ Publish Port 445 ผู้ใช้ก็เปิด File Share ไม่ได้

ขั้นแรก: Connector ต้อง Resolve ชื่อภายในได้

ทุกวิธีอาศัยการ Resolve ของ App Connector จึงควรตรวจก่อนใช้ชื่อกับ App ทุกครั้ง

  • ที่ Core Features › Zero Trust Security › Policies › Connectors ขยายการ์ดของ Connector คอลัมน์ DNS ของแต่ละ Instance ต้องเป็น DNS Server ภายใน (เช่น Domain Controller)
  • บนเครื่อง Linux ไฟล์ /etc/resolv.conf ต้องมี nameserver เป็น DNS ภายใน (บน Ubuntu ให้ชี้ไปที่ /run/systemd/resolve/resolv.conf แทน 127.0.0.53 แล้ว Restart Service ของ Connector ดูรายละเอียดในการติดตั้งบน Linux)
  • ทดสอบจากเครื่อง Connector เช่น resolvectl query <ชื่อภายใน> ต้องได้ IP จริงของ Server
ไฟล์ resolv.conf บนเครื่อง Connector มี nameserver เป็น DNS ภายในและ search domain

App ที่ Publish ด้วยชื่อโดเมน (fake IP)

  1. ในหน้า Add Internal App กรอก Server Address เป็นชื่อโดเมนในแถว TCP เช่น wiki.example.local หรือ Wildcard *.example.local (ชื่อโดเมนใช้ได้ในแถว TCP)

  2. ที่แท็บ Proxy Settings ระบบติ๊ก Enable fake IP ไว้ให้อัตโนมัติสำหรับ App ที่ใช้ชื่อโดเมน และคงค่านี้ไว้ หมายเหตุบนฟอร์มอธิบายว่า เมื่อเลือก fake IP ระบบส่ง IP เสมือนให้ Client ส่วนเมื่อไม่ได้เลือก ระบบจะหา IP จริงของชื่อนั้นจาก HOSTS (ก่อน) และ DNS ทุก 30 นาที แล้วส่ง IP จริงให้ Client

    แท็บ Proxy Settings ของ App ที่ใช้ชื่อโดเมน Enable fake IP ติ๊กไว้และหมายเหตุของ Tunnel Domain Resolution

  3. เมื่อผู้ใช้ที่ได้รับสิทธิ์ Login แล้ว เรียกชื่อนั้นจะได้ IP เสมือน (ไม่ใช่ IP จริงของ Server) และเปิด App ได้ผ่าน Port ที่ Publish ไว้

    คำสั่ง ping ชื่อ App ที่ Publish ด้วยชื่อโดเมน ได้ IP เสมือนแทน IP จริง

คำสั่ง ping ใช้ดูว่า Client ได้ IP ใด ส่วนการใช้งานจริงวิ่งผ่าน Protocol และ Port ที่ Publish ไว้ใน App หาก App มีทั้งชื่อเต็มและ Wildcard ระบบจะ Match ชื่อเต็มก่อน

App ที่ Publish ด้วย IP + Internal DNS Resolution

  1. Publish App ด้วย IP หรือช่วง IP ตามปกติ (เช่น TCP 192.168.1.12 Port 80)

  2. ไปที่ Core Features › Zero Trust Security › Policies › Advanced Settings แท็บ User Policies แล้ว Add หรือ Edit Policy ของผู้ใช้กลุ่มนั้น (เลือก Department ที่ผู้ใช้สังกัดโดยตรง หรือผู้ใช้รายคน) ดูลำดับการมีผลของ User Policy ในบทความ Advanced Settings

  3. ที่แท็บ Access Settings เปิด Internal DNS Resolution หลังผู้ใช้ Login Client จะใช้ DNS Server ภายในที่กำหนดก่อน และเมื่อไม่ได้ Login หรือออฟไลน์ เครื่องจะกลับไปใช้ DNS เดิมของตัวเอง

  4. ในแถวกฎ กรอก Domain Name ได้หลายบรรทัด (บรรทัดละหนึ่งชื่อ) และใช้ Wildcard ได้ เช่น *.example.local (Tooltip อธิบายว่า *.* คือทุกโดเมน และ *.com คือทุกชื่อที่ลงท้ายด้วย .com) กฎแต่ละข้อมีลำดับ Priority ปุ่ม Add rule แสดงจำนวนกฎที่เพิ่มได้อีก

  5. ที่ Connectors เลือก Connector หรือ Connector Group แล้วกด Select เลือกตัวที่เข้าถึง DNS ภายในได้ กล่องข้างกันแสดง DNS Server ที่ Connector นั้นใช้ (หากต้องเปลี่ยน ให้แก้ DNS บนเครื่อง Connector) หากแถวกฎมีช่อง PoP Gateway Area ให้เลือก Region ที่ต้องการก่อน

  6. ชื่อที่ต้องการให้ใช้ DNS เดิมของเครื่องต่อไป ให้ติ๊ก Excluded Domain Name แล้วกรอกไว้

  7. กด Save แล้วให้ผู้ใช้ Log out และ Login ใหม่ เพราะ User Policy มีผลใน Login ครั้งถัดไป

    User Policy แท็บ Access Settings เปิด Internal DNS Resolution กฎ Domain Name แบบ Wildcard เลือก Connector และ Append DNS suffix

เมื่อเปิด Internal DNS Resolution ระบบสร้าง App ของ DNS ให้เองโดยอัตโนมัติ App นี้ไม่แสดงใน App List แต่ใน Logs › Critical Feature Logs › ZTNA Logs แท็บ Access Logs จะเห็นแถวชื่อ Internal DNS Server (Generated Based on User Policies) ที่ Address 169.254.0.255 ซึ่งคือ DNS Query ที่วิ่งผ่าน Connector ตาม User Policy

หากตั้ง Wildcard เดียวกันทั้งใน App (ชื่อโดเมน) และใน User Policy ค่าใน App จะถูกใช้ก่อน ควรเลือกใช้วิธีใดวิธีหนึ่งสำหรับแต่ละโดเมน

ชื่อสั้นด้วย Append DNS suffix

ชื่อสั้น เช่น intranet คือชื่อแบบ NetBIOS ซึ่งเครื่องที่ Join Domain ต่อ Suffix ให้เองอยู่แล้ว สำหรับผู้ใช้นอกองค์กร ให้เปิด Append DNS suffix ในแท็บ Access Settings เดียวกัน แล้วกรอก Domain Name Suffix (เช่น example.local) เมื่อผู้ใช้พิมพ์ชื่อสั้นใน Browser ระบบจะต่อท้ายให้เป็นชื่อเต็ม ใช้ได้หลังผู้ใช้ Login Client บน Windows และ macOS แนะนำให้ใช้คู่กับ Internal DNS Resolution

ทดสอบและตรวจผล

  1. ก่อน Login Client ชื่อภายในจะ Resolve ไม่ได้จากเครื่องนอกองค์กร

  2. หลังผู้ใช้ Login (และได้รับสิทธิ์ App) เปิดชื่อเต็มใน Browser หน้าเว็บควรเปิดได้ หากพิมพ์ชื่อสั้นก็ควรเปิดได้เช่นกันเมื่อเปิด Append DNS suffix

    Browser เปิดเว็บภายในด้วยชื่อโดเมนได้ หน้าเว็บแสดงว่าคำขอมาจาก IP ของ Connector

  3. ดูแถวของ DNS และการเข้าถึง App ที่ ZTNA Logs แท็บ Access Logs

แก้ปัญหาที่พบบ่อย

อาการ สิ่งที่ควรตรวจ
ชื่อภายใน Resolve ไม่ได้ที่เครื่องผู้ใช้ ผู้ใช้ Login Client อยู่หรือไม่, ผู้ใช้อยู่ใน Objects ของ User Policy ที่ตั้ง Internal DNS Resolution หรือไม่ (Policy ระดับผู้ใช้มีผลก่อนระดับ Department), Domain Name ในกฎครอบคลุมชื่อนั้นหรือไม่ และให้ผู้ใช้ Log out/Login ใหม่หลังแก้ Policy
App ที่ใช้ชื่อโดเมนเปิดไม่ได้ คอลัมน์ DNS ของ Connector เป็น DNS ภายในหรือไม่, Connector Resolve ชื่อนั้นได้หรือไม่, App Health Status เป็น Normal หรือไม่
Resolve ได้ แต่เปิดไม่ได้ (รอจนหมดเวลา) IP และ Port นั้นถูก Publish เป็น App แล้วหรือไม่ และผู้ใช้ได้รับสิทธิ์ App นั้นใน App Authorization หรือไม่
ชื่อสั้นใช้ไม่ได้ เปิด Append DNS suffix และกรอก Suffix ถูกต้องหรือไม่ และเครื่องผู้ใช้เป็น Windows หรือ macOS ที่ Login Client แล้ว

ข้อคิดเห็น

0 ข้อคิดเห็น

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