Современные средние и тем более крупные локальные сети по разным причинам всё более нуждаются в наличии специализированных средств сетевого управления - маршрутизаторов и коммутаторов. Одной из особых причин этого является необходимость оперативного отключения от сети [1] ПК с некорректными настройками, завирусованных или пораженных иными вредоносными программами, мешающими работе сети.
В этих целях актуально наличие и развитие программных средств, допускающих автоматизированную работу по заранее определенным алгоритмам, либо полуавтоматическое управление сетевыми управляющими устройствами малоквалифицированным пользователем по опять-таки заранее предопределенным шаблонам.
Однако, разнообразные имеющиеся средства управления сетевыми коммутаторами (далее для единообразия будет идти речь именно о них, хотя те же рассуждения актуальны и для иных устройств сетевого управления), интенсивно развиваясь в методах их управления, были и остаются самостоятельным замкнутым классом устройств. Интенсивное развитие GUI-ориентированных методов, от «Web Console» и «Visual Switch Manager» до «Cluster Management Suite», и «Cisco Works», по-прежнему предполагает привлечение высококвалифицированных специалистов для любых операций. Между тем, большинство конкретных действий по управлению коммутаторами, представляется, может быть сведено к нескольким типовым схемам, управление которыми может осуществляться специалистом средней квалификации по заранее разработанным шаблонам.
Таким образом, актуальной становится проблема автоматизации управления сетевыми коммутаторами. Для ее решения впервые предлагается создать специализированные средства полуавтоматического управления, действующие по заранее разработанным шаблонам.
Решение указанной проблемы должно базироваться на создании программных средств взаимодействия с сетевыми коммутаторами. Центральным вопросом создания этих средств является выбор актуального сетевого протокола. В данной работе исследуется попытка создания подобных средств на базе сетевого протокола Telnet.
Выбор Telnet для создания средств полуавтоматического управления сетевыми коммутаторами является не случайным: он стал де-факто стандартным протоколом дистанционного управления сетевыми устройствами. Так, даже в современных продуктах серии Cisco, маршрутизаторах и коммутаторах различного назначения, несмотря на интенсивное развитие GUI-ориентированных программных средств, Telnet с его крайне отсталой командной строкой включен во все базовые операционные средства.
Казалось бы, при таком уверенном месте, занимаемым этим протоколом, рынок программных приложений должен изобиловать средствами, реализующими большинство его компонент на уровне DLL-библиотек. Давно назревшая необходимость интеграции процессов управления коммутаторами в общую технологичную среду управления локальными сетями должна была бы привести к достаточному выбору автоматизированных управляемых программных средств, предназначенных для включения в конструируемую среду управления сетью. Однако, по нашему мнению, этого до сих пор не произошло. Рынок предлагает разнообразные реализации протокола, являющиеся законченным программным продуктом, не допускающим ни настройки на актуальный список управляемых сетевых устройств, ни автоматизации в наборе длинных и труднозапоминаемых команд управления этими устройствами. Даже речи нет о какой-либо автоматизации действий пользователя: не предлагается предварительно создаваемых шаблонов, выделенных групп команд, макросредств и т.д.
Такая отсталость в средствах автоматизации типового сетевого протокола управления тем более странна, что большинством потребителей Telnet являются системные сетевые администраторы - лица высокой квалификации, либо сами являющиеся программистами, либо имеющие тесные связи с таковыми.
Под полуавтоматическими программными средствами управления сетевыми коммутаторами автором понимается программный модуль, взаимодействующий в сеансах связи с управляемым устройством. После команды, - пользователя или из шаблона, - запущенное программное средство в очередном сеансе связи должно выполнить заранее определенный специально разработанный сценарий, возможно, с некоторыми параметрами (MAC-адресом сетевого устройства, номером порта и др.). Предполагается обеспечить возможность автоматизированного контроля за ходом исполнения, хотя бы методом проверки ответных реплик. Выходом программы должно являться новое состояние коммутатора и бинарный индикатор успешности завершения заданного сценария. В связи с особой важностью для состояния сети процессов управления сетевым коммутатором, весь ход исполнения сценария должен быть сохранен в виде читабельного текстового протокола.
Несмотря на кажущуюся простоту, протоколу Telnet среди серии протоколов TCP/IP посвящено, пожалуй, едва ли не наибольшее число RFC-документов [2-44, приведены только актуальные документы]. Вероятно, это объясняется бурным развитием актуального протокола сетевого управления.
Протокол Telnet представляет собой имитацию «сетевого телетайпа», включающего устройства посимвольного ввода и построчного вывода. В процессе управления характерен посимвольный обмен между управляющим «сетевым телетайпом» и управляемым устройством. Вводимая команда завершается стандартным концом строки. Ответным действием управляемого устройства может быть высылка одной или более текстовых строк. В специальных случаях подаются дополнительные сигналы, например при превышении определенного числа выведенных строк далее выводится мерцающий текст “-- More--” и ожидается реакция управления.
В конкретных реализациях протокола обязательно присутствуют также служебные команды как последовательности спецсимволов, включенных в произвольное место основного текстового обмена данными. Эти последовательности принято называть опциями протокола. Одна из принципиальных трудностей реализации состоит в определении широты реализованных опций в конкретных версиях Telnet, “зашитых” в действующую IOS коммутатора. Разумеется, никакой информации по этому вопросу в обширной документации сопровождения сетевых коммутаторов не имеется. Неясна полнота реализации протокола, не указаны конкретные типы имитируемых терминалов, не описан список поддерживаемых опций.
Для исследования всех этих вопросов были проведены эксперименты на реальном современном сетевом коммутаторе Cisco Catalyst-2935 с IOS 12.1 с задействованием разработанных ранее средств сетевого мониторинга [45]. В сеансах связи стандартной Windows-реализации протокола Telnet с одного из рабочих мест с сетевым коммутатором, все сетевые пакеты связи были запротоколированы с помощью наблюдающей станции (НС), настроенной на отбор пакетов (как отсылаемых, так и получаемых) для дампирования по MAC-адресу коммутатора. Вывод дампированных пакетов получен утилитой tamview.exe из комплекта программ, сопровождающих разработку математического обеспечения НС. Схема этого эксперимента приведена на рис. 3.
Рис. 3. Схема эксперимента связи с Cisco Catalyst-2935
Эксперимент проведен в условиях, исключающих иное стороннее наблюдение изнутри ЛВС, кроме рабочей НС: ip-связь с тестируемым устройством (выделено жирной линией) проходила, минуя компьютеры ЛВС.
В целях понимания представленных результатов эксперимента укажем, что тестовый сеанс связи проходил с ПК с MAC-адресом 004005411AAF, ip-адресом 193.232.194.13 на коммутатор с MAC-адресом 000DBCBBC780 и ip-адресом 193.232.194.25; состоял всего лишь в вводе логина, пароля и команды EXIT. На рис. 4 показаны первые 8 пакетов (их общее число ѕ 70).
Рис. 4. Формат первых 8 пакетов связи с Cisco Catalyst
По каждому пакету была проанализирована информационная часть и составлен список опций протокола Telnet, реально используемых в сеансах связи с коммутатором Cisco Catalyst-2935. Так, например, на рис. 5 показан отдельно пакет №6 рисунка 4, реструктурированный в соответствии с правилами TCP/IP [46]. Подчеркнуты 4 группы Telnet-команд, в спецификациях протокола Telnet именуемые WILL Echo, WILL SuppressGA, DO Terminal-Type и DO Window-Size.
Рис. 5. Формат пакета 6 связи с Cisco Catalyst
Таблица 1. Список используемых Terminal-опций
Описанный эксперимент позволил установить начальный список опций, заведомо используемых в Telnet-протоколе связи с коммутатором Catalyst-2935 (табл. 1). Дальнейшие эксперименты показали, что этот список окончательный, хотя порядок опций в отношении основного информационного потока может варьироваться в зависимости от сетевой коннективности.
Следует с сожалением отметить, что, как показали специальные эксперименты, реализация даже указанных команд в IOS Cisco неполна. Так, попытка применения ответной опции DON’T Echo на стороне клиента вовсе не подавляет последующие эхо-ответы сервера, как должно следовать из [47].
Реализующее программное обеспечение было создано в среде Windows на языке высокого уровня с использованием компилятора PowerBASIC for Windows 7.04. Использованы немодальные (modeless) диалоги, позволившие выполнить разработку программы в стиле реального времени (realtime). Общий вид окна программы приведен на рис. 6.
В этой, начальной версии программы предусмотрено выполнение всего одной содержательной команды Cisco Catalyst, которая должна быть параметром вызова программы. После ее исполнения следует автоматическое исполнение команды EXIT и связь с Cisco Catalyst разрывается. Однако, команда может быть выполнена несколько раз по инициативе оператора (нажатие кнопки Start).
Тем самым воспроизведены все необходимые условия создания настраиваемого программного обеспечения: конкретная исполняющая команда может быть задана параметром вызова программы. В дальнейшем предполагается дать возможность вместо конкретной команды задать параметром каталог шаблонов возможных сценариев.
Рис. 6. Вид окна программы управления Cisco Catalyst
На рис. 7 показан журнал работы, сформированный программой при исполнении команды DIR. Символы пароля заменены звездочками. Каждая строка соответствует одной транзакции (посылке или приему блока информации).
На приведенном рисунке после даты и времени указано направление транзакций: стрелка влево показывает символы, передающиеся на управляемый объект, стрелка вправо показывает принимаемые символы. Видно, как формируются транзакции при работе протокола: из программы управляющие символы подаются по одному, исключая концы строк и опциональные блоки.
Рис. 7. Журнал (протокол транзакций) исполнения команды DIR
Можно заметить (строки 17:40:07-17:40:12), что вместо подавленной согласно опциям Telnet команды GA при завершении многострочного текстового вывода протоколом управляемого объекта выполняется задержка до установленного значения таймаута (в программе задано значение 5 с). Разумеется, это неудобно для практической реализации; при формировании эксплуатационной версии следует алгоритмически разрешить этот вопрос.
Конечно же, приведенный журнал невозможно использовать в практической работе с программой конечного пользователя. Он включает по сути отладочную информацию, в то время как информационная его часть не структурирована по строкам. Поэтому, вместе с журналом формируется протокол работы, пример которого для вышеприведенного случая команды дан на рис. 8.
Рис. 8. Протокол пользователя - исполнение команды DIR
Приведенный протокол работы полностью соответствует аналогичному протоколу, получаемому при использовании команды DIR стандартной программой telnet.exe, входящей в комплект программ Windows. Тем самым можно считать исполнение результирующего модуля функционально успешным.
Особую трудность в реализации протокола Telnet вызвала алгоритмизация и программная обработка многострочного вывода в случае, когда формируемый вывод приостанавливается для прочтения заполненного “стандартного” экрана. В этом случае, оказывается, выводится отдельной строкой последовательность симолов “ –More—”, затем 9 символов BS, затем 8 символов пробела и еще 9 символов BS. Далее этот цикл может быть повторен. Предполагается, что на стандартном ANSI-терминале получается мигающая надпись. Два фрагмента такого вывода показаны на рис. 9, причем видно, что указанные символьные комбинации могут быть в физически разных транзакциях ввода (символы BS показаны квадратами).
Рис. 9. Фрагмент вывода Telnet с командами "More" (журнал)
Указанная трудность успешно преодолена следующим образом. Оказалось достаточным распознавать в транзакции ввода последовательность “--More--”, и подавать на вывод дополнительный пробел как сигнал продолжения многострочного вывода. В то же время, из строк формируемого протокола изымается часть согласно количеству приинятых символов BS. Полученный результат адекватен «чистому» протоколу вывода.
Легко видеть по рис. 9, что и в этом случае транзакции ввода принудительно задерживаются управляемым устройством на заданную величину таймаута. В финальной программной реализации этот вопрос также следует алгоритмически разрешить.
Проведенные эксперименты после завершения отладки реализующей программы проверены на коммутаторах Cisco Catalyst-2935 с IOS C2900XL Software 12.1(22)EA1, работающем в холостом режиме, и Cisco Catalyst-2924 c IOS 12.0(5.2)XU, работающем в стандартном режиме эксплуатации. Результаты адекватны, помех в работе коммутаторов не обнаружено.
Таким образом, проведенные исследования показали принципиальную возможность создания программных средств полуавтоматического и автоматического управления сетевыми коммутаторами Cisco Catalyst по протоколу Telnet. Эти программные средства работоспособны в реальном времени как Windows-приложения. Выполненная реализация таковых средств в начальном варианте проверена на актуальных сетевых коммутаторах Cisco Catalyst-2924 и Cisco Catalyst-2935 и показала результаты, адекватные стандартным методам управления. Далее предполагается реализовать аппарат типовых сценариев, а на более поздних этапах и связь со сторонними управляющими средствами.
Предложенный автором подход управления сетевыми коммутаторами открывает возможность создания нового варианта типовой технологии управления локальной вычислительной сетью, доступной в эксплуатации пользователям средней квалификации, а также интеграции средств управления коммутаторами в программный комплекс управления локальной сетью предприятия/организации.
(X)Работа выполнена при финансовой поддержке РФФИ, проект N 04-07-90260в