Расширение локальной инфраструктуры в облако
С появлением в Windows Azure технологий виртуальных машин (ВМ) и виртуальных сетей реализация гибридных сценариев, когда часть локальной инфраструктуры переносится в облако или расширяется за счет ресурсов облака, становится вполне выполнимой задачей. Подобные сценарии предполагают наличие туннеля между локальной сетью предприятия и облаком. В этом посте я покажу, каким образом строится такой Site-to-Site (S2S) туннель в случае, когда в качестве облака выступает Windows Azure, а шлюзом в локальной сети является сервер под управлением Windows Server 2012 R2. Будет много картинок.
Постановка задачи
Давайте представим себе, что некоторая компания заинтересована в расширении своей локальной ИТ-инфраструктуры и хотела бы перенести часть нагрузок в Windows Azure. Для нас сейчас не принципиально, что конкретно будет переезжать в облако: веб-сервер, база данных, портал SharePoint или что-то еще. Важно, чтобы виртуальные машины, развернутые в Windows Azure, «виделись» как часть локальной инфраструктуры Active Directory (AD), были включены (или могли быть включены) в домен и по сути представляли собой просто еще один сегмент корпоративной сети.
Планируемая конфигурация выглядит следующим образом:
![clip_image001[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/8688.clip_image0016_2CE20B47.png "clip_image001[6]")
Точнее слева на рисунке то, что уже есть, справа то, что предстоит сделать.
В первую очередь мы создадим в 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. Если это не так, можно подчерпнуть информацию в третьем модуле курса «Windows Azure для системных администраторов» на портале MVA. Но основные шаги я прокомментирую.
Итак, необходимо зайти на портал управления Windows Azure и выбрать в разделе NETWORKS создание новой виртуальной сети, нажав кнопку NEW.
![clip_image003[5]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/3487.clip_image0035_2E48BECA.png "clip_image003[5]")
Задаем имя виртуальной сети и выбираем AFFINITY GROUP, которая позволяет расположить ваши ВМ в рамках одного ЦОД Windows Azure для сокращения задержек в сети. Если ни одной AFFINITY GROUP у вас еще нет, вам предложено будет такую группу создать.
![clip_image005[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0068.clip_image0056_4AE7CB4E.png "clip_image005[6]")
На следующей странице необходимо задать имя и IP-адрес сервера(-ов) DNS. Строго говоря, это поле не является обязательным, и его можно заполнить/изменить позже. Но для нашего сценария вся информация о DNS уже есть. Поскольку мы планируем использовать ВМ в Windows Azure как часть AD предприятия, то здесь я указываю имя и IP-адрес контроллера домена, традиционно выполняющего и роль DNS-сервера. Все создаваемые в этой сети ВМ автоматически получат именно этот адрес в качестве адреса DNS-сервера. Если поле оставить пустым, то создаваемые впоследствии ВМ будут использовать для разрешения имен службу DNS Windows Azure и при этом, разумеется, включить такие машины в домен не получится. Технически вы сможете потом зайти на конкретную ВМ, например, с помощью RDP и вручную изменить адрес DNS, но предлагаемый на данной странице вариант гораздо удобнее. Кроме того, надо заметить, что вообще не рекомендуется что-либо менять вручную в настройках TCP/IP виртуальных машин. Этими настройками управляет Windows Azure, чтобы вы, в свою очередь, имели надежный доступ к вашим машинам.
Второй важный параметр на странице – чекбокс Configure site- to- site VPN, который нужно не забыть отметить.
![clip_image007[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/2502.clip_image0076_1ECD5F0E.png "clip_image007[6]")
На странице Site- to- Site Connectivity задаем три параметра:
- NAME – имя сайта, оно может быть произвольным и лишь идентифицирует набор настроек, который на данной странице мы и формируем;
- VPN DEVICE IP ADDRESS – внешний IP-адрес VPN-шлюза в локальной сети предприятия, применительно к рассматриваемому сценарию это IPv4-адрес на внешнем сетевом интерфейсе машины с Windows Server 2012 R2;
- ADDRESS SPACE – адресное пространство локальной сети или той ее части, к которой хотим предоставить доступ из Windows Azure.
![clip_image009[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/2577.clip_image0096_671D358E.png "clip_image009[6]")
На странице Virtual Network Address Spaces необходимо сформировать виртуальное адресное пространство создаваемой виртуальной сети. ВМ в облаке будут получать IP-адреса как раз из этого пространства. Указав адресный диапазон всей сети, нужно затем разбить его на подсети. Напомню, что требуется как минимум две подсети: для ВМ и шлюза соответственно. В каждой виртуальной сети может быть только одна подсеть шлюза.
![clip_image011[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/6406.clip_image0116_0CA943A1.png "clip_image011[6]")
Нажимаем кнопку “Complete” и ждем завершение процесса создания виртуальной сети.
![clip_image013[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/5430.clip_image0136_3B9116E7.png "clip_image013[6]")
Собственно на этом первый этап завершен, и мы можем переходить к настройке шлюза Windows Azure.
Настройка шлюза в Windows Azure
После того как сеть создана, щелкаем по ней и видим закладку DASHBOARD.
![clip_image015[6]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/8865.clip_image0156_7F6A6CA0.png "clip_image015[6]")
В меню в нижней части экрана нажимаем CREATE GATEWAY и выбираем Dynamic Routing. Два типа маршрутизации поддерживает на текущий момент Windows Azure. Статическая маршрутизация основана на заданных пользователем политиках (списках доступа), динамическая – на заданных маршрутах и туннельном интерфейсе (любой пакет, попадающий на туннельный интерфейс, пересылается через VPN-туннель). В случае динамической маршрутизации, соответственно, если IP-диапазоны виртуального и локального адресных пространств при создании виртуальной сети в Windows Azure были заданы корректно (не пересекаются, не дублируются и пр.), то пакеты должны правильным образом маршрутизироваться между Windows Azure и локальной инфраструктурой.
![clip_image017[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/1803.clip_image0174_5DA3B571.png "clip_image017[4]")
Выбор типа маршрутизации определяется тем, какой шлюз используется на стороне локальной инфраструктуры. В документации в разделе Known compatible VPN devices можно посмотреть список поддерживаемых шлюзов и соответствующих им типов маршрутизации.
Остается ждать, пока Windows Azure настроит шлюз. Этот процесс занимает в среднем 15-20 мин.
![clip_image019[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/7851.clip_image0194_0E5BDE7F.png "clip_image019[4]")
По окончании на странице можно увидеть внешний IP-адрес созданного в Windows Azure шлюза, и этот адрес следует использовать в качестве конечной точки подключения при настройке шлюза в корпоративной сети.
![clip_image021[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/4137.clip_image0214_5F31A4FA.png "clip_image021[4]")
Для определенных моделей шлюзов (VPN-устройств), в том числе для службы RRAS в Windows Server 2012/R2, Windows Azure может сгенерировать скрипт, который затем необходимо запустить на VPN-устройстве и тем самым сконфигурировать это устройство для организации туннеля в Windows Azure. Чтобы загрузить такой скрипт нужно создать ключ, используемый для туннельной аутентификации, нажав MANAGE KEY,
![clip_image022[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/1321.clip_image0224_7B647E89.png "clip_image022[4]")
а затем щелкнуть по ссылке Download VPN Device Script справа на странице.
В открывшемся окне выберете производителя шлюза, платформу и операционную систему и загрузите скрипт.
![clip_image023[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/1106.clip_image0234_138A7996.png "clip_image023[4]")
Теперь полученный скрипт необходимо перенести на 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.
![clip_image025[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/5710.clip_image0254_19D3E0D5.png "clip_image025[4]")
По приведенному фрагменту видно, что скрипт устанавливает и настраивает службу Routing and Remote Access Services (RRAS). Давайте посмотрим, как выглядят некоторые настойки RRAS после успешного выполнения скрипта.
Во-первых, в разделе Network Interfaces можно заметить интерфейс с именем, соответствующим внешнему IP-адресу шлюза в Windows Azure, причем состояние этого интерфейса должно быть Connected. Если это не так, щелкните по нему правой кнопкой мыши и в контекстном меню выберете Connect.
![clip_image027[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/2553.clip_image0274_040F19DA.png "clip_image027[4]")
В свойствах этого интерфейса, используемого, как вы понимаете, для построения туннеля, мы найдем IP-адрес шлюза Windows Azure,
![clip_image028[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0702.clip_image0284_30BA6464.png "clip_image028[4]")
а также на закладке Security используемый протокол (IKEv2) и сгенерированный в Windows Azure ключ.
![clip_image029[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/4722.clip_image0294_4B1CE82C.png "clip_image029[4]")
Кроме того, в разделе Static Routes появился статический маршрут, пересылающий по туннелю все пакеты с адресами получателя, принадлежащими виртуальной сети Windows Azure.
![clip_image031[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/3250.clip_image0314_02F44DB2.png "clip_image031[4]")
Сам RRAS-сервер сконфигурирован в качестве маршрутизатора, в чем можно убедиться посмотрев его свойства.
![clip_image032[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0827.clip_image0324_24760DF2.png "clip_image032[4]")
Используя приведенную информацию, вы сможете вручную настроить службу RRAS, если по каким-либо причинам скрипт отработал с ошибками.
Если же все в порядке, то вернувшись на закладку DASHBOARD виртуальной сети, созданной в Windows Azure, вы увидите примерно такую картину:
![clip_image034[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0245.clip_image0344_65A6A7FA.png "clip_image034[4]")
Либо она станет такой после нажатия кнопки CONNECT внизу страницы.
Создание ВМ в Windows Azure и проверка конфигурации
Теперь, когда туннель создан, остается проверить конфигурацию.
Для этого давайте создадим ВМ в Windows Azure и попробуем включить эту ВМ в AD локальной инфраструктуры. Шаги достаточно стандартные, в разделе VIRTUAL MACHINES нажимаем NEW и выбираем FROM GALLERY,
![clip_image036[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/5758.clip_image0364_622AA7C1.png "clip_image036[4]")
в качестве гостевой ОС выбираем, например, Windows Server 2012,
![clip_image038[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/2185.clip_image0384_50DC618D.png "clip_image038[4]")
задаем имя ВМ, логин и пароль администратора,
![clip_image040[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0841.clip_image0404_648BDBD2.png "clip_image040[4]")
и убеждаемся, что машина будет подключена к созданной ранее виртуальной сети.
![clip_image042[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/4540.clip_image0424_3F247915.png "clip_image042[4]")
На последней странице оставляем все без изменений.
![clip_image044[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0143.clip_image0444_396BF020.png "clip_image044[4]")
После того как ВМ запустится, можно подключиться к ней по RDP и посмотреть параметры IP. В данном случае видно, что ВМ получила адрес 10.50.1.4 из адресного пространства виртуальной сети, при этом в качестве адреса DNS-сервера указан адрес контроллера домена (192.168.3.200).
![clip_image046[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/8473.clip_image0464_4D1B6A65.png "clip_image046[4]")
Проверим разрешение имен и ping на контроллер домена, если конечно Firewall разрешает ICMP.
![clip_image048[4]](https://msdntnarchive.z22.web.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/59/37/metablogapi/0383.clip_image0484_528EFC6B.png "clip_image048[4]")
Коммуникации настроены, остается просто включить ВМ в домен, и это уже самая обычная процедура, на которой я останавливаться не буду.
Итак, мы прошли все этапы, и теперь наша локальная инфраструктура расширена сетевым сегментом в Windows Azure. В этом сегменте можно создавать дополнительные подсети, запускать ВМ нужной конфигурации, переносить в них требуемые сервисы, настраивать их мониторинг и использовать таким образом ресурсы облака для решения стоящих перед ИТ-департаментом задач.
Я привел достаточно подробное описание настроек для того, чтобы вы смогли при необходимости воспроизвести рассмотренные шаги. Как упоминалось, на сайте Windows Azure вы сможете найти скрипты для разных типов VPN-шлюзов. Но даже если в этом списке нет вашего устройства, вы можете настроить свой шлюз, понимаю логику работы и используемые протоколы и механизмы аутентификации Windows Azure. В общем, лучший способ изучить технологию – попробовать самому. J
Надеюсь, материал был полезен!
Comments
- Anonymous
January 01, 2003
Специально никаких исключений делать не надо. Я бы в первую очередь проверил, что на шлюзе правильно прописан маршрут из внутренней сети в Azure. - Anonymous
January 22, 2014
Александр, подскажите пожалуйста, если наша внутренняя сеть находится за натом, то в таком случае есть необходимость делать какие-то исключения? VPN-туннель устанавливается, но из внутренней в виртуальную сеть Azure мы попасть не можем. Пинг не идет, по рдп не подключается. Брандмауэры отключены.