احراز هویت کلاینت P2S در Azure: 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 قابل‌جانشینی نیستند. اگر دروازه عمداً چند نوع احراز هویت را فعال می‌کند، پروفایل و مسیر اعتبارنامه متناظر را انتخاب کنید نه اینکه انتظار داشته باشید یک اتصال همه را برآورده کند. سپس بررسی‌ها را به این ترتیب انجام دهید:
- کلاینت پشتیبانی‌شده پروفایل ساخته‌شده را بدون ویرایش آن وارد می‌کند.
- هویت موردنظر با روشی که آن پروفایل انتظار دارد احراز هویت می‌شود.
- سیاست مسیر و حل‌کننده موردنیاز روی کلاینت ظاهر می‌شود.
- برنامه مجاز به منبع خصوصی خود دسترسی پیدا می‌کند.
یک ورود موفق نه سازگاری احراز هویت را اثبات می‌کند و نه مجوز منبع خصوصی را، به همین دلیل آن چهار بررسی جدا می‌مانند.