Always On VPN ไม่ใช่การเข้าถึง LAN: รายการตรวจสอบทรัพยากร

Always On คือวงจรชีวิตของการเชื่อมต่อ โปรไฟล์จะเชื่อมต่อตอนลงชื่อเข้าใช้หรือก่อนหน้านั้น และเชื่อมต่อใหม่โดยที่ผู้ใช้ไม่ต้องกดอะไร นั่นไม่ได้หมายความว่าปลายทางส่วนตัวทุกแห่ง โปรโตคอลและผู้ใช้ทุกคนได้รับอนุญาต คำถามที่ใช้ได้จริงคือโปรไฟล์ที่ติดตั้งไว้ส่งมอบทรัพยากรใดจริง ๆ และคำตอบนั้นต้องตรวจทีละทรัพยากร ไม่ใช่ดูที่ป้าย Connected

ขั้นตอนที่ 1: เขียนทรัพยากรลงไปก่อนทดสอบ

เริ่มด้วยบันทึกสั้น ๆ หนึ่งรายการต่อแอป โดยดึงค่าจากสภาพแวดล้อมจริง: ชื่อ คำนำหน้าปลายทาง บริการและพอร์ต บทบาทของอุโมงค์ กลุ่มตัวตน และเส้นทางของตัวแก้ไขชื่อ

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

บันทึกนี้บังคับให้ถามสี่คำถามแยกกัน เส้นทางกำหนดว่าแอดเดรสจะไปที่ใด นโยบาย DNS กำหนดว่าลูกค้าเรียนรู้แอดเดรสได้อย่างไร ตัวกรองทราฟฟิกกำหนดว่าทราฟฟิกนั้นใช้การเชื่อมต่อได้หรือไม่ ไฟร์วอลล์และสิทธิ์ของแอปปลายทางกำหนดว่าคำขอจะถูกยอมรับหรือไม่ ไม่มีข้อใดในสี่ข้อนี้ที่ได้มาจากอุโมงค์ที่เชื่อมต่อแล้ว

ขั้นตอนที่ 2: กำหนดว่าอุโมงค์ใดควรขนส่งมัน

Windows Always On VPN มีอุโมงค์อุปกรณ์และอุโมงค์ผู้ใช้ ซึ่งกำหนดเป็นโปรไฟล์แยกกันพร้อมใบรับรองและขอบเขตแยกกัน โดยทั่วไปอุโมงค์อุปกรณ์ขนส่งเฉพาะโครงสร้างพื้นฐานที่ต้องใช้ก่อนลงชื่อเข้าใช้ เช่น การจัดการและบริการโดเมน ส่วนการเข้าถึงแอปอย่างกว้างขวางของพนักงานเป็นของอุโมงค์ผู้ใช้

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

ขั้นตอนที่ 3: ตรวจสอบเส้นทางสำหรับแอดเดรสจริง

แก้ชื่อหนึ่งครั้ง แล้วตรวจเส้นทาง: Find-NetRoute -RemoteIPAddress 10.20.5.10 รายงานอินเทอร์เฟซที่เลือก ฮอปถัดไป และแอดเดรสต้นทาง หากอินเทอร์เฟซเป็นอะแดปเตอร์จริง แปลว่าคำนำหน้าไม่มีอยู่ในชุดเส้นทางของอุโมงค์ หรือลูกค้าได้ยกเว้นผ่านอุโมงค์แบบแยก เปรียบเทียบกับคำนิยามของโปรไฟล์แทนการเพิ่มเส้นทางภายในเครื่อง

คำสั่ง route add ภายในเครื่องอาจทำให้การทดสอบผ่านและหายไปเมื่อนโยบายรีเฟรชครั้งถัดไป การเปลี่ยนแปลงจึงต้องอยู่ในโปรไฟล์ที่จัดการ ตรวจคำนำหน้าในโปรไฟล์ผู้ใช้และอุปกรณ์ และตรวจการตั้งค่าอุโมงค์แบบแยก: อุโมงค์เต็มไม่ต้องมีเส้นทางต่อคำนำหน้า อุโมงค์แบบแยกต้องมีหนึ่งเส้นทางสำหรับทุกคำนำหน้าส่วนตัวที่ขนส่ง

ขั้นตอนที่ 4: ทดสอบการแก้ชื่อส่วนตัวแยกต่างหาก

ชื่อส่วนตัวมีเส้นทางนโยบายของตัวเอง โปรไฟล์สามารถส่งกฎ NRPT และรายการค้นหาคำต่อท้าย DNS ซึ่งใช้ได้ตราบที่อุโมงค์ยังทำงาน อ่านด้วย Get-DnsClientNrptPolicy ว่าลูกค้าได้รับอะไรจริง แล้วทดสอบชื่อและแอดเดรสในเซสชันเดียวกัน หากชื่อล้มเหลวแต่แอดเดรสทำงาน แสดงว่าปัญหาอยู่ที่ตัวแก้ไขชื่อ หากล้มทั้งสองอย่างแสดงว่าอยู่ที่เส้นทาง

ชื่ออาจแก้ไปยังแอดเดรสนอกเส้นทางของอุโมงค์ได้ ซึ่งทำให้ผลลัพธ์สำเร็จและหมดเวลาปะปนกัน เปรียบเทียบแอดเดรสที่ได้กลับมากับคำนำหน้าในบันทึกของคุณ หากต่างกัน แปลว่าโซนส่วนตัวตอบด้วยแอดเดรสสาธารณะหรือแอดเดรสทางเลือก และเส้นทางที่ตรงกันไม่ใช่เส้นทางที่ออกแบบไว้

ขั้นตอนที่ 5: ตรวจตัวกรอง ตัวตน และประตูของแอปเอง

ตัวกรองทราฟฟิกจำกัดว่าโปรโตคอลและพอร์ตใดใช้ทราฟฟิกของอุโมงค์อุปกรณ์ได้ และชุดที่แคบเกินอาจปิดกั้นทรัพยากรที่เส้นทางควรขนส่ง โปรไฟล์กำหนดการเชื่อมต่อให้กลุ่ม แต่ทรัพยากรมีการอนุญาตของตัวเอง ผู้ใช้ที่เชื่อมต่อได้ไม่ได้รับอนุญาตจากไฟล์เซิร์ฟเวอร์โดยอัตโนมัติ

แก้ไขโปรไฟล์ที่จัดการผ่านเจ้าของ ไม่ว่าจะเป็น Intune การปรับใช้ ProfileXML หรือสคริปต์ปฏิบัติการ แล้วทดสอบใหม่หลังเชื่อมต่อใหม่ตามปกติและหลังรีบูต เพราะความล้มเหลวที่พบบ่อยคือเส้นทางภายในเครื่องที่ค้างอยู่หรือโปรไฟล์ที่ใช้เพียงครั้งเดียว เก็บเวอร์ชันของโปรไฟล์ไว้ข้างผลการทดสอบ