Задача управления компьютерной сетью является неотъемлемой, а во многих случаях и главной обязанностью сетевого инженера или администратора. На первый взгляд, что сложного в этой работе? С точки зрения рядового сотрудника она выглядит следующим образом: получив сообщение от пользователей сети о тех или иных неисправностях (например, недоступен Интернет, не подключается телефон к сети, «тормозит» RDP), сетевой инженер устраняет их. Такие работы могут быть охарактеризованы как реактивная поддержка.

К сожалению, для обслуживания крупной сети реактивный подход зачастую оказывается недостаточным. В какой-то момент количество сообщений о неисправностях начинает увеличиваться лавинообразно, что может вызвать отказ критичных сетевых сервисов. Поскольку компьютерная сеть является бизнес-критичным инструментом для любого современного предприятия, даже пятиминутный простой сети может привести к значительным убыткам, поэтому сетевой инженер должен исключить возможность возникновения подобных ситуаций.

Для предотвращения непредвиденного отказа следует применять комплексный и структурированный подход к управлению сетью, предусматривающий в числе прочего выполнение проактивных действий.

Итак, в общем случае задача управления компьютерной сетью может быть разделена на две составляющие:

  • структурированные работы — запланированные мероприятия по поддержке сети;
  • реактивные работы — действия по устранению выявленных неполадок.

Безусловно, в реальной сетевой инфраструктуре свести к нулю реактивные работы не представляется возможным, однако структурированный подход позволяет не только их минимизировать, но и более эффективно выявлять и устранять уязвимости в компьютерных сетях.

Для описания задачи поддержки ИТ-инфраструктуры в целом и сетевой инфраструктуры в частности существуют определенные модели (ITIL, FCAPS, TMN, Cisco Lifecycle Services). Такие модели можно использовать в качестве отправных точек при разработке структурированной схемы управления компьютерной сетью. Опыт показывает, что процедуры, описанные в стандартизованных моделях, во многих случаях избыточны. В данной статье мы дадим обзор наиболее важных, на наш взгляд, средств и инструментов управления, использование которых способно гарантировать надежное и предсказуемое функционирование компьютерной сети.

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

1.?Обеспечение доступа к сетевым устройствам для управления ими. Безусловно, инженер должен иметь возможность в любой момент подключиться к сетевому устройству, чтобы внести изменения в настройки или ознакомиться с телеметрической информацией. Основной инструмент для управления таким устройством — командная строка (CLI), однако сегодня почти всегда имеется удобный графический интерфейс (GUI). Вдобавок существует широкий спектр программного обеспечения, с помощью которого можно управлять сразу несколькими устройствами и/или технологиями.

Задача обеспечения доступа к сетевым устройствам нетривиальна, особенно в случае больших территориально распределенных сетевых инфраструктур. Управление может быть организовано по тем же каналам связи, по которым передается пользовательский трафик, по выделенным каналам или из облака. Следует отметить, что доступ к сетевым устройствам нужно обеспечить не только для инженера, но и для системы мониторинга. При этом крайне важно поддерживать надлежащий уровень безопасности.

2.?Мониторинг сетевой инфраструктуры. Этой достаточно объемной задаче мы уделим особое внимание. Мониторинг сетевой инфраструктуры можно разбить на следующие составляющие:

  • мониторинг сетевых устройств;
  • мониторинг каналов передачи данных.

В свою очередь, задача мониторинга сетевых устройств может быть разделена на три подзадачи:

  • сбор системных сообщений — журналов устройства;
  • мониторинг доступности и телеметрии сетевого устройства;
  • оповещение инженера об изменениях в сети.

Постоянный мониторинг сетевой инфраструктуры позволяет инженеру иметь всю необходимую информацию о сети в режиме реального времени, а также определять рабочий уровень (baseline) для параметров сетевых устройств и каналов передачи данных. Для различных инфраструктур границы допустимых значений параметров могут варьироваться. Например, для одной из них загрузка процессора маршрутизатора на периметре сети в нормальном режиме работы не превышает 10%, а в другой постоянная нагрузка аналогичного маршрутизатора составляет 30–40% и при этом все сервисы и бизнес-критичные приложения функционируют нормально. В таком случае указанные значения можно принять за показатель нормального режима работы сетевого устройства. Их превышение будет указывать на наличие аномалии в сети, а значит, и на риск возникновения проблем в функционировании сервисов и приложений. Тогда требуется оперативное вмешательство: поиск причины превышения допустимых показателей и ее устранение.

Как показывает опыт наших инженеров, мониторинг, выполняемый в рамках описанных выше задач, является необходимым и достаточным условием для того, чтобы сетевая инфраструктура работала на надлежащем уровне. При аккуратном соблюдении предложенных (и, в общем-то, несложных) пунктов, сетевой инженер сможет справиться практически с любой сетевой проблемой в сжатые сроки. А многие сетевые неполадки могут быть устранены проактивно.

