لب عملی: پیکربندی تفکیک با Scalable Group Tag (SGT)

این لب عملی Scalable Group Tag ها را به نقاط‌پایانی از طریق مجازسازی 802.1X اختصاص می‌دهد، یک سیاست دسترسی مبتنی‌بر-SGT مستقل از آدرس‌دهی IP پیکربندی می‌کند، و تأیید می‌کند ترافیک بر اساس صرفاً عضویت گروه به‌جای زیرشبکه یا VLAN مجاز یا رد می‌شود.

اختصاص Scalable Group Tagاعمال سیاست SGACLتفکیک مبتنی‌بر-هویت

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

هدف لب

پیکربندی دو نقطه‌پایانی برای دریافت Scalable Group Tag های متفاوت هنگام احراز هویت 802.1X، تعریف یک ACL امنیتی گروهی که ترافیک از یک گروه به یک گروه مقصد خاص را رد می‌کند، و تأیید اینکه اعمال بر اساس عضویت گروه رخ می‌دهد حتی وقتی هر دو نقطه‌پایانی همان زیرشبکه را به اشتراک می‌گذارند.

هدف لب (چرا مهم است)

VACL ها و ایزوله‌سازی مبتنی‌بر-VLAN پوشش‌داده‌شده پیش‌تر در این مجموعه ترافیک را بر اساس توپولوژی شبکه تفکیک می‌کنند — اینکه یک دستگاه در کدام VLAN یا زیرشبکه قرار دارد. SGT ها تفکیک را کاملاً از توپولوژی شبکه جدا می‌کنند، و ترافیک را بر اساس هویت احراز‌هویت‌شده دستگاه یا کاربر تگ‌گذاری می‌کنند، و اجازه می‌دهند سیاست یک نقطه‌پایانی را حتی وقتی بین مکان‌های فیزیکی یا زیرشبکه‌های متفاوت حرکت می‌کند دنبال کند.

توپولوژی لب

Switch1 (لبه fabric)
  Gi1/0/1 ---- Employee-PC (احراز هویت از
               طریق 802.1X، RADIUS SGT 10
               "Employees" را اختصاص می‌دهد)
  Gi1/0/2 ---- Guest-PC (احراز هویت از طریق
               802.1X، RADIUS SGT 20
               "Guests" را اختصاص می‌دهد)

هر دو PC همان زیرشبکه/VLAN را به اشتراک
می‌گذارند -- تفکیک باید کاملاً از سیاست SGT
بیاید، نه جداسازی VLAN

وظیفه ۱: تأیید دریافت SGT های اختصاص‌یافته توسط هر دو نقطه‌پایانی

تأیید کن سرور RADIUS SGT 10 را به Employee-PC و SGT 20 را به Guest-PC هنگام احراز هویت موفق 802.1X اختصاص می‌دهد.

وظیفه ۲: تأیید اتصال خط‌مبنا بدون یک SGACL

تأیید کن هر دو PC در حال حاضر می‌توانند به یک سرور مشترک برسند، چون هنوز هیچ محدودیت مبتنی‌بر-SGT‌ای وجود ندارد.

وظیفه ۳: تعریف یک ACL امنیتی گروهی که دسترسی Guest-به-Server را رد می‌کند

یک SGACL بساز که ترافیک را به‌طور خاص از SGT 20 (Guests) به SGT سرور مشترک رد می‌کند.

وظیفه ۴: اعمال SGACL بین جفت گروه مرتبط

ورودی ماتریس سیاست را طوری پیکربندی کن که این SGACL را روی ترافیک از SGT 20 به‌سمت SGT سرور اعمال کند.

وظیفه ۵: تأیید اعمال بر اساس گروه، نه زیرشبکه

تأیید کن Guest-PC اکنون از سرور مسدود شده در حالی که Employee-PC، روی زیرشبکه یکسان، همچنان مجاز باقی می‌ماند.

راه‌حل و تأیید

Switch1# show authentication sessions interface gigabitethernet1/0/1 details | include SGT
SGT: 0010-10 (Employees)

Switch1# show authentication sessions interface gigabitethernet1/0/2 details | include SGT
SGT: 0020-10 (Guests)
-- هر دو نقطه‌پایانی SGT خودشان را به‌طور پویا
-- از RADIUS به‌عنوان بخشی از احراز هویت
-- 802.1X، پیش‌تر در این مجموعه بحث شد،
-- دریافت کردند، با وجود اشتراک‌گذاری همان
-- VLAN فیزیکی

Guest-PC> ping SharedServer
Reply from SharedServer...
-- در حال حاضر مجاز -- هیچ سیاست SGACL‌ای هنوز
-- برای محدودکردن این وجود ندارد

Switch1(config)# cts role-based sgt-map SharedServer-address sgt 30
Switch1(config)# ip access-list role-based DENY-GUESTS
Switch1(config-rb-acl)# deny ip
Switch1(config-rb-acl)# exit
Switch1(config)# cts role-based permissions from 20 to 30 DENY-GUESTS

