Моніторинг мережевої інфраструктури

Відео: IOM3: оптимізація безпеки мережі і моніторингу

Повідомлення syslog і їх аналіз. Журнали подій служать для моніторингу та аналізу роботи всіх мережевих пристроїв, а так само фіксують його стан в будь-який проміжок часу. Будь-яка дія, так чи інакше пов`язане з мережевим обладнанням відбивається у вигляді записів в журналі (балках). Рівні деталізації таких записів різняться в залежності від цього виділяють три рівня логування. Для обладнання Cisco Systems передбачено вісім рівнів: від рівня про (Emergencies - повідомлення про непрацездатність системи) до рівня 7 (Debugging - налагоджувальні повідомлення).

Дане обладнання надає наступні можливості щодо виведення повідомлень: на консоль пристрої (console logging), в локальний буфер пристрої (buffer logging), в термінальну лінію (monitor logging) і на зовнішній мережевий накопичувач - виділений сервер syslog. В ролі останнього може виступати централізована система моніторингу. Таким чином дане обладнання може виявитися непоганою підмогою в пошуку різних проблем мережі. Саме тому так важливо не тільки замовити сайт (https://i-to.me/) у досвідчених виконавців, але і підшукати хостера, який використовує якісне обладнання в своїх мережах.

При включенні протоколювання потрібно бути вкрай уважним, оскільки ігнорування деяких нюансів може привести до відмови пристрою і / або необхідності його перезапуску.


Перша особливість стосується виведення на консоль або термінальну лінію повідомлень з високим рівнем деталізації, зокрема рівня 7. Перш за все мова йде про ситуацію, коли інженер активує додаткову трасування будь-якого сервісу командою debug. Оскільки мережний пристрій може генерувати занадто велика кількість повідомлень за одиницю часу, все ресурси процесора будуть спрямовані на виведення цих повідомлень на екран. В результаті пристрій може «зависнути» і перестати виконувати свою головну функцію - маршрутизировать і коммутировать мережевий трафік. Таким чином, при необхідності перегляду повідомлень високого рівня деталізації ми рекомендуємо виводити їх в локальний буфер.

Другий нюанс стосується виведення повідомлень в локальний буфер, який на мережевих пристроях Cisco виділяється із загального пулу оперативної пам`яті. Якщо для буфера повідомлень буде запитано зайняв велику кількість пам`яті, це також може привести до «зависання» пристрою і неза-планувальної перезавантаження.








Окремо варто виділити настройку протоколювання на міжмережевих екранах Cisco ASA. Розподіл повідомлень за рівнями для багатьох випадків не є оптимальним. Зокрема, повідомлення, пов`язані з роботою списків доступу (ACL) або з правилами трансляції IP-адрес (NAT), можуть відповідати рівням 2-6. Наприклад, якщо трафік підпадає під дію списку доступу, то в цьому випадку може генеруватися наступне повідомлення:

Таким чином, навіть якщо пристрій використовується нормальному режимі не виключена поява повідомлень високого рівня критичності. З урахуванням цього в операційній системі брандмауера Cisco ASA передбачені широкі можливості по налаштуванню і оптимізації протоколи-вання на пристрої. Зокрема, інженер може змінювати рівень будь-якого повідомлення, а також створювати списки системних повідомлень, об`єднуючи його цікавлять події в групи. Наприклад, для налагодження та моніторингу роботи сервісу VPN формується список, в який будуть потрапляти тільки ті повідомлення, які пов`язані з роботою даного сервісу, а на виділений сервер Syslog передаватиметься налаштований список. Крім того, пристрій Cisco ASA може відправляти списки повідомлень по електронній пошті.

Для будь-якого мережевого пристрою системні повідомлення є головним, а в деяких випадках і єдино доступним інструментом пошуку проблем і несправностей. Виконуючи діагностику мережевий проблеми, відразу після перевірки коректності конфігурації інженер повинен подивитися журнали подій мережевих пристроїв. Імовірність виявлення причини при аналізі системного журналу вкрай велика.

Системні повідомлення незамінні при розслідуванні непередбачуваних мережевих проблем. Ось простий приклад. Адміністратор періодично отримує від користувачів скарги на те, що протягом робочого дня три-чотири рази пропадає зв`язок між центральним офісом і віддаленим. Що робити в такій ситуації?

В першу чергу треба уточнити, коли саме це відбувалося, і подивитися журнали подій мережевих пристроїв в цікавлять тимчасові інтервали. Припустимо, із записів видно, що на всьому мережевому обладнанні центрального офісу зникає маршрут в віддалений офіс. Аналіз журналів обладнання цього офісу показує, що як раз в цікавлять нас інтервали часу на маршрутизаторі, до якого підключений канал до центрального офісу, з`являлося критичне повідомлення про брак оперативної пам`яті на пристрої і потім проводилася перезавантаження.

Таким чином, за записами в журналі ми змогли локалізувати проблему і зрозуміти причину її появи.

Крім вирішення мережевих проблем, хотілося б відзначити ще одну сферу застосування системних повідомлень. Їх можна використовувати спільно з вбудованим в операційну систему пристроїв Cisco редактором автоматичних сценаріїв Cisco Embedded Event Manager (EEM). Дана функціональність дозволяє створювати сценарії для автоматичної зміни конфігурацій пристроїв. Повідомлення про подію може виступати тригером запуску сценарію.