אימות לקוח 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 הוא בחירת backend עם השילובים שלו
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 אינם ניתנים להחלפה. אם השער מפעיל בכוונה כמה סוגי אימות, בחרו את הפרופיל ונתיב האישורים המתאימים במקום לצפות שחיבור אחד יענה על כולם. לאחר מכן הריצו את הבדיקות בסדר הזה:
- הלקוח הנתמך מייבא את הפרופיל שנוצר בלי לערוך אותו.
- הזהות המיועדת מאמתת את עצמה בשיטה שהפרופיל מצפה לה.
- מדיניות המסלול והפותרים הנדרשת מופיעה בלקוח.
- האפליקציה המורשית מגיעה למשאב הפרטי שלה.
ייבוא מוצלח אינו מוכיח לא תאימות אימות ולא הרשאה למשאב פרטי, ולכן ארבע הבדיקות האלה נשארות נפרדות.