Маленький, но очень интересный проект

Маленький, но очень интересный проект

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


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


На первый взгляд задача достаточно простая. Установил VMware ESXi с бесплатной лицензией (на платную лицензию денег нет, так как это только стартап), создал нужное количество ВМ, сделал доступ к ним по RDP и, в принципе, все. Радуйся, пока все работает. Но у меня ситуация несколько иная. В первую очередь нужно обеспечить должный уровень безопасности. Для этого мне нужно было решить две проблемы:


  1. Как безопасно и удобно для клиента организовать удаленный VPN доступ до сервера ESXi?
  2. Каким образом изолировать виртуальные машины различных клиентов?

Небольшое пояснение ко второй проблеме.

Задача состоит в том, чтобы виртуальные машины разных клиентов на одном VMware ESXi сервере ни коим образом между собой не взаимодействовали. Ну, например, представьте себе ситуацию, когда одна виртуальная машина подверглась взлому, или на ней завелся вирус, и если все виртуальные машины в одной сети, то представьте себе, какими могут быть плачевные последствия. А теперь на минуточку остановитесь и подумайте, как бы вы поступили в данном случае, когда у вас есть только один сервер, и вам нужно сделать так, чтобы всем было хорошо ;)?

По поводу VPN доступа я не особо парился. Есть готовый VPN-сервер "OpenVPN Access Server", который мне очень нравится, его-то я и буду использовать.

Про настройку "OpenVPN Access Server" вы можете прочитать здесь.

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


Итак. Прежде чем я приведу схему сети, хочу рассказать про то, какую сеть и сетевую маску для виртуальных машин я выбрал. Исходя из того, что у одного клиента, в нашем случае, скорее всего не будет больше шести (6) виртуальных машин, я решил использовать /29 (255.255.255.248) маску подсети. Это мне позволит в сети 192.168.1.0 спокойно уместить 30 клиентов. Если этого станет мало - задействую сеть 192.168.2.0, ну, и так далее.


С помощью IP калькулятора я получил всю необходимую для себя информацию:

ipcal1.PNG

Теперь самое интересное. Схема сети:

Небольшое пояснение к схеме:


  • vmnic0 - когда я нахожусь рядом с хостом, через этот интерфейс я им управляю.
  • vmnic1 - к данному сетевому интерфейсу подключен интернет-провайдер.


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

Схему более высокого качества вы можете скачать в конце этой статьи.

vswitch-full.PNG

Как вы можете видеть на схеме, для каждого клиента на стандартном свиче 1 (vSwitch1) я создаю отдельную портгруппу со своим VLAN ID. Тем самым я добиваюсь того, что ВМ разных клиентов между собой без шлюза взаимодействовать никак не смогут.

Из документа: "VMware vSphere 4.1 Configuration Maximums":

cmax.png

512 портгрупп на один vSwitch меня вполне устраивает. Кстати говоря, в vSphere 5 это значение уменьшили ровно в два раза. Зачем, не понятно. Да, кстати, в качестве гипервизора я использую VMware ESXi 4.1 (с бесплатной лицензией).

Как я уже выше говорил, свои эксперименты я провожу на своем тестовом сервере, который работает под управлением VMware ESXi 5.0. Поэтому имейте в виду, что на скриншотах вы, возможно, увидите то, чего нет в vSphere 4.1. Но я думаю, что это не смертельно, поэтому просто примите к сведению.

Изолировать-то мы изолировали, но ВМ должны иметь выход в интернет, да и клиенты как-то должны добраться до своих виртуальных машин. Как видно, без шлюза здесь никак не обойтись.


Но как это организовать?


Эту проблему я решил достаточно просто. На все том же стандартном vSwitch1 я создал еще одну дополнительную портгруппу "GATEWAY-NET" c VLAN ID 4095. Здесь я не буду останавливаться на описании того, что это за VLAN ID 4095 и зачем он нужен. Для нас сейчас главное то, что в этой группе фактически собраны все ранее созданные VLAN'ы клиентов. А это означает только одно: если мы поместим в эту портруппу один из сетевых интерфейсов шлюза и на шлюзе правильно настроим vlan интерфейсы и маршрутизацию, то мы получим желаемый результат.


В качестве шлюзов у меня выступают виртуальные машины с ОС FreeBSD на борту. Вот скриншот того, как настроены vlan интерфейсы на шлюзе "Gateway-Private":

rc-conf-vlan.png

Вывод команды ifconfig:

Gateway.PNG

После того, как "Gateway-Private" настроен, проверяем работу сети на ВМ "Client-001-VM1":

Client-001-VM1.jpg

Как мы видим, от виртуальной машины "Client-001-VM1" пинги до шлюза "ходят". Очень Хорошо. Теперь давайте протестируем сеть на ВМ другого (второго) клиента. Для этого открываем консоль виртуальной машины "Client-002-VM1" и начинаем тестировать сеть:

Client-002-VM1.jpg