Если учтены не все предложенные пункты, то рано или поздно окажется, что для решения очередной проблемы не хватает информации и необходимо экстренно добавлять недостающие средства мониторинга, что потребует дополнительного времени. Кроме того, даже после установки этих средств сетевой инженер не сможет достоверно интерпретировать новые данные, ведь у него не будет информации о том, как сеть работала раньше и какие показатели считать нормальными, а какие аномальными.

3.?Замена устаревшего или вышедшего из строя оборудования. С течением времени надежность сетевых устройств значительно снижается: устаревшее оборудование подвержено новым видам атак, поэтому и сетевая инфраструктура в целом становится уязвимой. Кроме того, с определенного времени устаревшее оборудование перестает отвечать постоянно возрастающим требованиям к функциональности и производительности. Таким образом, инженер должен иметь исчерпывающую информацию о моделях используемых сетевых устройств и при необходимости проводить замену оборудования на более современное.

4.?Обновление?программного обеспечения сетевых устройств. Производители сетевого оборудования постоянно разрабатывают новые версии операционных систем. Как правило, в них устраняются выявленные уязвимости, исправляются ошибки (баги) в коде, увеличивается производительность, а также добавляются новые функции.

5.?Резервное копирование конфигураций сетевых устройств. При отказе устройства с высокой долей вероятности теряется описание его конфигурации. Вышедшее из строя устройство необходимо заменить на аналогичное — с такими же настройками. Безусловно, эта задача значительно упрощается, если имеется резервная копия конфигурации.

На полезность наличия такой копии указывает еще один пример. Сетевой инженер вносит изменения в конфигурацию сетевого устройства, после чего перестает работать часть сервисов (возможно, бизнес-критичных). Такая ситуация может произойти как из-за неправильного действия (человеческий фактор), так и по вине производителя ПО (проявляется баг). Тем не менее работоспособность сервиса должна быть восстановлена в сжатые сроки. При наличии резервной копии конфигурации инженер может быстро осуществить процедуру отката, а затем выявить ошибку в новой конфигурации.

6.?Поддержка документации сетевой инфраструктуры. Как правило, первоначальная документация на сетевую инфраструктуру создается на этапах проектирования и внедрения, а в процессе эксплуатации вносятся многочисленные изменения в настройки устройств, в топологию сети и т. д. Отсутствие актуальной документации затрудняет как поддержку ее работы, так и устранение неисправностей, особенно если обслуживанием занимаются сразу несколько человек.

Далее мы рассмотрим наиболее интересные моменты из предложенных пунктов более подробно и представим примеры того, как те или иные инструменты помогают решать задачи управления.

ОБЕСПЕЧЕНИЕ ДОСТУПА К СЕТЕВЫМ УСТРОЙСТВАМ ДЛЯ УПРАВЛЕНИЯ ИМИ

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

Классические типы управления. Можно выделить несколько типов управления сетевым оборудованием. К наиболее часто описываемым методам относятся управление по основной сети (in-band) и по внешнему каналу (out-of-band). Кроме классического подхода, существуют и альтернативные варианты управления сетевым оборудованием. Например, на рынке представлены готовые решения, где управление устройствами происходит из облака. Конечно, такой метод можно было бы отнести к одному из двух уже названных, но в силу его гибридности и специфики имеет смысл выделить его в отдельный класс. Кроме того, не стоит забывать, что огромную популярность набирает концепция SDN (программно конфигурируемые сети). Итак, давайте разберемся, что собой представляет каждый тип.

Первый (in-band) предполагает передачу трафика управления оборудованием (Telnet, SSH, HTTPs и пр.) и трафика мониторинга (Syslog, SNMP, Netflow и пр.) через те же физические каналы и порты на сетевом оборудовании, через которые передается и обычный пользовательский трафик. Иначе говоря, одна и та же сеть обеспечивает передачу всех данных. Безусловно, при настройке оборудования необходимо на логическом уровне сегментировать трафик управления и остальной трафик. Это можно сделать при помощи виртуальных сетей (VLAN), списков доступа (ACL), межсетевых экранов и прочего. Но, как было отмечено, физическая инфраструктура остается той же.

