การยืนยันตัวตนไคลเอนต์ Azure P2S: Entra, ใบรับรอง หรือ RADIUS
การลงชื่อเข้าใช้ Entra ใบรับรองไคลเอนต์ และ RADIUS ต้องใช้ไคลเอนต์และโปรไฟล์ Azure VPN ที่ต่างกัน เลือกวิธีการก่อน แล้วจึงเลือกไคลเอนต์ แล้วจึงเลือกโปรไฟล์
ตัวติดตั้งทำงาน โปรไฟล์ถูกนำเข้า แต่การเชื่อมต่อล้มเหลวที่ขั้นตอนลงชื่อเข้าใช้ ตั๋วเหล่านี้ส่วนใหญ่ไม่ใช่บั๊กในไคลเอนต์: แอปพลิเคชันที่เข้ากันได้กับ OpenVPN สามารถบรรทุกอุโมงค์ได้ แต่ก็ยังไม่รู้วิธีลงชื่อเข้าใช้ Microsoft Entra ลำดับที่หลีกเลี่ยงวงจรคือ วิธีการ แล้วจึงไคลเอนต์ แล้วจึงโปรไฟล์ เลือกวิธีการยืนยันตัวตนที่เกตเวย์กำหนดค่าไว้ เลือกไคลเอนต์ที่ Microsoft จัดทำเอกสารสำหรับวิธีนั้น และจากนั้นจึงสร้างโปรไฟล์ที่ไคลเอนต์นั้นคาดหวัง ทุกอย่างด้านล่างปฏิบัติตามลำดับนั้น
เริ่มจากวิธีการ ไม่ใช่ตัวติดตั้ง
เกตเวย์กำหนดค่าด้วยประเภทอุโมงค์หนึ่งประเภทหรือมากกว่าและวิธีการยืนยันตัวตน คู่นี้ ไม่ใช่นามสกุลไฟล์บนเดสก์ท็อปของคุณ เป็นตัวกำหนดว่าไคลเอนต์ใดได้รับการสนับสนุน
จดคู่ไว้ก่อนดาวน์โหลดสิ่งใด เพราะเมทริกซ์การสนับสนุนแคบ และการเริ่มผิดพลาดทำให้เสียเวลาหนึ่งบ่าย
นี่คือการแมปที่ฉันเก็บไว้ในบันทึกการปรับใช้:
| Authentication | Tunnel type | Documented client |
|---|---|---|
| Microsoft Entra ID | OpenVPN | Azure VPN Client on Windows and macOS |
| Client certificate | OpenVPN or IKEv2 | Azure VPN Client, documented OpenVPN client, native IKEv2 client, strongSwan on Linux |
| RADIUS | IKEv2 or OpenVPN, per the current matrix | Native IKEv2 client, strongSwan, or the OpenVPN client the matrix names |
อ่านตารางนั้นเป็นข้อจำกัด ไม่ใช่เมนู แต่ละแถวคือชุดค่าผสมที่จัดทำเอกสารไว้ และการผสมไคลเอนต์จากแถวหนึ่งกับวิธีการจากอีกแถวหนึ่งคือความล้มเหลวที่บทความนี้มีไว้เพื่อป้องกัน
Entra ID หมายถึง OpenVPN บวก Azure VPN Client
สำหรับการยืนยันตัวตน Entra บนจุดถึงไซต์ การจัดวางที่สนับสนุนใช้ประเภทอุโมงค์ OpenVPN และ Azure VPN Client กล่องโต้ตอบชื่อผู้ใช้และรหัสผ่านทั่วไปไม่ใช่สิ่งทดแทนการผสานรวมนั้น และ IKEv2 แบบเนทีฟของ Windows ไม่ใช่วิธีที่สลับได้ในการลงชื่อเข้าใช้เดียวกัน หากไคลเอนต์ของบุคคลที่สามเสนอตัวเลือก Entra หรือ Azure AD ให้ตรวจสอบกับเอกสาร Microsoft ปัจจุบัน ไม่ใช่กับป้ายกำกับ ป้ายกำกับคือการตลาด ขณะที่ชุดค่าผสมที่จัดทำเอกสารคือสัญญา
บน macOS Azure VPN Client ก็เป็นเส้นทางที่จัดทำเอกสารสำหรับวิธีนี้เช่นกัน
ใบรับรองต้องใช้ข้อมูลรับรองไคลเอนต์ ไม่ใช่แค่รูท
การยืนยันตัวตนด้วยใบรับรองเป็นแบบจำลองที่สนับสนุนแยกต่างหาก และทำงานกับไคลเอนต์ OpenVPN ที่ Microsoft จัดทำเอกสารและกับ Azure VPN Client บนแพลตฟอร์มที่สนับสนุน บน Windows Azure VPN Client ไม่ได้มีไว้สำหรับ Entra เท่านั้น: ยังมีเวิร์กโฟลว์ใบรับรองที่จัดทำเอกสารด้วย สิ่งที่ต้องใช้คือใบรับรองไคลเอนต์ที่ตั้งใจไว้พร้อมคีย์ส่วนตัวที่ใช้งานได้ ซึ่งเกตเวย์เชื่อถือ รูทที่เชื่อถือได้ของเกตเวย์ไม่ใช่ข้อมูลรับรองไคลเอนต์ และคีย์ลงนามของผู้้ออกไม่เคยเป็นส่วนหนึ่งของแพ็กเกจไคลเอนต์
ตรวจสอบห่วงโซ่ก่อนแก้ไขโปรไฟล์ ใบรับรองที่ออกโดยรูทที่เกตเวย์ไม่เชื่อถือทำให้เกิดความล้มเหลวที่ดูเหมือนโปรไฟล์ไม่ดีแต่จริง ๆ แล้วเป็นปัญหาเรื่องความเชื่อถือ
เก็บคีย์ส่วนตัวให้ส่งออกไม่ได้ในที่ที่แพลตฟอร์มอนุญาต และทดสอบด้วยใบรับรองที่ติดตั้งจริงสำหรับผู้ใช้ปัจจุบัน
RADIUS เป็นทางเลือกของแบ็กเอนด์ที่มีชุดค่าผสมของตัวเอง
RADIUS ย้ายการตัดสินใจเรื่องข้อมูลรับรองไปยังเซิร์ฟเวอร์ที่คุณดำเนินการเอง และจัดทำเอกสารด้วยประเภทอุโมงค์และไคลเอนต์เฉพาะ ไม่ใช่คำตอบที่ถูกต้องโดยอัตโนมัติเพียงเพราะสภาพแวดล้อมมีระบบปฏิบัติการหลายระบบ ระบุว่าไคลเอนต์จริงสามารถนำเสนออะไรได้ก่อนเปลี่ยนนโยบายการยืนยันตัวตนของเกตเวย์ เพราะการเปลี่ยนเกตเวย์เป็น RADIUS ไม่ได้ปรับโปรไฟล์ที่มีอยู่ทั้งหมด ไคลเอนต์ยังต้องสามารถขอหรือจัดหาข้อมูลรับรองเหล่านั้นได้
หากสภาพแวดล้อมแบบผสมเป็นสาเหตุ ให้แก้ไขตามแพลตฟอร์มแทนที่จะทำให้นโยบายของเกตเวย์อ่อนลงสำหรับทุกคน
Linux หลังจากการยกเลิกตัวอย่างในปี 2026
คำแนะนำของ Microsoft เกี่ยวกับการยกเลิก Linux ระบุวันที่ 31 สิงหาคม 2026 เป็นวันยกเลิกตัวอย่าง Azure VPN Client สำหรับ Linux ดังนั้นตั้งแต่พฤศจิกายน 2026 ตัวอย่างนั้นอยู่ข้างหลังคุณ การติดตั้งที่มีอยู่อาจทำงานต่อไปได้ แต่จะไม่ได้รับการสนับสนุน การอัปเดต หรือการแก้ไขความปลอดภัยอีกต่อไป อย่าแจกจ่ายตัวติดตั้ง Linux เก่าเป็นการปรับใช้ใหม่ที่สนับสนุน นี่คือการยกเลิกไคลเอนต์ ไม่ใช่การยกเลิก Azure VPN Gateway หรือไคลเอนต์ Windows และ macOS
ทางเลือก Linux ที่จัดทำเอกสารคือไคลเอนต์ OpenVPN ที่มีการยืนยันตัวตนด้วยใบรับรอง หรือ strongSwan ที่มี IKEv2 และการยืนยันตัวตนด้วยใบรับรองหรือ RADIUS ทั้งสองเป็นการกำหนดค่าที่แตกต่างซึ่งต้องได้รับการอนุมัติจากองค์กร ไม่ใช่การแปลงที่ได้จากการเปลี่ยนชื่อโปรไฟล์ Entra เก่า
หากการลงชื่อเข้าใช้ Entra เป็นข้อบังคับด้วยเหตุผลด้านนโยบาย เจ้าของต้องเลือกแพลตฟอร์มที่สนับสนุนหรือการออกแบบทางเลือกที่ได้รับอนุมัติ นั่นคือการตัดสินใจ ไม่ใช่การหลีกเลี่ยง
สร้างโปรไฟล์และดำเนินการตรวจสอบสี่ข้อ
เมื่อชุดค่าผสมชัดเจนแล้ว ให้สร้างการกำหนดค่าไคลเอนต์จากเกตเวย์ที่ตั้งใจไว้ และนำเข้าการแสดงแทนที่จัดทำเอกสารสำหรับไคลเอนต์และวิธีนั้น โฟลเดอร์ OpenVPN ทั่วไปและโปรไฟล์ XML ของ Azure VPN Client ใช้แทนกันไม่ได้ หากเกตเวย์เปิดใช้ประเภทการยืนยันตัวตนหลายประเภทโดยเจตนา ให้เลือกโปรไฟล์และเส้นทางข้อมูลรับรองที่ตรงกันแทนที่จะคาดหวังให้การเชื่อมต่อเดียวตอบสนองทั้งหมด จากนั้นดำเนินการตรวจสอบตามลำดับนี้:
- ไคลเอนต์ที่สนับสนุนนำเข้าโปรไฟล์ที่สร้างขึ้นโดยไม่แก้ไข
- ตัวตนที่ตั้งใจไว้ยืนยันตัวตนด้วยวิธีที่โปรไฟล์นั้นคาดหวัง
- นโยบายเส้นทางและตัวแก้ไขที่จำเป็นปรากฏบนไคลเอนต์.
- แอปพลิเคชันที่ได้รับอนุญาตเข้าถึงทรัพยากรส่วนตัวของตน
การนำเข้าที่สำเร็จไม่ได้พิสูจน์ทั้งความเข้ากันได้ของการยืนยันตัวตนและการอนุญาตทรัพยากรส่วนตัว ดังนั้นการตรวจสอบสี่ข้อนั้นจึงแยกจากกัน