-- این یک عبارت سیاست واحد ترافیک را صرفاً با
-- جفت SGT (20 به 30) تطبیق می‌دهد -- هیچ
-- زیرشبکه IP، VLAN، یا اینترفیسی در هیچ‌کجای
-- این قانون ارجاع نشده

Switch1# show cts role-based permissions

From SGT: 20 (Guests)
To SGT: 30 (Servers)
  DENY-GUESTS
-- سیاست تأیید‌شده فعال برای این جفت گروه خاص

Guest-PC> ping SharedServer

Request timed out.
Success rate is 0 percent (0/5)
-- Guest-PC، تگ‌گذاری‌شده SGT 20، اکنون مسدود
-- است

Employee-PC> ping SharedServer

Reply from SharedServer...
!!!!!
Success rate is 100 percent (5/5)
-- Employee-PC، تگ‌گذاری‌شده SGT 10، کاملاً
-- مجاز باقی می‌ماند -- با وجود اینکه هر دو PC
-- روی دقیقاً همان زیرشبکه و VLAN هستند،
-- اعمال کاملاً بر اساس هویت گروه احراز‌هویت‌شده‌شان
-- متفاوت است

نکته کلیدی

اعمال سیاست مبتنی‌بر-SGT در یک لایه کاملاً بالاتر از آدرس‌دهی IP و عضویت VLAN عمل می‌کند — همان ماتریس سیاست با یک دستگاه یا کاربر صرف‌نظر از اینکه از میان کدام پورت فیزیکی، VLAN، یا زیرشبکه متصل می‌شوند سفر می‌کند، چون تگ به‌طور پویا در احراز هویت اختصاص می‌یابد به‌جای استخراج‌شدن از مکان شبکه، یک تغییر بنیادین از رویکردهای تفکیک مبتنی‌بر-VLAN و زیرشبکه پوشش‌داده‌شده در سراسر بیشتر این مجموعه.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

لب عملی: پیکربندی مسیریابی Stub در EIGRP

این لب عملی یک روتر شعبه را به‌عنوان یک stub در EIGRP پیکربندی می‌کند، و تأیید می‌کند فقط مسیرهای متصل و خلاصه خودش را تبلیغ می‌کند در حالی که روتر hub به‌درستی از پرس‌وجوکردن stub در طول یک تغییر توپولوژی در جای دیگری از شبکه اجتناب می‌کند.

ادامه

لب عملی: پیکربندی حالت Named در EIGRP

این لب عملی یک پیکربندی EIGRP کلاسیک موجود را به حالت named EIGRP بازپیکربندی می‌کند، و عبارات network و پیکربندی خاص-اینترفیس را در یک سلسله‌مراتب address-family ساختاریافته‌تر سازمان‌دهی می‌کند، و تعادل عملکردی با سبک پیکربندی کلاسیک استفاده‌شده در سراسر لب‌های EIGRP قبلی این مجموعه را تأیید می‌کند.

ادامه

لب عملی: پیکربندی ERSPAN در سراسر یک شبکه مسیریابی‌شده

این لب عملی Encapsulated RSPAN (ERSPAN) را برای آینه‌کردن ترافیک در سراسر یک شبکه مسیریابی‌شده-لایه-۳ به‌جای یک ترانک لایه ۲ واحد پیکربندی می‌کند، و مفهوم RSPAN از لب قبلی را فراتر از مرزهای یک VLAN یا دامنه سوئیچ‌شده واحد گسترش می‌دهد.

ادامه

لب عملی: پیکربندی RSPAN در سراسر سوئیچ‌ها

این لب عملی Remote SPAN (RSPAN) را با استفاده از یک VLAN RSPAN اختصاصی حمل‌شده در سراسر یک ترانک پیکربندی می‌کند، و اجازه می‌دهد ترافیک آینه‌شده روی یک سوئیچ توسط یک دستگاه گرفتن متصل به یک سوئیچ کاملاً متفاوت نظارت شود، و مفهوم SPAN محلی پوشش‌داده‌شده در یک لب قبلی را در سراسر شبکه گسترش می‌دهد.

ادامه

لب عملی: پیکربندی In-Service Software Upgrade (ISSU) روی یک Stack

این لب عملی یک In-Service Software Upgrade را در سراسر یک stack StackWise انجام می‌دهد، و ایمیج IOS هر عضو را یکی‌یکی ارتقا می‌دهد در حالی که stack در سراسر آن به فوروارد‌کردن ترافیک ادامه می‌دهد، و صفر خرابی را در مقایسه با رویکرد مخل reload استفاده‌شده در لب‌های ارتقای IOS قبلی تأیید می‌کند.

ادامه

لب عملی: پیکربندی Stacking سنتی StackWise در Catalyst

این لب عملی stacking سنتی Catalyst (StackWise) را در سراسر سه سوئیچ با استفاده از کابل‌های stack پیکربندی می‌کند، و نیازمندی تک-لایه و مجاورت فیزیکی‌اش را با جفت StackWise Virtual پوشش‌داده‌شده در لب قبلی که اجازه می‌دهد سوئیچ‌ها بسیار دورتر از هم قرار بگیرند مقایسه می‌کند.

ادامه