А теперь снова посмотрите скриншот приведенный выше, но на этот раз более внимательно. Обратите внимание на вывод команды tracert. Видите, что виртуальная машина второго клиента "Client-002-VM1" обменивается информацией с виртуальной машиной первого клиента через ШЛЮЗ, установленный по умолчанию? То есть мы можем на шлюзе настроить соответствующим образом фаервол и рулить трафиком как нам нужно. Захотели - открыли доступ, захотели - закрыли. В общем, схема работает. Но это еще не все. Ведь пока машины не получили доступ в интернет.


Для того, чтобы выпустить виртуальные машины в интернет, был поднят дополнительный шлюз на FreeBSD: "Gateway-Public", на который шлюз "Gateway-Private" и пересылает все запросы от ВМ, адресованные в интернет.


Ну, а теперь попробую еще раз пояснить то, как вся эта кухня работает. Допустим, первый клиент захотел получить RDP доступ до своих ВМ. Что он делает? Он запускает web-браузер, вводит там наше доменное имя, и в ответ в браузере появляется приглашение от OpenVPN сервера на ввод логина и пароля. После успешной аутентификации клиент запускает нужный RDP ярлычок, где уже прописан IP адрес нужной ВМ, и, тем самым, клиент получает доступ к своим машинам. Чтобы клиент получил доступ только к своим ВМ, на фаерволе "Gateway-Private" соответствующим образом настраиваются правила для каждого клиента.


Теперь давайте рассмотрим тот нередкий случай, когда администратору нужно получить доступ к ВМ "vSphere-Client". Системный/виртуальный администратор так же, как и любой другой клиент, должен установить защищенное соединение с OpenVPN сервером и, далее, просто соединиться с нужной виртуальной машиной, используя для этого RDP. Вся логика по разграничению доступа лежит на "Gateway-Private". Именно он ответственен за то, кому и куда можно "ходить".


В заключение, хочу написать о том, как заносится в систему новый клиент. Итак. Допустим, у нас появился четвертый клиент, который заказал одну ВМ. Что я делаю:


  • Создаю на vSwitch1 портгруппу "CLIENT-004-NET" с VLAN ID 4.
  • Создаю новую ВМ с сетевым интерфейсом, входящим в эту портгруппу.
  • На шлюзе "Gateway-Private" создаю новый сетевой интерфейс "vlan4".

Данный сетевой интерфейс можно создать заранее. Если клиентов у вас много, то можно быстренько накатать простенький скрипт.

  • Затем на этом же шлюзе "Gateway-Private" настраиваю соответствующим образом фаервол.

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

  • Ну и, в последнюю очередь, на OpenVPN сервере я создаю нового пользователя. Вот и все.


Новый, четвертый клиент в систему занесен. Ура, товарищи! Осталось только рассказать клиенту, как всем этим хозяйством пользоваться. Благо, это не занимает много времени. На этом у меня все. Надеюсь, что кому-нибудь эта статья окажется полезной и нужной.

Attachments
Comments

А зачем так сложно в части шлюза?

Вместо трех виртуальных машин gateway-public, gateway-private и openvpn вполне достаточно одного шлюза с vpn сервером.

Я сторонник разделения сервисов с целью повышения безопасности системы в целом.

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

Честно говоря, не уловил взаимосвязи. Может, поясните свою точку зрения?

Сама идея виртуализации состоит в том, что разные сервисы консолидируются в одно железо.

Сторонникам разделения это должно не подойти. 🙂

Вы разделяете сервисы на разные виртуальные серверы, чтобы потом совместить их в одном физическом.

Т.е. в принципе идея ясна, и часто весьма полезна. Но в данном случае, я считаю, разносить эти три шлюза не имеет никакого практического смысла.

Вы совсем не принимаете во внимание удобство администрирования и безопасность. Когда три сервиса в одной ВМ (в данном случае), их сложнее сопровождать (моё мнение). В частности, представьте ситуацию, когда вышло экстренное обновление для VPN сервера, и вам нужно срочно обновиться, а обновление, допустим, требует перезагрузки ВМ. Что будет в случае возникновения какой-либо ошибки, и при этом ВМ не удается загрузиться? Все. Вы потеряли доступ до сервера.

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

В случае же разделения сервисов, при обновлении VPN-сервера, у меня, как минимум, всегда будет доступ по SSH до Gateway-Public.

Вот вам другая ситуация - вы пренебрегли обновлением, и ваш сервер “3 в одном” взломали. Тогда злоумышленник без всяких проблем получит доступ к клиентским сетям. В случае же с разделением сервисов, злоумышленник всего лишь окажется в DMZ зоне, и ему еще нужно будет постараться, чтобы пройти фаервол Gateway-Private. В общем, я всяческий сторонник DMZ.

P.S.

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

В принципе согласен.

Не зря говорят, что внедрение виртуализации ведет к чрезмерному росту количества виртуальных серверов. 🙂

Есть подозрение, что использование ESX(i) подобных наколенных "хостингах" противоречит требованиям EULA. Для продажи своего IaaS'а нужно отдельно договариваться (кажется, программа VSPP). Т.ч. в данном случае с темже успехом можно было не ограничиваться фришной версией и использовать функционал PVLAN.

В блоге vmgu.ru уже дали пояснение по этому поводу: http://www.vmgu.ru/news/vmware-vspp-program-rent-vms

Version history
Revision #:
1 of 1
Last update:
‎11-13-2011 03:00 AM
Updated by: