Подключение Windows Azure IaaS к локальной сети

На внутренней конференции Microsoft из уст самого Марка Руссиновича я узнал, что в составе облачного сервиса Windows Azure наконец-то появился полноценный IaaS (инфраструктура как сервис), который называется Virtual Machines and Virtual Networks.

Ранее в составе Windows Azure предлагался PaaS, который я не воспринимал всерьёз: список предлагаемых сервисов был скуден, а сами сервисы были настолько ограничены, что подходили для создания инфраструктуры небольшой компании с нуля. Я скептически смотрел на возможность создания серьёзных гибридных решений, в которых существующая зрелая on-prem инфраструктура предприятия интегрировалась с облачной.

Теперь же я полон энтузиазма! Windows Azure IaaS — это полноценные виртуальные машины и сети, предоставляемые как облачный сервис и размещённые в датацентрах Microsoft. Если подключить облачную виртуальную сеть к локальной сети предприятия, и развернуть в облаке новые сервера (или мигрировать существующие), это будет работать так же, как в удалённом филиале.

В процессе знакомства с Windows Azure IaaS я встретил несколько неочевидных вещей, о которых хочу рассказать.

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

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

Далее я приведу оптимальный порядок шагов по конфигурации Windows Azure для подключения виртуальных сетей (cloud) к локальной сети (on-prem).

1. Создание подключения к локальной сети: Networks → Local Networks

• Name — имя подключения к локальной сети, нельзя изменить после создания
• VPN Device IP Address — доступный из интернета IP-адрес, нельзя указать доменное имя или список адресов (вот вам и надёжность), но можно редактировать в любое время
• Address Space — список подсетей в локальной сети [например 10.18.0.0/20], после создания можно редактировать

2. Создание виртуальной сети: Networks → Virtual Networks

• Имя — имя подключения виртуальной сети, нельзя изменить после создания
• Affinity Group — служит для группировки ресурсов в пределах одного датацентра таким образом, что они будут напрямую доступны по сети друг для друга. Любая виртуальная сеть должна принадлежать к Affinity Group.
  • Region — выбираем ближайший
  • Affinity Group Name — имя, нельзя изменить после создания
• Address Space — все адресное пространство, которое будет принадлежать данной виртуальной сети [например 10.18.80.0/20], можно указать несколько подсетей, нельзя изменить после создания
• Subnets — подсети из определённого выше адресного пространства [например 10.18.80.0/24, 10.18.90.0/24], именно в данных подсетях можно развёртывать виртуальные машины; после создания виртуальной сети список подсетей можно пополнять в пределах общего адресного пространства
• DNS Servers — список DNS серверов, которые будет выдаваться создаваемым в данной сети виртуальным машинам. Парадоксально, но если в данной виртуальной сети уже развёрнута хоть одна виртуальная машина, данный список нельзя редактировать (даже IP-адреса менять). Поэтому, список DNS-серверов я предпочитаю не заполнять.
• Connectivity = подключение к локальной сети
  • Gateway Subnet = мне до сих пор не понятно, какой в этом параметре практически смысл, но он должен содержать подсеть из общего адресного пространства и не пересекаться с уже определёнными подсетями.
  • Local Network = выбор ранее созданного подключения к локальной сети.

3. Создание виртуальных машин: Virtual Machines

После создания виртуальной сети можно переходить к созданию виртуальных машин. Хочу отметить следующие важные моменты:

• Создавать виртуальные машины нужно через путь New → Virtual Machine → From Gallery, так как Quick Create не позволяет выбрать виртуальную сеть
• Как я писал выше, после создания виртуальной машины, её нельзя подключить к другой виртуальной сети
• После создания хотя бы одной виртуальной машины в виртуальной сети, почти все настройки этой сети будут заблокированы для изменений
• В данный момент виртуальные машины могут иметь только один сетевой интерфейс
• Виртуальные машины Linux в данный момент в пролёте: они не могут быть развёрнуты в виртуальной сети
• IP-адреса для машин назначаются DHCP-сервером Azure из выбранной при их создании подсети. Однако, это не должно смущать (например при развертывании контроллера домена или сервера DNS), так как IP-адрес виртуальнй машины закрепляется за ней на все время её существования.

4. Создание VPN-шлюза в Azure: Networks → Ранее созданная сеть → Create Gateway

Данная операция может занимать длительное время, похоже, в недрах Azure подготавливается полноценный шлюз для VPN-соединений, на н`м настраиваются политики и выделяется публичный IP-адрес.

В итоге, все, что нам предоставляет Azure — это IP-адрес шлюза VPN, ключ для шифрования трафика (shared key) и примеры конфигурационных файлов для настройки VPN-туннеля на некоторых устройствах Cisco и Juniper.

5. Настройка шлюза на стороне локальной сети

Так как ни Cisco, ни Juniper у меня в тестовой инфраструктуре нет, я решил воспользоваться достаточно скудной официальной информацией с требованиями к VPN-устройствам, а также методом обратного инжениринга предлагаемых шаблонов для конфигурации поддерживаемых устройств.

Получились следующие требования для VPN-соединения:

• Публичный IP-адрес для шлюза VPN
• Тип VPN: Site-to-site IPSec, протокол IKEv1
• IKE Phase 1
  • Hash Algorithm: SHA
  • Encryption Algorithm: AES-128
  • Diffie-Hellman Perfect Forward Secrecy (DH PFS) Group: 2
  • Lifetime: 28000
• IKE Phase 2
  • Hash Algorithm: SHA
  • Encryption Algorithm: AES-128
  • DH PFS Group: none
  • Lifetime: 3600
• Исходящие соединения
  • IPsec Security Associations mode: tunnel
  • NAT Traversal (NAT-T): enabled
  • MSS: 1350

У меня имеется роутер Mikrotik — дешёвый, как потребительские сетевые устройства, но сердитый, как Циски. Для поднятия соединения между своей локальной сетью и виртуальной сетью Windows Azure понадобилось сделать следующие настройки:

IP → IPSec → Peers, создать

IP → IPSec → Proposal, создать

IP → IPSec → Policy, создать

IP → Firewall → Filter Rules, создать

Чтобы проверить работу VPN-туннеля нужно иметь уже развернутую в облаке Azure виртуальную машину, так как каким-то причинам внутренние шлюзы Windows Azure на пинги не откликаются.

Ссылки

• Create a Virtual Network for Cross-Premises Connectivity
• Establish a Site-to-Site VPN Connection
• About VPN Devices for Virtual Network
• Windows Azure Virtual Network VPN with TMG 2010

[заметку буду дописывать и полировать]