EAP דרך שער VPN: מי מסיים את השיטה

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

שני מסלולי אימות שנראים זהים ביומן

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

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

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

איפה השיטה באמת רצה

RFC 3579 מגדיר את סידור ההעברה: ה-NAS נושא מנות EAP במאפייני RADIUS ואינו זקוק לקוד ייחודי לכל סוג EAP. לכן שער יכול לתמוך ב-PEAP וב-EAP-TLS בלי לממש אף אחד מהם.

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

הגדרות אימות PPP שייכות לשירות PPP. הן אינן מגדירות מחדש בשקט כל מסלול IPsec או XAuth ישן שמשתמש באותו שרת AAA, ולכן שינוי שעובד לסוג גישה אחד יכול להשאיר את האחר ללא שינוי.

מה ה-NAS חייבת לתמוך

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

ב-IKEv2 EAP הוא חלק מזרימת אימות מוגדרת, ובדיקות הזהות והאמון של השרת מגיעות מאותה זרימה. תווית PEAP שהושאלה מפריסת 802.1X אינה עוברת אוטומטית, כי המשא ומתן סביבה שונה.

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

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

לכדו ניסיון מאושר אחד בשער ובשרת האימות. חפשו מאפייני EAP-Message בבקשת RADIUS. נוכחותם אומרת שמסלול ההעברה בשימוש; היעדרם מצביע על חליפין של פרטי התחברות.

בשער Linux לכידה בפורט RADIUS מראה אילו מאפיינים נמצאים על החוט:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

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

תכננו את המעבר כשינוי אחד מקצה לקצה

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

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

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