הוספת משתמש לקבוצת VPN אינה מעניקה גישה בעצמה
חברות בקבוצה היא תנאי אחד, לא הרשאה. בדקו מה השער באמת התאים, קראו את רשומת הקבלה או הדחייה, ובדקו את שני התוצאות.
שמתם את החשבון בקבוצה הנכונה, ההתחברות הצליחה, והחיבור עדיין נדחה, או שהוא מתחבר ולא מגיע לשום דבר שימושי. התגובה הרגילה היא להוסיף את המשתמש לעוד קבוצות עד שמשהו נכנע, וכך ארגונים מעניקים הרבה יותר ממה שהכרטיס ביקש. חברות בקבוצה היא קלט אחד להחלטת ההרשאה, אף פעם לא ההחלטה עצמה: השער אוסף כמה עובדות על החיבור, מתאים אותן למדיניות מסודרת ורק אז מחליט למה החיבור רשאי לגעת. אם תנאי אחר נכשל, שינוי הקבוצה לא משנה דבר מלבד החשיפה שלכם.
חברות בקבוצה היא תנאי, לא הרשאה
ב-RADIUS הקבוצה מגיעה כמאפיין הרשאה, ומאפיינים מתארים את החיבור במקום להתיר אותו. השרת עונה ב-Access-Accept או Access-Reject; בעת קבלה הוא יכול לצרף Filter-Id, Class או את מאפייני המנהרה מ-RFC 2868, והציוד ברשת בצד השני מפרש אותם כפי שהחליט היצרן. שום דבר בפרוטוקול לא ממפה קבוצה לגישה מלאה; את המיפוי הזה כותב מי שהגדיר את המדיניות בשער או בשרת גישת הרשת.
לכן אותו שם קבוצה מתנהג אחרת בשתי מערכות. Microsoft NPS מרכיב מדיניות רשת מתנאים, הגבלות והגדרות ומעריך אותן בסדר מוגדר. ל-OpenVPN Access Server יש מודל קבוצות וכללי גישה משלו, ושרת OpenVPN קהילתי מרבה להעביר את כל השאלה לסקריפט client-connect או לקובץ client-config-dir.
הכלל שהתאים הוא שמחליט, לא הקבוצה שציפיתם לה
רוב המנועים עוצרים במדיניות הראשונה שמתאימה או בספציפית ביותר. אם מדיניות 3 דוחה ומדיניות 7 מתירה, החיבור עלול להיכשל בלי להגיע לכלל שהיה מניח לו לעבור. הסדר הוא הגדרה אמיתית ב-NPS וברבים ממוצרי בקרת הגישה לרשת, והוא נסחף עם השנים.
התנאים שנוסעים עם הקבוצה הם החצי השני. מצב המכשיר, שיטת האימות, MFA שהושלם, רשת המקור, נושא התעודה או חלון שעות יכולים לשבת באותה מדיניות. כשאחד מהם לא מתקיים המדיניות לא מתאימה, המנוע נופל, ונדחה ברירת המחדל. מכיסא המשתמש זה נראה כאילו הקבוצה מתעלמת; מכיסא המנוע בכלל לא נשאלו על הקבוצה.
פרטי המדריך יוצרים אותה אשליה. מדיניות שמתאימה לפי חברות בקבוצות Windows קוראת את ה-SID בטוקן של המשתמש, ושם נספרות רק קבוצות אבטחה, קבוצת תפוצה לעולם לא מופיעה. הקבוצה הראשית נישאת בשדה משלה ולא ברשימה, ולכן מדיניות שננעצה בה עלולה להיכשל בשקט.
קראו את רשומת הקבלה או הדחייה לפני שאתם נוגעים בקבוצה
שאלו קודם שאלה אחת: האם הבקשה בכלל הגיעה לשלב ההרשאה? ב-NPS התשובה ביומן האירועים, שם 6272 רושם גישה שניתנה, 6273 דחייה, ו-6274 בקשה שהשרת זרק לפני הערכת המדיניות. שלושת המספרים האלה מחלקים את הבעיה לשלוש חקירות שונות, ורק אחת מהן עוסקת בקבוצות.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
כשהיומן אינו בהישג יד, שאלו את השרת ישירות וקראו מה הוא מחזיר. תשובה בלי Filter-Id ובלי מאפייני מנהרה אומרת שהשרת רואה את החיבור כשגרתי ושהשער מיישם כללים משלו. תשובה עם מאפיינים שנקודת האכיפה לא מיישמת היא תקלה אחרת: ההרשאה עברה, והמכשיר התעלם מהתוצאה.
radtest alice 'password' 10.0.0.5 0 testing123השוו את המאפיינים שהוחזרו לאלה שהשער מתעד, לא למה ששם הקבוצה מרמז. ההשוואה הזאת מפרידה בדרך כלל בין בעיית מדיניות לבעיית אכיפה.
שינוי קבוצה אינו רטרואקטיבי
מאפייני הרשאה מוחזרים פעם אחת, בעת אימות החיבור. השער שומר אותם על החיבור ואינו קורא שוב את המדריך לכל מנה, ולכן חיבור קיים ממשיך לעבוד אחרי שהוצאתם מישהו מקבוצה, וחיבור חדש עלול להיכשל.
כדי שהשינוי ייכנס לתוקף דרושה החלטת הרשאה חדשה, לא רק מפתחות חדשים. במקום שהשרת תומך בהרשאה דינמית RFC 5176, Disconnect-Request או CoA-Request ל-UDP 3799 מאלצים הערכה מחדש; אחרת נתקו את הלקוח ותנו לו להתחבר שוב. משא ומתן מחדש מרענן את מפתחות המנהרה ובדרך כלל משאיר את תוצאת ההרשאה ללא שינוי.
תקנו את התנאי, לא את הקבוצה
כשיודעים איזו מדיניות פעלה, התיקון בדרך כלל קטן: סדרו מחדש דחייה שמאפילה על ההתרה הרצויה, הוסיפו את תנאי המכשיר או ה-MFA החסר למדיניות שהתכוונתם אליה, או כתבו כלל צר למשאב האחד במקום להעלות את המשתמש לקבוצה שנושאת עשרה אחרים.
לולאה קצרה שומרת על השינוי ישר:
- שחזרו את הדחייה עם החשבון המקורי ורשמו את מזהה האירוע לפני שאתם משנים משהו.
- שנו אובייקט אחד, סדר מדיניות, תנאי אחד או קבוצה אחת, ורשמו איזה.
- פתחו חיבור חדש, ודאו שההתרה מופיעה ביומן ושאל המשאב באמת נפתח.
- בדקו משתמש שאמור עדיין להידחות, כדי שהתיקון לא הרחיב את המדיניות בטעות.
אם ההתרה נכונה והמשאב עדיין לא נפתח, הבעיה עברה לניתוב או לפתרון שמות ברגע ההרשאה. הפרידו בין שתי התקלות והכרטיס הבא ייקח דקות, לא אחר צהריים.