С появлением в Windows Azure технологий виртуальных машин (ВМ) и виртуальных сетей реализация гибридных сценариев, когда часть локальной инфраструктуры переносится в облако или расширяется за счет ресурсов облака, становится вполне выполнимой задачей. Подобные сценарии предполагают наличие туннеля между локальной сетью предприятия и облаком. В этом посте я покажу, каким образом строится такой Site-to-Site (S2S) туннель в случае, когда в качестве облака выступает Windows Azure, а шлюзом в локальной сети является сервер под управлением Windows Server 2012 R2. Будет много картинок.

Постановка задачи

Давайте представим себе, что некоторая компания заинтересована в расширении своей локальной ИТ-инфраструктуры и хотела бы перенести часть нагрузок в Windows Azure. Для нас сейчас не принципиально, что конкретно будет переезжать в облако: веб-сервер, база данных, портал SharePoint или что-то еще. Важно, чтобы виртуальные машины, развернутые в Windows Azure, «виделись» как часть локальной инфраструктуры Active Directory (AD), были включены (или могли быть включены) в домен и по сути представляли собой просто еще один сегмент корпоративной сети.

Планируемая конфигурация выглядит следующим образом:

Точнее слева на рисунке то, что уже есть, справа то, что предстоит сделать.

В первую очередь мы создадим в Windows Azure виртуальную сеть с именем VPNnet01. В этой сети необходимо предусмотреть как минимум две подсети – одна (можно несколько) для ВМ, вторая для построения туннеля в локальную AD. Наличие выделенной подсети для шлюза является требованием Windows Azure.

Затем организуем туннель между созданной виртуальной сетью и локальной инфраструктурой, причем сначала этот туннель настраивается со стороны Windows Azure, потом со стороны локальной сети.

Наконец, создадим ВМ в Windows Azure и убедимся, что эта виртуальная машина доступна из локальной сети и наоборот, ВМ может взаимодействовать с контроллером домена, расположенным локально.

Вся процедура, таким образом, сводится к четырем основным этапам:

1. Создание виртуальной сети в Windows Azure
2. Настройка шлюза в Windows Azure
3. Настройка Windows Server 2012 R2 в качестве S2S-шлюза в локальной сети
4. Создание ВМ в Windows Azure и проверка конфигурации

Поехали!

Создание виртуальной сети в 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.

Настройка шлюза в 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 Server 2012 R2 в качестве S2S-шлюза

Следует убедиться в том, что полученный на предыдущем этапе скрипт содержит корректные значения адресного пространства виртуальной сети и внешнего адреса шлюза 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 и проверка конфигурации

Теперь, когда туннель создан, остается проверить конфигурацию.

Для этого давайте создадим ВМ в 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. В общем, лучший способ изучить технологию – попробовать самому. 🙂

Надеюсь, материал был полезен!