802.1X, FreeRADIUS ו-VLAN דינמי: מדריך מלא

אינפורמטק דיגיטל » Recursos » 802.1X, FreeRADIUS ו-VLAN דינמי: מדריך מלא

אם אתם מנהלים רשתות קוויות או Wi-Fi ורוצים להפריד תעבורה לפי סוג משתמש מבלי להזדקק לפתרון NAC יקר, שימוש יעיל ב-802.1X, FreeRADIUS והקצאת VLAN דינמית הוא אחד הדברים החזקים ביותר שאתם יכולים לעשות, וכדאי להבין כיצד זה משתלב עם ארכיטקטורת Zero Trust . מיושם כהלכה, זה מאפשר לכם להחליט לאיזו רשת כל מכשיר מתחבר על סמך מי הוא, מאיפה הוא מגיע או לאיזו קבוצת ספריות הוא שייך, מבלי ליצור SSID בכל מקום או להיות קשורים לספק יחיד.

במאמר זה, נפרט בפירוט כיצד כל הפאזל משתלב יחד: תפקידו של 802.1X, תצורת FreeRADIUS אופיינית, תכונות RADIUS עבור VLAN, אינטגרציה עם בקרי ומתגים של Wi-Fi , דוגמאות מהעולם האמיתי (Omada, ExtremeCloud IQ, מתגים קלאסיים), בעיות נפוצות, ואפילו נושאים מתקדמים כמו Azure AD ותכונות פגומות ב-LDAP. המטרה היא שתהיה לכם הבנה ברורה ומעשית בסוף, ותוכלו להתאים את מה שתלמדו כאן לתשתית שלכם, בין אם היא קטנה או גדולה.

802.1X ורשתות VLAN דינמיות: מושגים ורכיבים בסיסיים

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

בכל פריסת 802.1X, ישנם שלושה רכיבים מרכזיים שתמיד מופיעים, בין אם אתם משתמשים ב-Omada, ExtremeCloud IQ או במתגים גנריים:

