איך התחברות VPN מגיעה ל-RADIUS ולספק הזהות שלכם
עקבו אחר התחברות VPN מהלקוח לבקשת RADIUS של השער, לספק הזהות שמאחוריה ולמדיניות שמופעלת לאחר הקבלה.
בשבוע שעבר משתמש הצליח להתחבר ל-VPN ובכל זאת נחת ברשת שבה שום דבר לא נפתר. הלקוח אמר מחובר, יומן השער אמר Access-Accept, וצוות הזהות אמר שהחשבון תקין. ההתחברות עבדה; ההרשאה שמאחוריה לא. כשהתחברות VPN נכשלת, אני הולך בדרך שהבקשה באמת עוברת — לקוח, שער, שרת RADIUS, ספק זהות — ועוצר בצעד הראשון שתשובתו אינה מתיישבת עם הבא.
הלקוח לא מדבר RADIUS אף פעם
יהיה מה שהאפליקציה על המחשב הנייד מציגה, הצעד הראשון שלה הוא פרוטוקול ה-VPN: IKEv2, OpenVPN, WireGuard או לקוח מבוסס TLS. RADIUS אינו מופיע בחילופים האלה. הלקוח מאמת את עצמו מול השער בעזרת תעודה, שם משתמש וסיסמה, או שיטת EAP שנישאת בתוך הגדרת המנהרה.
זה חשוב כשקוראים יומנים, כי שגיאת האימות הכללית שהמשתמש רואה מיוצרת על ידי השער לאחר שכבר דיבר עם משהו אחר. אם הלקוח לא מגיע לשער כלל, אין בקשת RADIUS לניפוי, ושעה שהושקעה בשרת RADIUS אבודה. ודאו שהמנהרה בכלל עלתה לפני שנוגעים ב-backend.
השער הוא לקוח ה-RADIUS
ברגע שהגדרת המנהרה מגיעה לנקודה שבה יש לבדוק אישורים, השער הופך לשרת גישה לרשת. הוא בונה Access-Request: User-Name, סיסמה או מטען EAP, NAS-IP-Address או NAS-Identifier, ו-Message-Authenticator כשהשיטה דורשת אחד. הבקשה הולכת ל-UDP 1812 כברירת מחדל, והנהונהלנות ל-1813. פריסות ישנות יותר עדיין משתמשות ב-1645 וב-1646, ולכן כלל חומת אש שנכתב לזוג אחד מסביר הרבה כשלים שקטים.
שני הצדדים חולקים סוד, והוא אינו אישור משתמש. הוא חותם על החילוף, וכל תשובה מאומתת מולו. הגדירו את הסוד אחרת בשני הצדדים והשרת לא עונה בסוד שגוי — הוא מפיל את הבקשה או שהתשובה נכשלת באימות, ולכן השער מדווח על פסק זמן. סוד שגוי ושרת מת נראים זהים מהשער, ולכן אני בודק את הצעד בכלי לקוח לפני שאני מאשים את הספרייה.
הפרוטוקול קטן וישן — RFC 2865 מגדיר את חילוף האימות — אבל התכונות שהוא נושא הן הבסיס שעליו בנויה רוב מדיניות ה-VPN.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'ייתכן ששרת RADIUS הוא רק החזית של ספק הזהות
אנשים מדברים על RADIUS ועל ספק הזהות כאילו היו אותה קופסה. לעיתים קרובות הם לא. שרת RADIUS מקבל את ה-Access-Request ואז שואל משהו אחר — Active Directory דרך LDAP או Kerberos, קובץ משתמשים מקומי או שירות חיצוני — לפני שהוא עונה. FreeRADIUS עם מודול LDAP או krb5, Windows NPS ו-Cisco ISE כולם עומדים בעמדה הזו.
ההבחנה קובעת היכן להסתכל. סיסמה שנדחתה היא תשובה של ספק הזהות שה-RADIUS מעביר. פסק זמן הוא בדרך כלל הקטע RADIUS-לספרייה: חשבון קישור שפג, ספרייה שאינה נגישה, או בקשה שהופנתה ל-backend שגוי. אם שם המשתמש נושא סיומת דומיין, השרת עשוי לנתב לפיה, ואותו חשבון שנשלח כ-CORP\alice וכ[email protected] יכול לנחות במקומות שונים. ב-Windows NPS יומן Security רושם 6272 להענקה ו-6273 לדחייה, מה שאומר לכם אם ההחלטה בכלל הגיעה מ-NPS.
קראו את הכשל בצעד שיצר אותו
הודעת לא-מצליח-להתחבר אחת מכסה ארבעה כשלים שונים. לפני שמשנים משהו, התאימו את התסמין לצעד שיצר אותו.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
השורה האחרונה היא זו ששולחת אנשים לצוות הלא נכון. Access-Accept פירושו שהאישורים התקבלו; הוא אינו אומר שהשער הציב את המשתמש בבריכה הנכונה או דחף מסלולים. תכונות קבוצה חשובות רק אם מדיניות השער קוראת אותן. ראיתי התחברות נכונה נוחתת בבריכת אורחים כי מיפוי הקבוצות הוגדר בצד RADIUS לתכונה שונה מזו שהשער בודק.
עקבו אחר התחברות אחת מתחילתה ועד סופה
בחרו חשבון בדיקה אחד ושער אחד, ואז התבוננו באותו ניסיון בכל ארבע הנקודות. התחילו ריצת ניפוי בצד RADIUS — freeradius -X מדפיס את הבקשה וכל מודול שהיא נוגעת בו — עקבו אחר יומן האימות של השער, והריצו tcpdump לחילופי ה-UDP. התחברו פעם אחת וקראו את ארבעת העקבות לפי הסדר.
מה שתרצו לראות הוא הסכמה: השער שאל על המשתמש שציפיתם לו, שרת RADIUS בחר את ה-backend שציפיתם לו, ה-backend החזיר החלטה, והתכונות בתשובה תואמות למדיניות שהשער מיישם. המקום הראשון שבו העקבות אינן מסכימות הוא קו התקלה שלכם. אם התשובה אינה נושאת תכונת קבוצה, הבעיה בצד RADIUS, לא בפרופיל ה-VPN; אם התכונה קיימת והשער מתעלם ממנה, מדיניות השער היא הבעיה.
הערת אבטחה אחת כל עוד אתם שם. הסוד המשותף מגן על החילוף, אבל הוא אינו מצפין את רוב התכונות. אם השער ושרת RADIUS נמצאים במקטעים שונים, שימו את הצעד הזה על RADIUS דרך TLS או נתיב פרטי. מנהרת משתמש מוצפנת אינה אומרת דבר על הקישור ל-backend.
לפני שסוגרים את הפנייה, אשרו ארבעה דברים. השער יכול להגיע לשרת RADIUS בפורט שהוא באמת מוגדר עבורו. הסוד המשותף תואם בשני הצדדים. שרת RADIUS מפענח את הצורה המדויקת של שם המשתמש שהשער שולח. הקבלה נושאת את התכונות שמדיניות השער צריכה. כשכל הארבעה מתקיימים, התחברות שעדיין נכשלת היא בעיית מדיניות שער, לא בעיית אימות.