لب عملی: پیکربندی احراز هویت NTP

این لب عملی احراز هویت MD5 را به پیکربندی NTP پوشش‌داده‌شده در یک لب قبلی اضافه می‌کند، و تأیید می‌کند یک کلاینت فقط با سروری که کلید احراز هویت درست را ارائه می‌دهد همگام‌سازی می‌کند و به‌روزرسانی‌های زمان از یک منبع احراز‌هویت‌نشده یا نامنطبق را رد می‌کند.

احراز هویت MD5 در NTPپیکربندی کلید Trustedرد‌کردن منابع زمان احراز‌هویت‌نشده

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

هدف لب

پیکربندی احراز هویت NTP هم روی سرور و هم کلاینت از لب NTP قبلی، تأیید اینکه کلاینت فقط همگام‌سازی زمان از یک سرور که کلید احراز هویت منطبق را ارائه می‌دهد می‌پذیرد، و تأیید اینکه یک منبع NTP احراز‌هویت‌نشده یا نامنطبق کاملاً رد می‌شود.

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

لب پایه NTP پوشش‌داده‌شده پیش‌تر در این مجموعه همگام‌سازی را بدون هیچ احراز هویتی برقرار کرد — هر دستگاهی که ادعا کند آدرس سرور پیکربندی‌شده است بالقوه می‌توانست اطلاعات زمان نادرست به یک کلاینت بدهد، با پیامدهایی برای دقت لاگینگ و تأیید گواهینامه بحث‌شده در جای دیگری از این مجموعه. احراز هویت NTP تضمین می‌کند یک کلاینت فقط به‌روزرسانی‌های زمان اثبات‌شده-رمزنگاری-شده از سرور مورد نظر را اعتماد می‌کند.

توپولوژی لب

R1 (سرور NTP) ---- Serial0/0/0 ------ Serial0/0/0 ---- R2 (کلاینت NTP)

همان توپولوژی لب NTP قبلی، اکنون با احراز
هویت اضافه‌شده

وظیفه ۱: پیکربندی یک کلید احراز هویت روی سرور

R1 را با یک کلید احراز هویت NTP پیکربندی کن و آن را به‌عنوان trusted علامت‌گذاری کن.

وظیفه ۲: پیکربندی کلید منطبق روی کلاینت

R2 را با همان کلید یکسان، همچنین به‌عنوان trusted علامت‌گذاری‌شده، پیکربندی کن، و احراز هویت NTP را فعال کن.

وظیفه ۳: به‌روزرسانی ارجاع سرور برای نیازمندی احراز هویت

عبارت ntp server R2 را برای ارجاع به کلید احراز هویت به‌روزرسانی کن.

وظیفه ۴: تأیید موفقیت همگام‌سازی احراز‌هویت‌شده

تأیید کن R2 با موفقیت با پیکربندی کلید احراز‌هویت‌شده همگام‌سازی می‌شود.

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

مقدار کلید R2 را به یک مقدار نامنطبق تغییر بده و تأیید کن R2 دیگر R1 را به‌عنوان یک منبع زمان معتبر اعتماد نمی‌کند.

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

R1(config)# ntp authentication-key 1 md5 NtpSecure2026
R1(config)# ntp trusted-key 1
R1(config)# ntp authenticate

-- "ntp authenticate" به‌طور سراسری بررسی
-- احراز هویت را فعال می‌کند -- بدون این
-- دستور، کلیدهای پیکربندی‌شده وجود دارند اما
-- هرگز واقعاً اعمال نمی‌شوند

R2(config)# ntp authentication-key 1 md5 NtpSecure2026
R2(config)# ntp trusted-key 1
R2(config)# ntp authenticate

R2(config)# no ntp server 10.15.15.1
R2(config)# ntp server 10.15.15.1 key 1

-- افزودن مجدد عبارت server با عبارت "key 1" --
-- بدون این، R2 همچنان تلاش می‌کرد NTP
-- احراز‌هویت‌نشده انجام دهد، و کاملاً
-- پیکربندی trusted-key را برای این سرور خاص
-- نادیده می‌گرفت

R2# show ntp associations

address         ref clock    st  when  poll  reach  delay  offset
*~10.15.15.1     127.127.1.1   3    8     64    17   4.1    0.234
-- ستاره تأیید می‌کند R2 R1 را به‌عنوان منبع
-- زمان مورداعتماد و احراز‌هویت‌شده‌اش انتخاب
-- کرده و با آن همگام است

R2# show ntp status

Clock is synchronized, stratum 4
-- همگام‌سازی موفق و احراز‌هویت‌شده

R2(config)# ntp authentication-key 1 md5 WrongKey999

-- عدم‌تطابق کلید معرفی شد -- R1 همچنان از
-- "NtpSecure2026" استفاده می‌کند