Основной плюс такого решения — простота, но, как это обычно бывает, за простоту приходится платить. Дело в том, что в случае сбоя в сети (например, из-за большого паразитного трафика), доступ к устройствам может быть перекрыт, в результате чего затрудняются их диагностика и устранение неполадок. Чтобы этого не произошло, на сетевом оборудовании необходимо настроить разные уровни качества обслуживания трафика (QoS). Трафику управления и мониторинга следует предоставить приоритет, выделив минимально необходимую пропускную способность. Соответствующим образом промаркированный, он будет передаваться, даже если сеть перегружена. Однако данный подход не дает 100-процентной гарантии доступности и усложняет настройку оборудования. Кроме того, есть вероятность того, что по какой-то причине устройство автоматически заблокирует порт и удаленный доступ к нему пропадет (например, коммутатор Сisco может перевести порт в состояние err-disabled). В конце концов, бывают случаи, когда по ошибке блокируется порт, через который идет трафик управления, и тогда теряется доступ к самому устройству.

Второй тип управления (out-of-band) предполагает передачу трафика управления по отдельным физическим каналам связи, для чего строится вторая сеть, а на каждом сетевом устройстве выделяется отдельный порт для подключения к ней. Обычно устанавливается и отдельный коммутатор, к которому подключается вся инфраструктура управления (машина администратора, сервер Syslog, коллектор Netflow и прочее). В таком случае администратор сети практически всегда будет иметь доступ к сетевому оборудованию, даже если основная сеть полностью выйдет из строя.

Безусловно, основным недостатком является необходимость использования отдельного оборудования и выполнения дополнительных настроек. Кроме того, при подобной организации управления всегда требуются отдельные каналы связи. Когда оборудование находится в одной серверной, всегда можно найти дополнительные коммутационные шнуры, но если устройства размещены в разных частях здания или на территориально распределенных площадках, вопрос получения выделенных каналов становится критичным. Как это часто бывает, дополнительные медные или оптические трассы не предусмотрены изначально, проложить их весьма проблематично. Кроме того, на сетевом оборудовании должны иметься дополнительные порты для подключения к сети управления, но зачастую в маршрутизаторах есть всего два физических интерфейса, и обычно они уже заняты.

Что касается территориально распределенной сети, то организовать управление по внешнему каналу в удаленном офисе, особенно если его топология достаточно проста, оказывается сложно и дорого. Поэтому в такой ситуации применяется гибридный вариант управления: по внешнему каналу для центрального офиса и по основной сети для удаленных помещений. Точно такая же схема может быть использована, когда сеть состоит из нескольких сегментов, расположенных на разных этажах здания, а дополнительные межэтажные соединения отсутствуют.

Хотелось бы отметить еще один вариант управления сетью, который в большей степени можно отнести к внешнему управлению, — использование консольного сервера, к которому подключается каждое сетевое устройство. Несомненное преимущество данного варианта состоит в том, что, даже если устройство не смогло корректно загрузиться, доступ к нему будет обеспечен. Но использовать только этот вариант мешают несколько нюансов. Забегая вперед, хотелось бы отметить, что консольный сервер может и должен использоваться как дополнительный элемент в обеих схемах управления.

Основные ограничения заключаются в том, что к консольному серверу удобно подключать те устройства, которые находятся на небольшом удалении, то есть в одной серверной комнате с ним. Кроме того, консольное подключение непригодно для мониторинга сетевого оборудования. Еще один нюанс связан со скоростью передачи данных: вывод большого количества информации может занять достаточно продолжительное время — в нашей практике были случаи получасового ожидания.

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

АЛЬТЕРНАТИВНЫЕ ТИПЫ УПРАВЛЕНИЯ

Как уже говорилось, управление из облака представляет собой в некотором роде гибридный способ. Одним из примеров реализации управления сетевым оборудованием из облака является концепция, примененная в линейке продуктов Cisco Meraki. Все устройства этой марки (а в нее входят и коммутаторы, и устройства бе-

зопасности, и решения по построению беспроводной сети) после установки автоматически подключаются к облаку Cisco. Управление ими осуществляется через облачный портал. Главным недостатком данной схемы является то, что при потере связи с облаком управлять устройствами невозможно. Это существенно повышает требования к надежности и количеству интернет-каналов. Такой тип управления пока не приобрел популярности, но ввиду распространения облачных технологий ждать осталось недолго.

Концепция программно конфигурируемых сетей бурно развивается. Она предполагает полное отделение функций управления устройствами и контроля трафика от функций передачи данных. Иначе говоря, за управление всеми сетевыми устройствами и логику контроля за трафиком (протоколы маршрутизации, служебные протоколы, VLAN) будет отвечать некое централизованное программное устройство (контроллер), а сетевое оборудование — заниматься только передачей трафика. С одной стороны, преимущества подхода налицо: удобное управление всей сетью и очень гибкая функциональность (дополнительные функции реализуются программно). С другой стороны, сетевые устройства с поддержкой данной технологии только начинают появляться и их возможности пока невелики. Насколько перспективен такой подход, станет ясно в ближайшие годы.

