ההתחברות ל-VPN נתקעת אחרי Access-Challenge מ-RADIUS

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

התחברות אחת, שני חילופים עם RADIUS

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

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

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

מה האתגר באמת נושא

מפרט RADIUS מתאר את קוד 11 בסעיף 4.4 ומתיר שני מאפיינים שחשובים כאן. Reply-Message מחזיק טקסט המיועד למשתמש, ו-State מחזיק ערך אטום שהשרת רוצה לקבל בחזרה. ה-NAS אינו אמור לפרש את State, אלא רק להחזיר אותו ללא שינוי.

בקשת ההמשך משתמשת ב-Identifier חדש וב-Request Authenticator חדש, והיא חייבת לשאת את אותו ערך State בתוספת תגובת המשתמש. השרת מתאים אותה לאתגר הממתין דרך אותו State, ולכן שער שמחדש או מפיל את המאפיין לא יכול להשלים את הטקס. גם ה-response authenticator בכל תשובה חייב לעבור אימות, אחרת על ה-NAS להשליך את החבילה.

סעיף 4.4 מוסיף את הפרט שמסביר את רוב הכשלים השקטים: NAS שאינו תומך באתגרים מתייחס ל-Access-Challenge כדחייה. אם שירות ה-VPN בשער שלכם קדם לתמיכה הזו או משמיט אותה, בקשת הקצה האחורי לגורם שני הופכת ל«האימות נכשל» מיידי בלי שום בקשה.

איפה בקשת השרשרת הולכת לאיבוד

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

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

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

עקבו אחרי ניסיון אחד מתחילתו ועד סופו

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

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

בפלט חפשו את צורת השיחה ולא שורה אחת. Access-Request ראשונה עם Identifier 3, Access-Challenge שנושא State, ואז Access-Request שנייה עם Identifier 4 שמחזירה על אותו State וכוללת את תגובת המשתמש. אם הבקשה השנייה חסרה, השער לא ביצע המשך כלל. אם היא מגיעה בלי State, השרת לא יכול להתאים אותה לאתגר הממתין ובדרך כלל ידחה אותה.

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

המצב הסופי שאתם רוצים הוא שיחה שהושלמה ואושרה, ואחריה הגישה המיועדת לשירות. תגובה שמגיעה משרת ה-RADIUS מוכיחה הרבה פחות מזה.