R2# show ntp associations

address         ref clock    st  when  poll  reach  delay  offset
 10.15.15.1     127.127.1.1   3   64     64    0    4.1    0.234
-- بدون ستاره -- R2 دیگر این منبع را اعتماد
-- نمی‌کند، چون بررسی احراز هویت اکنون روی هر
-- بسته دریافتی شکست می‌خورد

R2# show ntp status

Clock is unsynchronized, stratum 16
-- Stratum 16 قرارداد NTP برای "همگام‌نشده" است
-- -- R2 به ساعت آزاد-اجرای خودش بازگشته
-- به‌جای پذیرفتن به‌روزرسانی‌های زمانی که
-- نمی‌تواند تأیید کند

نکته کلیدی

احراز هویت NTP نیازمند سه قطعه جداگانه است که با هم کار می‌کنند: یک کلید منطبق تعریف‌شده روی هر دو سمت، آن کلید صراحتاً به‌عنوان trusted با ntp trusted-key علامت‌گذاری‌شده، و دستور سراسری ntp authenticate که واقعاً اعمال را فعال می‌کند — رد‌کردن هرکدام از این سه NTP را یا احراز‌هویت‌نشده یا، بدتر، بی‌سروصدا نادرست‌پیکربندی‌شده به شیوه‌ای که در running-config درست به‌نظر می‌رسد اما هرگز واقعاً به‌روزرسانی‌های زمان دریافتی را تأیید نمی‌کند باقی می‌گذارد.

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

مقالات مرتبط

لب عملی: چالش عیب‌یابی جامع نهایی CCNP (یکپارچگی BGP، DMVPN، و QoS)

این لب عملی یک شکست پیچیده چندلایه در سراسر یک توپولوژی یکپارچه BGP-روی-DMVPN ترکیب‌شده با علامت‌گذاری QoS ارائه می‌دهد، و نیازمند تشخیص سیستماتیک یک پیکربندی نادرست route reflector، یک شکست ثبت NHRP، و یک سیاست QoS نادرست‌اعمال‌شده که هم‌زمان روی همان شبکه تأثیر می‌گذارند است.

ادامه

لب عملی: پیکربندی BGP روی DMVPN

این لب عملی iBGP را به‌عنوان پروتکل مسیریابی در سراسر همان توپولوژی hub-and-spoke DMVPN استفاده‌شده در دو لب قبلی اجرا می‌کند، hub را به‌عنوان یک route reflector BGP پیکربندی می‌کند طوری‌که spoke ها مسیرهای یکدیگر را بدون یک mesh کامل iBGP یاد بگیرند، و دو مفهوم قبلاً جداگانه را در یک طراحی یکپارچه ترکیب می‌کند.

ادامه

لب عملی: پیکربندی OSPF روی DMVPN

این لب عملی OSPF را به‌عنوان پروتکل مسیریابی پویا در سراسر همان توپولوژی hub-and-spoke DMVPN اجرا می‌کند، و اینترفیس تونل را به‌عنوان یک نوع شبکه OSPF point-to-multipoint پیکربندی می‌کند تا الگوی همسایگی hub-and-spoke را به‌درستی بدون نیاز به انتخاب DR/BDR نوع شبکه broadcast مدیریت کند.

ادامه

لب عملی: پیکربندی EIGRP روی DMVPN

این لب عملی EIGRP را به‌عنوان پروتکل مسیریابی پویا در سراسر توپولوژی hub-and-spoke DMVPN ساخته‌شده در لب‌های قبلی اجرا می‌کند، و تأیید می‌کند روابط همسایه به‌درستی در سراسر تونل چندنقطه‌ای شکل می‌گیرند و مسیرها بدون نیاز به پیکربندی ایستای هر-spoke روی hub منتشر می‌شوند.

ادامه

لب عملی: پیکربندی احراز هویت MD5 در HSRP

این لب عملی احراز هویت MD5 را روی یک گروه HSRP پیکربندی می‌کند، و تأیید می‌کند دو روتر با رشته‌های احراز هویت منطبق یک رابطه active/standby معمولی تشکیل می‌دهند در حالی که یک روتر با رشته نامنطبق کاملاً از گروه مستثنی می‌شود.

ادامه

لب عملی: پیکربندی امنیت DNS به‌سبک-Cisco Umbrella از طریق تغییرمسیر Forwarding DNS

این لب عملی یک روتر را برای رهگیری هر پرس‌وجوی DNS کلاینت و تغییرمسیر آن به‌سمت یک resolver DNS امنیت-محور با استفاده از رهگیری forwarding DNS پیکربندی می‌کند، و اعمال امنیت DNS تحویل‌شده-با-ابر را بدون نیاز به تغییرات پیکربندی به‌ازای-هر-کلاینت تقریب می‌زند.

ادامه