КОРРЕКТНАЯ И БЕЗОПАСНАЯ НАСТРОЙКА СЕТЕВОГО ОБОРУДОВАНИЯ ДЛЯ УПРАВЛЕНИЯ

В идеале настройка сетевого оборудования для целей управления и мониторинга выполняется в соответствии с рекомендациями производителя: пароли должны иметь достаточную степень надежности, для удаленного подключения рекомендуются протоколы SSH и HTTPs, доступ к устройству необходимо ограничить. Список можно продолжить и дальше: корректная настройка каждого протокола управления, рекомендации по обеспечению качества обслуживания (QoS) и снятию телеметрии с оборудования и т. д.

Описание настройки всех этих параметров занимает не одну страницу, и их пересказ вряд ли интересен. Однако насколько все это нужно? Любой специалист, конечно же, подтвердит оправданность таких действий. Поэтому правильнее сформулировать вопрос по-другому: где та золотая середина между достаточным уровнем безопасной управляемости устройствами и нужной глубиной мониторинга и сложностью настройки сетевого оборудования? Ведь, наверное, нет смысла настраивать весь спектр функций при любом удобном случае. По крайней мере мы так не делаем. Безусловно, не стоит впадать и в ту крайность, когда на оборудовании даже не меняются имя и пароль, установленные по умолчанию, ведь доступ к такому устройству открыт из любой точки сети. Должен быть некий компромисс — так сказать, необходимое и достаточное.

Полагаем, каждый определяет этот минимум исходя из своего жизненного опыта. Один перестает оставлять открытыми все порты, после того как взламывают его оборудование. Другой начинает везде включать протоколирование, если оборудование внезапно вышло из строя, а из-за отсутствия журнальных записей понять причину не удалось. Поэтому отметим те особенности настройки управления, которые, на наш взгляд, наиболее важны.

Вот краткий перечень рекомендаций, который можно расширить или дополнить, обратившись к документации на оборудование:

  1. Для удаленного подключения рекомендуется использовать только защищенные протоколы, такие как SSH и HTTPs. Для проверки можно провести захват трафика подключения по протоколу Тelnet, и в этом трафике вы без труда найдете логин и пароль, передаваемые в открытом виде.
  2. На всех устройствах должны быть настроены имена и пароли с достаточной степенью надежности. Все учетные записи, заданные по умолчанию, следует удалить. Все пароли следует хранить в защищенном виде.
  3. Весь трафик мониторинга и управления, передаваемый по открытым каналам, должен быть зашифрован либо в рамках соединения VPN, либо с использованием защищенных протоколов (SNMPv3, sFTP, SCP).
  4. Доступ к устройствам должен иметь только определенный круг пользователей. Например, на оборудовании Cisco это можно сделать с помощью списков доступа (ACL).
  5. Необходимо настроить синхронизацию времени на устройствах. Это позволит более точно определять, когда осуществлялась попытка легитимного или нелегитимного подключения.
  6. Все подключения и вводимые команды рекомендуется протоколировать. Особенно это актуально, если управлением занимаются несколько человек.
  7. Каждый пользователь должен подключаться используя свою уникальную учетную запись.

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

Как было отмечено ранее, помимо рекомендаций, касающихся непосредственного управления устройствами, имеются рекомендации по безопасной настройке различных протоколов (например, EIGRP, OSPF и пр.), обеспечивающих работу сети. Например, целесообразно всегда включать протоколирование изменений состояния протокола (добавление/удаление маршрутов и пр.), а также аутентификацию между устройствами при установлении соседственных отношений.

Кроме того, есть целый набор рекомендаций по настройке качества обслуживания (QoS) трафика управления и мониторинга. Сюда же можно отнести вопросы фильтрации и ограничения скорости для того или иного протокола для предотвращения атаки с целью вызвать «отказ в обслуживании».

ПРОМЕЖУТОЧНЫЙ ИТОГ

Мы рассмотрели основные задачи, которые возникают при управлении сетью передачи данных, и выяснили, какие бывают парадигмы управления и как можно организовать безопасное управление сетевыми устройствами. В следующем номере большее внимание уделим целому ряду других вопросов: на что именно стоит обратить внимание при организации мониторинга и управления сетью, какие протоколы и средства мониторинга использовать для решения той или иной задачи, в чем заключаются преимущества комплексной системы управления и мониторинга сети и зачем необходимо заниматься документированием.

Сергей Калашников — технический директор компании «Компьютерные бизнес системы» (CBS), CCIE. С ним можно связаться по адресу: ksg@cbs.ru. Семен Моховиков — ведущий системный инженер компании «Компьютерные бизнес системы» (CBS). С ним можно связаться по адресу: msn@cbs.ru. Борис Усков — системный инженер компании «Компьютерные бизнес системы» (CBS). С ним можно связаться по адресу: uskov@cbs.ru.