Давайте представим себе, что некоторая компания заинтересована в расширении своей локальной ИТ-инфраструктуры и хотела бы перенести часть нагрузок в Windows Azure. Для нас сейчас не принципиально, что конкретно будет переезжать в облако: веб-сервер, база данных, портал SharePoint или что-то еще. Важно, чтобы виртуальные машины, развернутые в Windows Azure, «виделись» как часть локальной инфраструктуры Active Directory (AD), были включены (или могли быть включены) в домен и по сути представляли собой просто еще один сегмент корпоративной сети.
Планируемая конфигурация выглядит следующим образом:
Точнее слева на рисунке то, что уже есть, справа то, что предстоит сделать.
В первую очередь мы создадим в Windows Azure виртуальную сеть с именем VPNnet01. В этой сети необходимо предусмотреть как минимум две подсети – одна (можно несколько) для ВМ, вторая для построения туннеля в локальную AD. Наличие выделенной подсети для шлюза является требованием Windows Azure.
Затем организуем туннель между созданной виртуальной сетью и локальной инфраструктурой, причем сначала этот туннель настраивается со стороны Windows Azure, потом со стороны локальной сети.
Наконец, создадим ВМ в Windows Azure и убедимся, что эта виртуальная машина доступна из локальной сети и наоборот, ВМ может взаимодействовать с контроллером домена, расположенным локально.
Вся процедура, таким образом, сводится к четырем основным этапам:
- Создание виртуальной сети в Windows Azure
- Настройка шлюза в Windows Azure
- Настройка Windows Server 2012 R2 в качестве S2S-шлюза в локальной сети
- Создание ВМ в Windows Azure и проверка конфигурации
Поехали!
Я исхожу из того, что подписка Windows Azure в организации уже есть. Варианты получения подписки перечислены здесь. Я также предполагаю, что вы имеете представление о концепции виртуальных сетей в Windows Azure. Если это не так, можно подчерпнуть информацию в третьем модуле курса «Windows Azure для системных администраторов» на портале MVA. Но основные шаги я прокомментирую.
Итак, необходимо зайти на портал управления Windows Azure и выбрать в разделе NETWORKS создание новой виртуальной сети, нажав кнопку NEW.
Задаем имя виртуальной сети и выбираем AFFINITY GROUP, которая позволяет расположить ваши ВМ в рамках одного ЦОД Windows Azure для сокращения задержек в сети. Если ни одной AFFINITY GROUP у вас еще нет, вам предложено будет такую группу создать.
На следующей странице необходимо задать имя и IP-адрес сервера(-ов) DNS. Строго говоря, это поле не является обязательным, и его можно заполнить/изменить позже. Но для нашего сценария вся информация о DNS уже есть. Поскольку мы планируем использовать ВМ в Windows Azure как часть AD предприятия, то здесь я указываю имя и IP-адрес контроллера домена, традиционно выполняющего и роль DNS-сервера. Все создаваемые в этой сети ВМ автоматически получат именно этот адрес в качестве адреса DNS-сервера. Если поле оставить пустым, то создаваемые впоследствии ВМ будут использовать для разрешения имен службу DNS Windows Azure и при этом, разумеется, включить такие машины в домен не получится. Технически вы сможете потом зайти на конкретную ВМ, например, с помощью RDP и вручную изменить адрес DNS, но предлагаемый на данной странице вариант гораздо удобнее. Кроме того, надо заметить, что вообще не рекомендуется что-либо менять вручную в настройках TCP/IP виртуальных машин. Этими настройками управляет Windows Azure, чтобы вы, в свою очередь, имели надежный доступ к вашим машинам.
Второй важный параметр на странице – чекбокс Configure site-to-site VPN, который нужно не забыть отметить.
На странице Site-to-Site Connectivity задаем три параметра:
- NAME – имя сайта, оно может быть произвольным и лишь идентифицирует набор настроек, который на данной странице мы и формируем;
- VPN DEVICE IP ADDRESS – внешний IP-адрес VPN-шлюза в локальной сети предприятия, применительно к рассматриваемому сценарию это IPv4-адрес на внешнем сетевом интерфейсе машины с Windows Server 2012 R2;
- ADDRESS SPACE – адресное пространство локальной сети или той ее части, к которой хотим предоставить доступ из Windows Azure.
На странице Virtual Network Address Spaces необходимо сформировать виртуальное адресное пространство создаваемой виртуальной сети. ВМ в облаке будут получать IP-адреса как раз из этого пространства. Указав адресный диапазон всей сети, нужно затем разбить его на подсети. Напомню, что требуется как минимум две подсети: для ВМ и шлюза соответственно. В каждой виртуальной сети может быть только одна подсеть шлюза.
Нажимаем кнопку “Complete” и ждем завершение процесса создания виртуальной сети.
Собственно на этом первый этап завершен, и мы можем переходить к настройке шлюза Windows Azure.
После того как сеть создана, щелкаем по ней и видим закладку DASHBOARD.
В меню в нижней части экрана нажимаем CREATE GATEWAY и выбираем Dynamic Routing. Два типа маршрутизации поддерживает на текущий момент Windows Azure. Статическая маршрутизация основана на заданных пользователем политиках (списках доступа), динамическая – на заданных маршрутах и туннельном интерфейсе (любой пакет, попадающий на туннельный интерфейс, пересылается через VPN-туннель). В случае динамической маршрутизации, соответственно, если IP-диапазоны виртуального и локального адресных пространств при создании виртуальной сети в Windows Azure были заданы корректно (не пересекаются, не дублируются и пр.), то пакеты должны правильным образом маршрутизироваться между Windows Azure и локальной инфраструктурой.
Выбор типа маршрутизации определяется тем, какой шлюз используется на стороне локальной инфраструктуры. В документации в разделе Known compatible VPN devices можно посмотреть список поддерживаемых шлюзов и соответствующих им типов маршрутизации.
Остается ждать, пока Windows Azure настроит шлюз. Этот процесс занимает в среднем 15-20 мин.
По окончании на странице можно увидеть внешний IP-адрес созданного в Windows Azure шлюза, и этот адрес следует использовать в качестве конечной точки подключения при настройке шлюза в корпоративной сети.
Для определенных моделей шлюзов (VPN-устройств), в том числе для службы RRAS в Windows Server 2012/R2, Windows Azure может сгенерировать скрипт, который затем необходимо запустить на VPN-устройстве и тем самым сконфигурировать это устройство для организации туннеля в Windows Azure. Чтобы загрузить такой скрипт нужно создать ключ, используемый для туннельной аутентификации, нажав MANAGE KEY,
а затем щелкнуть по ссылке Download VPN Device Script справа на странице.
В открывшемся окне выберете производителя шлюза, платформу и операционную систему и загрузите скрипт.
Теперь полученный скрипт необходимо перенести на VPN-устройство и выполнить настройку.
Следует убедиться в том, что полученный на предыдущем этапе скрипт содержит корректные значения адресного пространства виртуальной сети и внешнего адреса шлюза Windows Azure. Эти значения выделены в приведенном фрагменте скрипта.
# Install RRAS role
Import-Module ServerManager
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Add-WindowsFeature -name Routing -IncludeManagementTools
# !!! NOTE: A reboot of the machine might be required here after which the script can be executed again.
# Install S2S VPN
Import-Module RemoteAccess
Install-RemoteAccess -VpnType VpnS2S
# Add and configure S2S VPN interface
Add-VpnS2SInterface -Protocol IKEv2 -AuthenticationMethod PSKOnly -NumberOfTries 3 -ResponderAuthenticationMethod PSKOnly -Name 137.116.214.169 -Destination 137.116.214.169 -IPv4Subnet @("10.50.0.0/16:100") -SharedSecret 0pCpWdVuzaJuZtJpQq8TbtUAQWk7PtOk
Set-VpnServerIPsecConfiguration -EncryptionType MaximumEncryption
# Set S2S VPN connection to be persistent by editing the router.pbk file (required admin priveleges)
Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "IdleDisconnectSeconds" "0"
Set-PrivateProfileString $env:windir\System32\ras\router.pbk "137.116.214.169" "RedialOnLinkFailure" "1"
# Restart the RRAS service
Restart-Service RemoteAccess
# Dial-in to Azure gateway (optional)
#Connect-VpnS2SInterface -Name 137.116.214.169
Если все верно, остается просто запустить это скрипт на машине с Windows Server 2012 R2, которая будет выполнять роль шлюза. Подчеркиваю, выше приведен лишь фрагмент. Запускать надо, конечно, весь скрипт целиком, причем под учетной записью с правами администратора. Например, это можно сделать в PowerShell ISE.
По приведенному фрагменту видно, что скрипт устанавливает и настраивает службу Routing and Remote Access Services (RRAS). Давайте посмотрим, как выглядят некоторые настойки RRAS после успешного выполнения скрипта.
Во-первых, в разделе Network Interfaces можно заметить интерфейс с именем, соответствующим внешнему IP-адресу шлюза в Windows Azure, причем состояние этого интерфейса должно быть Connected. Если это не так, щелкните по нему правой кнопкой мыши и в контекстном меню выберете Connect.
В свойствах этого интерфейса, используемого, как вы понимаете, для построения туннеля, мы найдем IP-адрес шлюза Windows Azure,
а также на закладке Security используемый протокол (IKEv2) и сгенерированный в Windows Azure ключ.
Кроме того, в разделе Static Routes появился статический маршрут, пересылающий по туннелю все пакеты с адресами получателя, принадлежащими виртуальной сети Windows Azure.
Сам RRAS-сервер сконфигурирован в качестве маршрутизатора, в чем можно убедиться посмотрев его свойства.
Используя приведенную информацию, вы сможете вручную настроить службу RRAS, если по каким-либо причинам скрипт отработал с ошибками.
Если же все в порядке, то вернувшись на закладку DASHBOARD виртуальной сети, созданной в Windows Azure, вы увидите примерно такую картину:
Либо она станет такой после нажатия кнопки CONNECT внизу страницы.
Теперь, когда туннель создан, остается проверить конфигурацию.
Для этого давайте создадим ВМ в Windows Azure и попробуем включить эту ВМ в AD локальной инфраструктуры. Шаги достаточно стандартные, в разделе VIRTUAL MACHINES нажимаем NEW и выбираем FROM GALLERY,
в качестве гостевой ОС выбираем, например, Windows Server 2012,
задаем имя ВМ, логин и пароль администратора,
и убеждаемся, что машина будет подключена к созданной ранее виртуальной сети.
На последней странице оставляем все без изменений.
После того как ВМ запустится, можно подключиться к ней по RDP и посмотреть параметры IP. В данном случае видно, что ВМ получила адрес 10.50.1.4 из адресного пространства виртуальной сети, при этом в качестве адреса DNS-сервера указан адрес контроллера домена (192.168.3.200).
Проверим разрешение имен и ping на контроллер домена, если конечно Firewall разрешает ICMP.
Коммуникации настроены, остается просто включить ВМ в домен, и это уже самая обычная процедура, на которой я останавливаться не буду.
Итак, мы прошли все этапы, и теперь наша локальная инфраструктура расширена сетевым сегментом в Windows Azure. В этом сегменте можно создавать дополнительные подсети, запускать ВМ нужной конфигурации, переносить в них требуемые сервисы, настраивать их мониторинг и использовать таким образом ресурсы облака для решения стоящих перед ИТ-департаментом задач.
Я привел достаточно подробное описание настроек для того, чтобы вы смогли при необходимости воспроизвести рассмотренные шаги. Как упоминалось, на сайте Windows Azure вы сможете найти скрипты для разных типов VPN-шлюзов. Но даже если в этом списке нет вашего устройства, вы можете настроить свой шлюз, понимаю логику работы и используемые протоколы и механизмы аутентификации Windows Azure. В общем, лучший способ изучить технологию – попробовать самому. :)
Надеюсь, материал был полезен!
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:
- Massacres That Matter - Part 1 - 'Responsibility To Protect' In Egypt, Libya And Syria
- Massacres That Matter - Part 2 - The Media Response On Egypt, Libya And Syria
- National demonstration: No attack on Syria - Saturday 31 August, 12 noon, Temple Place, London, UK
Комментариев нет:
Отправить комментарий