eapol_test דרך VPN: האם חילופי RADIUS זקוקים לשכבה 2?

אם תבקשו יציאת מתג במעבדה כדי להריץ eapol_test — כנראה פירשתם את הכלי לא נכון. ה־peer ולקוח ה־RADIUS חיים שניהם בתוך אותו קובץ בינארי יחיד, ולכן השיחה היחידה שיוצאת מהמכונה היא חילופי ה־RADIUS עצמם. מנהרה מנותבת בין מארח הבדיקה לשרת האימות היא כל דרישת הרשת. נתיב 802.1X הפיזי הוא דבר אחר שאולי עוד תצטרכו לבדוק, והוא לא זה.

למה השם שולח אנשים לחפש יציאת מתג

EAPOL הוא פורמט המסגרת שמשתמשים בו supplicant ומתג ברשת מקומית, והכלי שואל את השם משום שהוא צמח מהעולם הזה. מה שמסופק הוא תוכנית בדיקה שנושאת את מכונת המצבים של ה־peer ואת לקוח ה־RADIUS בתהליך אחד, ולכן שני החצאים של שיחת 802.1X לא נפגשים לעולם על גבי כבל. השם הוא היסטוריה, לא דרישת טופולוגיה.

אנשים עדיין מבקשים את היציאה משום שהתוכנית נשענת על התנהגות של מאמת, וזה נשמע כמו חומרה. הדבק שלה משחזר את מכונת המצבים של המאמת, ולכן בדיקה מסתיימת בלי נקודת גישה בחדר; הקובץ הבינארי המקומפל מקשר את EAP peer של wpa_supplicant עם לקוח ה־RADIUS של hostapd. הסרת המתג מסירה את קפיצת ה־EAPOL, לא את היגיון האימות. מה שנשאר הוא חילופי לקוח־שרת בין שני מארחי IP.

עקבו אחר חילופי RADIUS אחד קפיצה אחר קפיצה

עקבו אחר ניסיון אחד והנתיב קצר. ה־peer שבתוך eapol_test מייצר EAP-Response לשיטה שהגדרתם, ולקוח ה־RADIUS באותו תהליך מכניס אותו ל־Access-Request, ונושא את המטען במאפייני EAP-Message לצד Message-Authenticator. הדאטגרם הזה ממוען לשרת בפורט UDP 1812 והוא יוצא מהמארח כמו כל חבילת IP אחרת, ושם נכנסת המנהרה. השרת מעריך אותו מול המדיניות ומודולי השיטות שלו, ואז עונה ב־Access-Challenge, Access-Accept או Access-Reject.

eapol_test -c peap-mschapv2.conf -a 198.51.100.20 -p 1812 \
  -s REPLACE_WITH_RADIUS_SECRET -t 30

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

הקובץ הבינארי ומדיניות השרת הם רשימות שונות

שתי רשימות בלתי תלויות קובעות אם שיטה יכולה לעבור, וערבוב ביניהן מבזבז יום. הרשימה הראשונה מקומפלת לתוך הקובץ הבינארי: תצורת הבנייה בוחרת אילו שיטות EAP קיימות, ולכן בנייה בלי שיטה לא תוכל לנהל עליה משא ומתן יהיה אשר יהיה מה שהשרת מתיר. הרשימה השנייה חיה בשרת, שם המדיניות אומרת אילו מן השיטות הנתמכות רשאית מחלקת לקוחות זו להשתמש. מעבר דורש חיתוך, ואף רשימה לא יכולה למלא חור ברעותה.

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

מה שמעבר עדיין אינו מכסה

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

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

רשימת בדיקה לפני שתצטטו את התוצאה

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

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