На главную
  Москва 787-48-84
  С-Петербург 718-55-05
  Новосибирск 218-41-03
  Екатеринбург 378-70-50


Забыли пароль
Регистрация

Наши вендоры
3COM
Axis Communications
Allied Telesis
Belden
CISCO
DIGI International
D-link
EADS
Enterasys
Inelt
H3C
Lexmark
Linksys
Maxilan
MK
Molex PN
Netgear
Nortel (Data)
Nortel (Voice)
OKI
Rittal
SCO Group
TRENDnet
VIVOTEK
ZyXEL
 
 
  Новости   О компании   Для партнеров   Поддержка   Контакты   Поиск

Безопасный удаленный доступ к консолям оборудования. Часть 1.


Часть 1   Часть 2   Часть 3

История вопроса.

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

Последовательные консоли были и остаются атрибутами Intel - RISC -серверов, коммутаторов, маршрутизаторов, устройств VPN , офисных АТС и источников бесперебойного питания. Секрет консольного доступа заключается в его простоте, широком распространении и универсальности. Можно возразить, что необходимость встроенной консоли становится со временем менее актуальной и производители встраивают в свои продукты графические интерфейсы администрирования, доступные в любой точке сети через стандартный Web -браузер. Да, так оно и есть, но, рекламируя средства визуализации, производители часто умалчивают о том, что не все функции доступны в этом режиме. Что же мешает им в этом благородном деле?

Ответ, в общем-то, прост. Наделяя свои устройства избыточными, с точки зрения их основного назначения, средствами визуализации, производителям приходится увеличивать размеры микроядра управляющего ПО. Это, в свою очередь, снижает надежность этого самого ПО и чем больше оно поддерживает графических возможностей, тем больше объем кода и тем больше вероятность сбоя. Даром ничего не дается. Достаточно вспомнить пример перехода со старой доброй ОС MS DOS на Windows 2.0 или 3.1 и какую дань нам приходится платить до сегодняшнего дня за удобства графического интерфейса Microsoft Windows . Кроме того, увеличение ПО и его функциональности снижает общую производительность устройств, что вынуждает использовать более мощные процессоры и увеличивать объем оперативной и флэш-памяти. В конечном итоге, все это приводит к увеличению стоимости устройств, что не может устроить ни потребителей, ни поставщиков условиях всеобщей ценовой конкуренции.

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

История выбора.

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

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

Как известно, всегда хочется иметь нечто такое, что идеально подходило бы для конкретной задачи, а не то, что в принципе может решить проблему. Распространенным решением является использование маршрутизаторов Cisco 25хх-ой серии, которые в целом неплохо справляются с задачами терминального доступа. Но это устаревшее оборудование с максимальной плотностью 16 асинхронных портов на 1 U , которое по сообщениям производителя уже давно должно быть снято производства. Устройства 26-ой серии позволяют достичь нужной плотности портов, но дешевым это решение уже назвать трудно.

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

После тестирования нескольких устройств, выбор пал на консольный сервер PortServer CM 32, который в ходе экспресс-тестирования удовлетворил большую часть наших требований и ожиданий. Спустя три месяца, было решено приобрести один сервер и приступить к его полномасштабным испытаниям в условиях максимально приближенных к боевым.

История внедрения.

При покупке нас ожидал настоящий сюрприз: поставщик прекратил производство, так понравившегося нам консольного сервера, а вместо него предлагалась новая модель – Digi CM 32 (с 32-мя серийными портами) и по более привлекательной цене. Внешний дизайн устройства не претерпел значительных изменений, зато на передней панели появился слот для установки карт формата PCMCIA . В перечень поддерживаемых карт входили флэш-карты, карты беспроводного доступа, модемы и сетевые карты. Эта опция показалась нам весьма полезной, поскольку позволяла создавать дополнительное соединение при построении резервной сети управления. Кроме того, теперь имелся выбор из 8-ми, 16-ти, 32-х и 48-ми портовых моделей.

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

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

Итак, создание тестовой зоны мы решили начать с установки консольного концентратора, пары серверов, коммутатора и маршрутизатора, обеспечивающего подключение всего этого хозяйства к корпоративной сети. Все консольные кабели были подключены к консольному серверу Digi CM , кроме консоли самого Digi , которая была подключена к консольному концентратору технологической площадки - Cisco 26 xx . Проблем с подключением не возникло, в сопроводительной документации есть схемы всех необходимых разводок. Для подключения консолей всех устройств использовалась стандартная кабельная разводка – обычные патч-корды 5-й категории и переходники-конструкторы RJ -45 – DB -9/ DB -25, которые очень рекомендую. Переходники надо заказывать отдельно бандлами по 8 штук, но они перекрывают практически все варианты консолей DB -9, DB -25, male и female .

Начальная конфигурация Digi осуществлялась через консоль. После конфигурации сетевого интерфейса мы перешли на web -интерфейс, поскольку поддерживается и HTTP , и HTTPS . Меню простые и достаточно удобные, так что, если тонкая настройка не требуется, использовать CLI для управления концентратором не обязательно. Вообще, поставляемое с Digi ПО, удовлетворяет большинству стандартных запросов, так что лезть в устройство Shell 'ом может потребоваться только в специфичных случаях. Поэтому вам не придется изучать систему команд еще одного устройства только для того, чтобы добраться до консольных портов своего оборудования. Для любителей покрутить труднодоступные ручки намекну, что внутри живет сильно обрезанный Linux ( Hard Hat Distribution).

Начальная настройка устройства тоже не заняла много времени. Поменяли пароли предопределенных пользователей, выбрали настройки доступа к консолям: кроме параметров порта, можно выбрать протокол доступа к концентратору – мы выбрали SSH , включить port logging и даже настроить Digi на анализ сообщений с консоли устройства, установить фильтры доступа к консоли по IP -адресу и имени пользователя и много чего еще. Затем выделили порт и IP -адрес для каждой консоли и добавили нескольких новых пользователей.

Часть 1   Часть 2   Часть 3

Загрузить всю статью в формате MS-Word можно здесь.

Часть 1   Часть 2   Часть 3

Загрузить всю статью в формате MS-Word можно здесь.