Подключение Windows Azure IaaS к локальной сети
2012-07-28, 01:00 / ArgonНа внутренней конференции 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
[заметку буду дописывать и полировать]
Рубрика | Azure |
---|---|
Метки | azure, cloud, network |
Опубликовано | 2012-07-28, 1:00; обновлено 2016-09-07, 00:02 |
Комментарии | Нет комментариев » | Лента комментариев RSS |
Ссылки | Постоянная ссылка | Обратная ссылка |