Сервис тестирования продуктов Dr.Web LiveDemo на основе VMware ESXi

 АЛЕКСАНДР ФАТЕЕВ, специалист отдела развития ООО «Доктор Веб». Занимается системным администрированием с 2001 года

Сервис тестирования
продуктов Dr.Web LiveDemo на основе VMware ESXi

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

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

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

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

Итак, перечислим имеющиеся ресурсы и стоящие перед нами задачи. У нас есть несколько серверов с большим объемом дискового пространства и оперативной памяти – на них будут работать виртуальные машины. Есть сервер, который будет выступать в роли шлюза. Кроме того, на нем будут находиться все средства управления. Все это объединяется с помощью коммутатора, который должен поддерживать vlan. Задачи же стоят следующие: создать несколько идентичных наборов виртуальных машин, каждый – в своей изолированной сети; создать ряд снапшотов виртуальных машин, которые позволят нам возвращать их в одно или несколько исходных состояний; создать средства управления и автоматизации.

Схема сети

Сам процесс установки и настройки ESXi прост, и описывать его не имеет смысла. Поэтому сразу идем далее.

Прежде всего, мы разделим трафик – управление будем выполнять через интерфейс vmnic0, а непосредственно работа с виртуальными машинами будет происходить через vmnic1. Для каждой виртуальной сети нам нужен собственный vlan. Допустим, мы решили создать 16 виртуальных сетей, в каждой – не более 10 машин. Мы можем использовать любую «серую» сеть класса C. Например, 192.168.10.0/24 – разделить ее на 16 сетей несложно, получатся сети 192.168.10.0/28; 192.168.10.16/28 и т.д. Необходимо создать виланы для этих сетей, как на коммутаторе, так и на серверах ESXi. Для ESXi это можно сделать с помощью консоли клиента, вкладки Configuration > Networking. Виланы нужно создавать на том интерфейсе, который мы будем использовать для работы с виртуальными машинами. После того как конфигурация сети завершена, можно создавать виртуальные машины. После создания новой машины, ее установки и настройки необходимо создать снапшот, для того чтобы иметь возможность вернуть все в исходное состояние. Если исходных состояний несколько – например, рабочая станция в составе AD и не в составе AD, то необходимо сделать снапшоты в каждом из состояний.

Итак, после того как непосредственная настройка серверов ESXi и виртуальных машин завершена, переходим к самому главному: как этим всем пользоваться и управлять. Нам нужна возможность подключаться к виртуальным машинам из «внешнего мира», а также интерфейс для быстрого и удобного управления наборами. Для этих целей используем еще один сервер, который будет служить брандмауэром, шлюзом (с редиректом портов) и на котором будут работать скрипты для управления и автоматизации. Какие именно процессы нам надо автоматизировать? Прежде всего, откат виртуальной машины до требуемого снапшота. Во-вторых, включение виртуальной машины по запросу. В-третьих, генерация паролей и установка их на виртуальных машинах. В-четвертых, автоматическое отключение виртуальной машины по истечении заданного времени. Вообще говоря, официально средств автоматизации у ESXi нет. Но на самом деле они есть! Для начала нам необходимо включить возможность доступа к ESXi-серверу по протоколу SSH. Для этого нужно:

• с консоли сервера нажать + ;
• набрать unsupported (вывод отображаться не будет);
• залогиниться (тот же логин/пароль, что и для входа в консоль);
• раскомментировать в файле /etc/inetd.conf SSH;
• перезагрузить сервер.

После этого сервер становится доступен по протоколу SSH. Из консоли нам становится доступно множество полезных команд для управления виртуальными машинами.

В качестве примера возьмем виртуальную машину XP1 (путь до нее: /vmfs/volumes/datastore1/XP1/XP1.vmx).

Перечислим те команды, которые будут нам полезны.

Включить виртуальную машину:

vim-cmd vmsvc/power.on /vmfs/volumes/datastore1/XP1/XP1.vmx

Выключить виртуальную машину:

vim-cmd vmsvc/power.off /vmfs/volumes/datastore1/XP1/XP1.vmx

Откатить до снапшота нужного уровня:

vim-cmd vmsvc/snapshot.revert /vmfs/volumes/datastore1/XPen-1/XPen-1.vmx suppressPowerOff 1

(первым уровнем является «0»).

