RouterOS OpenVPN ו-NPS: הגדירו user-auth-method, לא auth

RouterOS יכול להגיע ל-NPS עם התחברות OpenVPN ובכל זאת להידחות, והסיבה הרגילה היא שתי הגדרות ששמותיהן נשמעים שתיהן כמו אימות. האחת בוחרת תקציר קריפטוגרפי למנהרה; האחרת קובעת כיצד פרטי הכניסה של המשתמש מוצגים ל-RADIUS. שינוי התקציר לעולם לא יהפוך בקשת PAP ל-MS-CHAPv2, לא משנה כמה פעמים השירות יופעל מחדש. הרשימה שלהלן מפרידה בין השניים, ואז עוקבת אחר התחברות כושלת אחת דרך מדיניות NPS ששפטה אותה.

שלב 1: קראו את שתי ההגדרות לפני שינוי אחת מהן

הדפיסו את תצורת שרת OpenVPN האפקטיבית בנתב שמסיים את המנהרה, לא מגיבוי או מהודעה שהועתקה בפורום. שני השדות שמעניינים אתכם נמצאים בדרך כלל באותו תפריט ונקראים כאילו היו חלופות. הם לא: האחד עוסק בערוץ הנתונים, והאחר בחילופי פרטי הכניסה.

/interface ovpn-server server print
/interface ovpn-server server export

השדה auth מפרט תקצירים כגון sha1 ו-sha256 ומפעיל את ה-HMAC שמאמת חבילות מנהרה. השדה user-auth-method בוחר pap או mschap2 וקובע כיצד הנתב מציג את פרטי הכניסה של המשתמש ל-RADIUS. שינוי תקציר אינו יכול לשנות את ההתנהגות השנייה, ולכן אותה דחייה שורדת כל כוונון של הראשונה.

עצרו כאן אם הגרסה שלכם אינה חושפת את user-auth-method כלל. גרסאות RouterOS ישנות יותר עשויות שלא להציע אותו בשרת OpenVPN, והתיקון שייך לגרסה שתוכלו לתמוך בה, לא לפקודה שהועתקה מגרסה חדשה יותר.

שלב 2: מצאו את המדיניות שדחתה את ההתחברות בפועל

בצד NPS, בקשת חיבור מוערכת מול מדיניויות רשת, ושיטת האימות הנקובה במדיניות המתאימה חייבת להיות אחת שהלקוח הציע בפועל. קשרו התחברות כושלת אחת לפי זמן ומשתמש במקום לקרוא ספירת סיכום. יומן האבטחה רושם בקשות שאושרו ונדחו עם קוד סיבה, מה שאומר לכם הרבה יותר משורת הכשל הגנרית של הנתב.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

קראו שלושה דברים באירוע: שם המדיניות המתאימה, שיטת האימות וקוד הסיבה. מדיניות שדורשת MS-CHAPv2 דוחה בקשת PAP גם כשהסיסמה נכונה, ומדיניות שדורשת חשבון תחום דוחה חשבון מקומי. רשומת לקוח RADIUS חייבת גם להתאים לכתובת המקור של הנתב, אחרת הבקשה נזרקת לפני שכל מדיניות נבדקת. שום דבר מזה אינו מופיע ביומן OpenVPN.

עצרו כאן אם הבקשה אינה מגיעה ל-NPS כלל. זו בעיה של סוד משותף, כתובת לקוח או UDP 1812, ושינוי שיטות אימות לא יתקן אותה.

שלב 3: שנו שיטה אחת, בשני הצדדים

אם העיצוב המאושר הוא MS-CHAPv2, הגדירו אותו בנתב ואשרו שהמדיניות המתאימה מקבלת אותו. שנו צד אחד, בדקו שוב ואז שנו את האחר; שינוי שניהם בבת אחת משאיר אתכם בלי יכולת לומר איזה מהם היה חשוב.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

אל תפעילו כל שיטה חלשה יותר ב-NPS כדי שהשגיאה תיעלם. ה-backend חייב להחזיק חומר שהשיטה הנבחרת יכולה לאמת: MS-CHAPv2 זקוק לגישה לסיסמה או לתחום, ומדיניות אינה יכולה להמציא את החומר הזה. הרחבת המדיניות מרחיבה גם את מה שתוקף יכול לנסות נגד אותו חשבון. רשמו את השיטה, את שם המדיניות ואת אסמכתת השינוי יחד, כדי שהאדם הבא יירש החלטה ולא ניחוש.

השאירו את אימות התעודה של המנהרה בדיוק כפי שהיה. שיטת פרטי כניסה אינה מחליפה את זהות השרת, והורדת בדיקות TLS כדי שבדיקה תעבור מחליפה בעיה אחת בגרועה ממנה.

שלב 4: בדקו שלוש התחברויות והרשאה אחת

בדקו משתמש מורשה, סיסמה שגויה ומשתמש מוחרג, כל אחד בהפעלה חדשה. הראשון מוכיח את הנתיב, השני מוכיח שבדיקת פרטי הכניסה אמיתית, והשלישי מוכיח שהמדיניות עדיין מחריגה את מי שהיא צריכה. הפעלה שמורה במטמון יכולה להסתיר את שלושתם, לכן התנתקו בין הניסיונות.

/log print where topics~"ovpn"
/radius monitor 0

הצלחת האימות אינה סוף הרשימה. בדקו את הכתובת שהלקוח קיבל ואת המשאבים שאותה כתובת יכולה להגיע אליהם, כי משתמש יכול להאומת כראוי ובכל זאת לנחות במאגר הלא נכון. אם הכתובת שהוקצתה שגויה, הבעיה נמצאת בפרופיל או במאפייני תגובת RADIUS, לא בשיטה. אשרו את שניהם לפני סגירת הפנייה.

הרשימה הושלמה כאשר הגדרת הנתב ומדיניות NPS נוקבות באותה שיטה, משתמש מורשה אחד מתחבר בהפעלה חדשה, סיסמה שגויה אחת נדחית, משתמש מוחרג אחד נשאר מוחרג, והכתובת שהוקצתה תואמת למאגר המיועד. כל דבר פחות מזה משאיר את ההתחברות הבאה לגורל.