• מְבַקֵשׁהלקוח שרוצה להתחבר (מחשב נייד, נייד, מדפסת "מוכנה" וכו').
• המאמתציוד הרשת ששולט בגישה (מתג, נקודת גישה או בקר Wi-Fi) ומתקשר עם שרת RADIUS.
• שרת אימותבדרך כלל א רַדִיוּס, לעתים קרובות FreeRADIUS, אשר מאמת אישורים וקובע מדיניות (אפשר, לדחות, להכניס VLAN אחד או אחר).

הקסם של רשתות VLAN דינמיות עובר בצורה של מאפייני RADIUS בתוך פרוטוקול Access-Accept . עבור רשתות VLAN, כמעט כל היצרנים מבינים את השילוב של מאפיינים דמויי מנהרה:

• סוג מנהרה = VLAN
• סוג מנהרה-מדיום = IEEE-802
• מזהה קבוצה פרטית של מנהרה = "VLAN ID" (בדרך כלל מספר בין 1 ל-4095, למרות שהוא נשלח כטקסט)

כאשר המתג או נקודת הגישה מקבלים הודעת Access-Accept עם תכונות אלה, אם הם תומכים ב-802.1X וב-VLAN דינמי, הם מקצה את הפורט או את סשן ה-Wi-Fi ל- VLAN המצוין על ידי ה-RADIUS, תוך התעלמות מה-VLAN או ה-SSID המוגדרים כברירת מחדל של הפורט (אלא אם כן ה-RADIUS אינו שולח דבר, ובמקרה כזה הוא מחיל את התצורה המקומית שלו).

תצורת FreeRADIUS עבור VLAN דינמיים

FreeRADIUS הוא שרת RADIUS בקוד פתוח מובהק. ניתן להתקין אותו על כל מערכת לינוקס צנועה , אפילו על חומרה קטנה מאוד כמו NanoPi NEO או Raspberry Pi, ועם תצורה נכונה, הוא יכול להתמודד עם סביבות תובעניות מאוד. עבור VLANs דינמיים, ישנם שני תחומים עיקריים: הגדרת משתמשים/קבוצות ומיקום נכון של המודולים בשרשרת העיבוד.

בפריסות פשוטות, ניתן להגדיר משתמשי בדיקה ישירות בקובץ המשתמשים של FreeRADIUS , ולהקצות להם את ה-VLAN שהם צריכים לקבל. קובץ טיפוסי בדביאן/אובונטו ממוקם בכתובת /etc/freeradius/3.0/users , וערכי ה-VLAN נראים כך (פשוטים ונכתבים מחדש):

עובד10 סיסמה ברורה := "key10" סוג שירות := משתמש ממוסגר, סוג מנהרה := VLAN, סוג מנהרה בינוני := IEEE-802, מזהה קבוצה פרטית מנהרה := "10" עובד20 סיסמה ברורה := "key20" סוג שירות := משתמש ממוסגר, סוג מנהרה := VLAN, סוג מנהרה בינוני := IEEE-802, מזהה קבוצה פרטית מנהרה := "20"

עם מבנה זה, FreeRADIUS יחזיר, לאחר Access-Accept, את שלושת מאפייני המנהרה כך שה- NAS (מתג או AP) יוכל למקם את הלקוח ב-VLAN 10 או 20, בהתאם למשתמש. המפתח הוא שציוד הרשת תומך ב-RFC המתאים ומכבד מאפיינים אלה לפני VLAN הגישה המוגדר.

בתרחישים מסוימים, כגון אינטגרציה עם ExtremeCloud IQ, חיוני שתכונות אלו יישלחו בדיוק במשפט Access-Accept , ולא רק כתכונות "מנהרות" בשלבים אחרים של תהליך ה-EAP. בתצורות ברירת מחדל, FreeRADIUS עשוי לעבד את מודול ה-eap תחילה ולאחר מכן את מודול הקבצים (אשר קורא את קובץ המשתמש). זה גורם לבקר לפספס את התכונות בזמן המתאים.

הפתרון המעשי שהוכח כיעיל הוא להתאים את הקובץ /etc/freeradius/3.0/sites-enabled/default , ולהזיז את מודול הקבצים לפני ה-eap בתוך בלוק ה-authorization . בדרך זו, FreeRADIUS טוען תחילה את מאפייני המשתמש הסטטיים (כולל VLAN) ולאחר מכן מטפל ב-EAP, כך שכאשר בונה את ה-Access-Accept הסופי , מאפייני המנהרה ייכללו במקום שבו הבקר מצפה להם.

התאמה מומלצת נוספת היא להשבית שיטות EAP חלשות כמו EAP-MD5 , שמעולם לא נועדו לסביבות ייצור. על ידי עריכת הקובץ /etc/freeradius/3.0/mods-enabled/eap והוצאת הערות או מחיקת מקטע MD5, FreeRADIUS יפסיק להציע אותו. מומלץ למקד את התצורה שלך בשיטות חזקות כמו EAP-TLS (אישורים) או PEAP עם MSCHAPv2.

הקצאת VLAN עם Omada: RADIUS פנימי ו-FreeRADIUS חיצוני

מערכת ה-Omada של TP-Link (בקר + מתגים + נקודת גישה) משלבת 802.1X עם VLAN דינמיים בצורה טובה מאוד, הן באמצעות RADIUS פנימי והן על ידי האצלת סמכויות ל-FreeRADIUS חיצוני. זוהי דוגמה ממחישה מאוד מכיוון שכל תהליך העבודה גלוי בבירור.

כדי להשתמש ב-RADIUS המובנה בבקר Omada, בדרך כלל מתבצע תהליך בן שלושה שלבים. ראשית, בתפריט הגלובלי של הבקר, ה- RADIUS המשולב מופעל על ידי ציון כתובת ה-IP (זו של הבקר עצמו) והפעלת האפשרות Tunneled Reply כך שתשלח בצורה נכונה את מאפייני המנהרה להתקן הגישה.

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

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

אם אנו מעדיפים לרכז הכל בשרת FreeRADIUS חיצוני, Omada תומכת באופן מושלם בתרחיש זה. הצעד הראשון הוא לערוך את קובץ clients.conf בשרת FreeRADIUS כדי לאשר את הבקר (או את הטווח שבו נמצאים המתגים/נקודתי הגישה) כלקוח RADIUS, תוך ציון כתובת ה-IP או רשת המשנה והסוד המשותף שנגדיר מאוחר יותר ב-Omada.

לאחר מכן, בחזרה ב-Omada, צור פרופיל RADIUS חיצוני מתוך הגדרות > פרופילים > פרופיל RADIUS , שם תזין את כתובת ה-IP של FreeRADIUS, את יציאת האימות (בדרך כלל 1812) ואת הסיסמה המשותפת. בהגדרות 802.1X של הבקר, בחר פרופיל חיצוני זה והפעל מחדש את VLAN Assignment , תוך סימון היציאות או ה-SSID שברצונך להגן עליהם.

ניתן לבצע אימות נוסף מהבקר עצמו: ב- Tools > Terminal , פתחו קונסולה מול המתג שבו מופעל 802.1X והפעילו את הפקודה show dot1x auth-state . אם הכל פועל כהלכה, תראו את הפורט המאומת ואת ה-VLAN שהוקצה על ידי RADIUS (לדוגמה, פורט 1/0/1 מאומת ומשויך ל-VLAN 2).

VLAN דינמי ב-Wi-Fi עם FreeRADIUS ו-ExtremeCloud IQ

דוגמה מקיפה נוספת היא זו של רשתות Wi-Fi המנוהלות על ידי ExtremeCloud IQ (XIQ) המשתמשות ב-FreeRADIUS כשרת האימות. כאן, ה-VLAN הדינמי מוקצה בעיקר ללקוחות Wi-Fi בהתבסס על מאפייני מנהרה המוחזרים על ידי FreeRADIUS.

ראשית, FreeRADIUS מוכן לשלוח את שלושת המאפיינים הללו בקובץ Access-Accept, בדיוק כמו קודם: ערכים בקובץ /etc/freeradius/3.0/users עם המשתמשים ורשתות ה-VLAN שלהם, וההגדרה בקובץ sites-enabled/default כך שמודול הקבצים יעובד לפני eap , מכיוון ש-XIQ מצפה למאפיינים בדיוק בקובץ Accept.

מומלץ מאוד להשבית את EAP-MD5 ולהשתמש בשיטות כגון PEAP/EAP-TLS . לאחר שינוי קובץ התצורה של EAP, הפעל מחדש את השירות באמצעות ` systemctl restart freeradius` כדי להחיל את השינויים. מאותו רגע ואילך, השרת יהיה מוכן להגיב לבקשות שנשלחו על ידי נקודות הגישה המנוהלות על ידי XIQ.

בצד הענן של Extreme, ישנם שני סוגי חשבונות רלוונטיים: חשבון Connect החינמי , המאפשר ניהול בסיסי של עד עשרה מכשירים אך אינו תומך בכללי סיווג מתקדמים עבור VLANs דינמיים, וגרסת Pilot , המציעה תקופת ניסיון של 90 יום ומאפשרת את כל מערך הפרופילים והכללים המבוססים על מאפייני RADIUS.

באמצעות חשבון הפיילוט, צור מדיניות רשת חדשה מתפריט "הגדרות > מדיניות רשת", תן לה שם ובחר "Wi-Fi בלבד" לשם פשטות. בשלב השני, הגדירו את ה-SSID, בדרך כלל כרשת ארגונית עם WPA2 או WPA3, ושייך קבוצת RADIUS . בעת יצירת קבוצה זו, הוסף את FreeRADIUS כשרת חיצוני, תוך ציון כתובת ה-IP, הסוד והיציאות 1812/1813 שלה.

לאחר מכן, מוגדרים פרופילי משתמש , שהם, בפועל, פרופילי גישה המקושרים לרשתות VLAN שונות (לדוגמה, VLAN10 ו-VLAN20). יש פרופיל ברירת מחדל שיוקצה ללקוחות שה-RADIUS שלהם אינו מחזיר תכונות מנהרה, אך עבור רשתות VLAN דינמיות, כללי הקצאה מוגדרים על סמך ערך Tunnel-Private-Group-ID ותכונות RADIUS אחרות.

הכללים קובעים בפשטות: "אם ה-Tunnel-Private-Group-ID שמגיע מה-Accept הוא 10, הקצה לפרופיל משתמש VLAN 10"; אם הוא 20, הקצה לפרופיל משתמש VLAN 20, וכן הלאה. ExtremeCloud IQ מתרגם את הכללים הללו בפועל להצבת הלקוח ב- VLAN התואם את התכונה שנשלחה מ-FreeRADIUS.

לבסוף, עליך להעניק גישה לרשתות VLAN אלו בצד הקווי של נקודת הגישה (AP) על ידי התאמת פרופיל נקודת הגישה ב-XIQ כך שיציאת ה-uplink תאפשר את כל רשתות ה-VLAN שתצורתן נקבעה ותשמור על ה-VLAN המקורי (בדרך כלל VLAN 1). לאחר שהכל נשמר ומדיניות הרשת מוחלת על נקודות הגישה, תוכל להשתמש בכלי בדיקת RADIUS המשולב ב-XIQ כדי לוודא ש-FreeRADIUS נגיש ושהשרת מחזיר את תכונת ה-VLAN הצפויה עבור כל משתמש.

Omada SDN עם ​​FreeRADIUS: רשתות VLAN עבור קווי ואלחוטי

פתרון ה-SDN של Omada מאפשר לך גם להקצות VLAN דינמיים בו זמנית ברשתות קוויות ואלחוטיות באמצעות RADIUS חיצוני כגון FreeRADIUS. זה מבטל את הצורך ליצור מספר SSIDs שונים או להשתמש ב-PVIDs סטטיים בפורטים של מתג.

הטופולוגיה האופיינית כוללת בקר Omada, נקודות גישה של EAP, מתגי JetStream ושרת FreeRADIUS הפועל על לינוקס. כדי לאפשר להתקני רשת לשלוח בקשות אימות לשרת, קובץ clients.conf נערך , ומגדיר את הלקוח לטווח הרשת של Omada (לדוגמה, 192.168.0.0/24) וסיסמה משותפת.

לאחר מכן, החשבונות מוגדרים בקובץ המשתמשים , תוך הגדרת, לדוגמה, שני משתמשים: אחד עבור VLAN10 ואחר עבור VLAN20, עם המאפיינים Tunnel-Type, Tunnel-Medium-Type ו-Tunnel-Private-Group-Id שלהם. ב-WPA-Enterprise, מקובל גם לשנות את קובץ התצורה של EAP כדי להתאים את השיטה לסוג הלקוחות (לדוגמה, EAP-PEAP עבור מחשבים ניידים של Windows).

מבקר Omada, במקטע האימות, צור פרופיל RADIUS המצביע אל FreeRADIUS ובחר באפשרות "הפעל הקצאת VLAN עבור רשת אלחוטית" . פעולה זו מבטיחה שכאשר לקוח מבצע אימות דרך WPA-Enterprise, Omada תבצע שאילתה לשרת RADIUS ותמקם את המכשיר ב-VLAN המוחזר על ידי השרת במקום ב-VLAN הסטטי של ה-SSID.

כמו כן, יש צורך להגדיר את ממשקי ה-VLAN של הרשת תחת הגדרות > רשתות קוויות > LAN , וליצור, לדוגמה, שני ממשקים לוגיים עבור VLAN10 ו-VLAN20 עם שערי ה-IP שלהם. בדרך זו, כאשר לקוח נמצא ב-VLAN10, הוא יקבל כתובת IP בטווח של אותו VLAN , והדבר חל גם על VLAN20.

בצד האלחוטי, נוצר SSID באמצעות WPA-Enterprise, ומצביע על פרופיל RADIUS. כאשר לקוח מתחבר ומאמת, לדוגמה, כ-test10, המשתמש יקבל כתובת IP מ-VLAN10; אם הוא משתמש ב-test20, הוא יוקצה ל-VLAN20, מבלי שנצטרך ליצור SSID ספציפי לכל מקרה.

בצד הקווי, הלוגיקה דומה אך משתמשת ב -802.1X Port-Based . 802.1X מופעל בחלק המתאים של הבקר, הסוג "Port-Based" נבחר, "VLAN Assignment" מופעל, והפורטים שידרשו אימות מסומנים. לאחר מכן מוחל פרופיל פורטים על אותם פורטים , תוך הוספת VLAN10 ו-VLAN20 כרשתות לא מתויגות, תוך הבטחה שמצב הבקרה של 802.1X מוגדר ל-"Auto" כך שהמתג יתחיל משא ומתן כאשר הוא מזהה לקוח.

לכן, עם תצורת RADIUS אחת וכמה פרופילים, Omada SDN מבטיח שמשתמשים קוויים ומשתמשי Wi-Fi כאחד יגיעו ל- VLAN המתאים להם בהתאם לאישורים שלהם , מבלי שיהיה צורך להכפיל רשתות או להתאים ידנית את התצורה של כל פורט.

דוגמאות מעשיות, טעויות נפוצות וטיפים להגדרה

עבודה עם FreeRADIUS ורשתות VLAN דינמיות אינה רק ורדים: מספר בעיות חוזרות ונשנות עולות בעת מעבר מבדיקות מעבדה לסביבות אמיתיות, במיוחד כאשר מתמודדים עם ספריות LDAP/AD, פורמטים של שמות משתמש ומדיניות מורכבת . לכן, ניהול סיכוני סייבר טוב מסייע בהפחתת אירועים.

תקלה אופיינית מאוד מתרחשת כאשר השרת בונה שאילתת LDAP באמצעות התכונה %{שם-משתמש} כשהוא מגיע ב-RADIUS. בתרחישי Windows רבים, הפורמט מגיע כ- DOMAIN\משתמש, כאשר הקו הנטוי ההפוך מקודד כ \5cאם תבנית LDAP בנויה עם uid=%{User-Name}השאילתה שתתקבל תהיה משהו כזה uid=DOMINIO\5cusuarioאשר לעיתים רחוקות תואם את ה-uid האמיתי בעץ LDAP, ומחזיר אפס תוצאות.

משמעות הדבר היא שתכונות המשתמש, כולל ערך ה-VLAN או הקבוצה שיש למפות, אינן נמצאות בספרייה. לכן, השרת אינו מוסיף את Tunnel-Private-Group-Id, והלקוח נשאר על ה-VLAN המוגדר כברירת מחדל של המתג או נקודת הגישה. דפוס זה נראה בבירור ביומני FreeRADIUS: שאילתת LDAP עם ה-uid "domain\5user" ופלט חיפוש ריק.

הפתרון המעשי שנעשה בו שימוש מוצלח הוא לשנות את השימוש ב -%{User-Name} ל -%{Stripped-User-Name} בתבנית שאילתת LDAP בתצורת FreeRADIUS, לדוגמה:

אם ("%{ldap:ldap:///dc=example,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }

בדרך זו, FreeRADIUS משתמש בשם המשתמש ה"נקי", ללא הדומיין או הקו הסלאש, והחיפושים שוב מצליחים. ברגע ש-LDAP מחזיר את הערך הנכון, השרת יכול להחיל את הלוגיקה כדי להקצות VLANs על סמך קבוצות, OUs או מאפיינים ספציפיים, וליצור שוב Tunnel-Type, Tunnel-Medium-Type ו-Tunnel-Private-Group-Id ב-Access-Accept.

מקרה מוזר נוסף מתרחש עם מתגים מסוימים כאשר תצורות VLAN סטטיות בפורט מעורבבות עם תצורות 802.1X דינמיות. לדוגמה, כאשר פורט 17 נמצא על VLAN סטטי 4 ובמקביל, ניסיון לאלץ את RADIUS להקצות משתמש ספציפי ל-VLAN 2. אם ההתקן אינו מכבד את מאפייני המנהרה או שפונקציית ה-VLAN הדינמית מושבתת, ללא קשר למה שקורה ב-RADIUS, הפורט ימשיך לראות תעבורה כ-VLAN 4.

במצבים אלה, חיוני לעיין בתיעוד של המתג כדי לאפשר במפורש תמיכה בהקצאת VLAN דרך RADIUS , ולבצע ניפוי באגים באמצעות פקודות כמו ` show dot1x` או מקביל, ולבדוק אם ההתקן מדווח על משהו כמו "התעלמות מתכונות מנהרה" או "הקצאת VLAN דינמית מושבתת". רק כאשר היצרן תומך בכך וזה מופעל, משתמש המחובר לפורט פיזי ב-VLAN 4 כברירת מחדל יגיע בסופו של דבר ל-VLAN 2 לאחר אימות כ-"carlos" או כל מי שלא יהיה.

ישנם גם ויכוחים קלאסיים לגבי התאמת השימוש ב- VLAN דינמיים בתרחישי שולחן עבודה מרוחק (RDP) . כאשר אימות מכונה מתרחש בעת הפעלת Windows ולאחר מכן אימות משתמש בעת הכניסה, שינוי ה-VLAN המופעל על ידי כניסת המשתמש יכול להפריע להפעלות RDP מתמשכות או לגרום לבעיות DNS כאשר הפורט עובר מ-VLAN של "המכונה" ל-VLAN של "המשתמש". מנהלים רבים בחרו לשמור על VLAN יחיד עבור כל המצבים במקרים אלה, או להקצות את אותו VLAN ברמת המכונה והמשתמש, ובכך למזער את שינויי הפלחים.

לבסוף, ברמת האינטגרציה המתקדמת, יש עניין גובר בקישור FreeRADIUS עם Azure AD כדי לקבוע VLANs על סמך חברות בקבוצה בענן. נכון לעכשיו, אין מודול רשמי מקורי שמבצע חיפושי קבוצות ישירים עבור VLANs ב-Azure AD, ופתרונות עוקפים כוללים סקריפטים חיצוניים, קריאות ל-Microsoft Graph API וכמה כוונון. זהו תחום דינמי, ואם נדרש פתרון יציב ונתמך, לוגיקה זו מועברת לעתים קרובות ל-NAC מסחרי או לרכיב מתווך אחר.

על ידי שילוב יעיל של 802.1X, FreeRADIUS והקצאת VLAN דינמית, ניתן להשיג פילוח רשת מדויק ללא צורך בפתרונות NAC מסורבלים. זה מתיישב בצורה מושלמת עם אסטרטגיית אבטחה טכנולוגית ארגונית חזקה : מבקרים כמו Omada או ExtremeCloud IQ ועד מתגים בטווח הביניים, הכל יכול לתרום אם מאפייני המנהרה מכובדים, שאילתות LDAP/AD מנוהלות בקפידה, וברור מתי להעביר משתמשים באופן דינמי מ-VLAN אחד לאחר בהתבסס על זהותם, תפקידם או סוג המכשיר שהם מתחברים אליו.