Получить список снапшотов:

vim-cmd vmsvc/get.snapshotinfo /vmfs/volumes/datastore1/XPen-1/XPen-1.vmx

Получить информацию о виртуальной машине:

vim-cmd vmsvc/get.summary /vmfs/volumes/datastore1/XPen-1/XPen-1.vmx

Теперь дело за малым – написать ряд необходимых скриптов для управления ESXi, веб-интерфейс для удобства администрирования, а также создать базу данных для хранения информации о наборах.

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

После этого происходит следующее:

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

Для обеспечения интерактивности в скриптах очень удобен язык expect. Ниже – пример скрипта на expect, который включает виртуальную машину (адрес сервера ESXi и путь до виртуальной машины он получает в качестве параметров):

#!/usr/local/bin/expect

set server [lindex $argv 0]
set config [lindex $argv 1] 

spawn ssh root@$server
expect "password:"
send password
expect "#"
send "vim-cmd vmsvc/power.on $config " 

send "exitr"
expect eof

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

Также важным моментом является удаленная смена паролей для Windows-машин (для «юниксовых», понятное дело, никаких проблем нет). Пример скрипта, который меняет пароль пользователю AD и разблокирует его:

#!/usr/local/bin/expect

set ip [lindex $argv 0]
set user [lindex $argv 1]
set password [lindex $argv 2]

spawn telnet -l administrator $ip
expect "password:"
send pass

expect ">"
send "dsmod user CN=$user,OU=drweb,DC=drweb,DC=test -disabled no "
expect ">"
send "dsmod user CN=$user,OU=drweb,DC=drweb,DC=test -pwd $password "

send "exit "
expect eof

Аналогичный пример, но для обычного пользователя (не AD):

#!/usr/local/bin/expect

set ip [lindex $argv 0]
set password [lindex $argv 1]

spawn telnet -l user $ip
expect "password:"
send pass

expect "user>"
send "net user user $password "
expect "user>"

send "exit "
expect eof

В обоих примерах вместо pass надо, естественно, подставить выбранный админский пароль.

Несколько слов о доступе к машинам и безопасности. На шлюзовой машине должны быть созданы все те же виланы, что и на ESXi и коммутаторе. Следует учитывать, что данная система предназначена для открытого доступа, следовательно, она должна быть надежно изолирована от внутренней сети и сервисов. Для этого на машине, служащей шлюзом (в моем случае это машина под управлением FreeBSD, в качестве брандмауэра используется pf), необходимо закрыть все порты, кроме тех, которые необходимы для доступа к виртуальным машинам. Записываем в конце pf.conf закрывающие правила:

block in log quick on $int_if from any to any
block in log quick on $ext_if from any to any

block in log quick on $all_vlans from any to any
block out log quick on $all_vlans from any to any

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

rdr on $ext_if proto tcp from any to $ext_ip port 2010 -> 192.168.10.18 port 22

Теперь, обратившись на внешний адрес сервера на порт 2010, мы будем перенаправлены на порт 22 сервера 192.168.10.18.

В итоге конечный пользователь, выполнив запрос, получает логин/пароль для доступа, адреса виртуальных машин (доступ по SSH для Linux, по RDP для Windows) и параметры виртуальной сети. В рамках этой сети он является полноправным администратором и волен делать все что угодно. Даже если машины в результате его действий «упадут», никаких негативных последствий не будет. После отката до исходных снапшотов все вернется в исходное рабочее состояние.

На данный момент пользователи могут получать для тестирования практически все серверные продукты Dr.Web, включая Dr.Web Enterprise Suite и Dr.Web для почтовых серверов UNIX. При этом они могут как сами установить и настроить все эти продукты, так и получить уже настроенную тестовую сеть. Второй вариант полезен партнерам для проведения демонстраций возможностей продуктов клиентам и самим потенциальным покупателям – если они хотят просто оценить возможности продукта, не изучая документацию. Особенностью сервиса Dr.Web LiveDemo является то, что его пользователи могут заказать интересующую их конфигурацию локальной сети – выбрав ее из списка возможных или отправив запрос администратору сервиса. При работе с сервисом пользователи опираются не только на документацию к продуктам, но и на пошаговые инструкции по настройке наиболее востребованных функций.

Комментарии могут оставлять только зарегистрированные пользователи