Настраиваем Site-to-Site IPsec-туннель между облаком Windows Azure и D-Link DFL-210

  • Tutorial
Приветствую!

В данной статье я поэтапно опишу весь процесс настройки Site-to-Site туннеля между облаком Windows Azure и межсетевым экраном D-Link DFL-210 (актуально для линейки устройств DFL: 210\260E\800\860E)

Внимание! Все этапы настройки сопровождаются большим количеством картинок!



Этап 1. Настройка Windows Azure



Для начала создадим новую виртуальную сеть Windows Azure используя мастер
Картинка

Имя: Habratest
Новая территориальная группа: Habragroup
Регион: Западная Европа

Картинка

Затем вводим имя и адрес локального ДНС (при необходимости). Иначе, используем ДНС от Windows Azure, либо любой общедоступный
Ставим галку «Настроить подключение VPN типа «сеть-сеть»»
Картинка

На следующем шаге вводим настройки нашего DFL:
Имя: Mydfl
IP-адрес VPN-устройства: 78.153.146.110 — это выделенный статический IPv4-адрес нашего DFL (Это важно. Если DFL за NAT, то у нас ничего не получится)
Адресное пространство: 192.168.22.0/24 — локальная подсеть, которую мы будем соединять с Windows Azure

Картинка

На последнем шаге вводим настройки подсети, к которой мы будем подключаться (будет использоваться для сервисов, созданных в Windows Azure)
В нашем случае настройки будут следующими:
Общее адресное пространство виртуальной сети: 172.16.80.0/24
Подсеть:
AzureSubnet 172.16.80.0/27
Шлюз 172.16.80.32/29

Картинка

Виртуальная подсеть создана!

Переходим в "Настройки" вновь созданной виртуальной сети и проверяем, что мы все правильно сделали
Картинка


На вкладке "Панель мониторинга" видим следующую картину
Картинка

Жмем кнопку «Создать шлюз» внизу страницы и выбираем режим «Статической маршрутизации». Подтверждаем свои намерения кнопкой «Ок»
Картинка

Ждем 10-15 минут пока Windows Azure создаст для нас шлюз

…Прошло от 10 до 15 минут…

Итак, шлюз создан. Смотрим, что же нам предоставил Windows Azure:
IP-адрес шлюза: 23.97.132.122
Картинка

Далее жмем кнопку «Управление ключами» внизу страницы и получаем наш персональный pre-shared key:
R9GrgLgZPosdZ7isMdt8MkrDQnfBwUbO
Картинка


Этап 2. Настройка DFL



Общие требования к шлюзу можно посмотреть здесь:
http://msdn.microsoft.com/ru-ru/library/windowsazure/jj156075.aspx#BKMK_VPNGateway

Здесь надо сделать одно очень важное замечание
В российской прошивке DFL (установлена по умолчанию) не доступны такие замечательные методы шифрования как AES, которые использует Windows Azure (и не только) для своей работы. Обсуждения на эту тему оставим за рамками данной статьи и воспользуемся следующим приемом:
Идем по ссылке http://tsd.dlink.com.tw/
Выбираем из списка свою модель DFL и загружаем самую последнюю WorldWide прошивку для нашего устройства (обозначается «For WW»)
Загружаем прошивку в наш DFL и ждем завершения операции
Прошивка загружена и мы можем продолжать


Теперь давайте добавим все IP-адреса облака в справочник («Objects->Address book->InterfaceAddresses):
Имя: Habratest_cloud_gateway
Значение: 23.97.132.122
Имя: Habratest_cloud_subnet
Значение: 172.16.80.0/24

Картинка

Затем переходим «Objects->Authentication Objects» и добавляем новый объект типа «Pre-shared key»:
Имя: Habratest_cloud_key
Passphrase: R9GrgLgZPosdZ7isMdt8MkrDQnfBwUbO

Картинка

Далее переходим в пункт «Objects->VPN Objects->IKE Algorithms» и создаем новый алгоритм IKE:
Имя: Habratest_cloud_stage1
Ставим галки: 3DES и AES(128 128 256), а так же галку SHA1

Картинка

После создания IKE-алгоритма переходим к созданию IPsec-алгоритма («Objects->VPN Objects->IPsec Algorithms»):
Имя: Habratest_cloud_stage2
Галки: те же, что и у IKE

Картинка

Теперь переходим непосредственно к созданию правила для IPsec-туннеля («Interfaces->IPsec»):
Вкладка «General»
Имя: Habratest_cloud_IPsec
Local Network: lannet
Remote Network: Habratest_cloud_subnet
Remote Endpoint: Habratest_cloud_gateway
Encapsulation mode: Tunnel (важная настройка!)


IKE Config Mode Pool: None
IKE Algorithms: Habratest_cloud_stage1
IKE Lifetime: 28800


IPsec Algorithms: Habratest_cloud_stage2
IPsec Lifetime: 3600 sec
IPsec Lifetime: 102400000 Kb

Картинка

Вкладка «Authentication»
Ставим точку «Pre-shared key» и выбираем наш «Habratest_cloud_key
Картинка

Вкладка «IKE Settings»
IKE:
Main — DH Group 2
PFS — None
Security Association: Per Net
NAT Traversal: On if supported and NATed
Dead Peer Detection: Use

Картинка

Затем создаем два IP-Правила («Rules->IP Rules»):
Правило1:
Имя: lan_to_cloud
Action: Allow
Service: All_service
Schedule: None
Source interface: lan
Source Network: lannet
Destination Interface: Habratest_cloud_IPsec
Destination Network: Habratest_cloud_subnet

Картинка

Правило2:
Имя: cloud_to_lan
Action: Allow
Service: All_service
Schedule: None
Source interface: Habratest_cloud_IPsec
Source Network: Habratest_cloud_subnet
Destination Interface: lan
Destination Network: lannet

Картинка


Вот мы и создали основные настройки для туннеля. Теперь сохраняем и применяем внесенные изменения на DFL

Вот и все! Наблюдаем красивые картинки поднятого туннеля
Картинка



Далее можно создавать необходимые сервисы в Windows Azure (виртуальные машины, базы данных, etc)



Немного о возможных ошибках в логах DFL:
1. statusmsg=«No proposal chosen» — не правильно выбраны методы шифрования
2. reason=«Invalid proposal» — то же, что и п.1
3. reason=«IKE_INVALID_COOKIE» — туннель уже был поднят, но после этого были внесены изменения в его настройки. Заходим на DFL «Status->IPsec->Habratest_cloud_IPsec->справа вверху страницы List all active IKE SAs» и удаляем устаревший IKE SA. Перезагружаем DFL
Картинка



На этом все. Не забудьте поменять тестовые данные из статьи (IP-адреса, подсети, регионы, ключи pre-shared key) на свои

Спасибо за внимание!

P.S. Прошу обратить внимание на комментарий хабраюзера DikSoft, который сообщает, что такой сценарий официально неподдерживаемый и могут быть проблемы
  • +12
  • 17,8k
  • 6
Поделиться публикацией

Комментарии 6

    0
    С предыдущей редакцией шлюза Azure мы столкнулись с тем, что после его обновления пришлось менять настройки Site-to-Site VPN на своей локальной стороне. Для чего пришлось здорово повозиться с настройками TMG 2010 SP3. При этом вариант соединения с TMG 2010 без обновлений и вовсе оказался недоступным к реализации. Да, это неподдерживаемый официально вариант, но ни Windows 2012, смотрящего одним портом в Интернет, ни Cisco ни Juniper «железок» у нас просто не было.
    Данное решение, как и то, что мы использовали — отличный временный вариант, хотелось бы упоминания в статье, об этом факторе.
    За трюк и ссылки с прошивкой — отдельное спасибо! Мы почему-то до этого не додумались, и DFL-860 отбросили почти сразу.

    Кстати, как по-вашему, насколько вероятен вариант остаться без шлюза после очередного Upgrade платформы Azure?
      0
      Добавил ваше замечание в статью.

      О вероятности падения шлюза ничего не могу сказать, так как на постоянной основе мой шлюз работает не более семи дней.
      Так же, я обязательно упомяну о стабильности данной связки как только пройдет очередное обновление платформы Windows Azure
        0
        Ну, я не берусь категорически утверждать, что оно (решение) упадет после обновления. Правильнее было бы сказать о «возможной недолговечности» в силу того, что это официально неподдерживаемый сценарий.
          0
          Как и обещал — пишу о стабильности.
          К сожалению, я не заметил было ли за это время (почти 2 месяца с момента написания статьи) обновление Windows Azure или нет, но могу заявить следующее:
          1. Связка DFL-210 <->Gateway Windows Azure работают без нареканий. Никаких изменений в конфиг после первоначальной настройки внесено не было.
          2. Бывают разрывы связи, но они редки и не продолжительны по времени (всего несколько секунд по заверению Zabbix'а)
          3. За время работы шлюза у меня было пару сложных моментов с Windows Azure, но с самим шлюзом это связано не было (переход с фри-триала на постоплатный тариф через ТП)
          4. Отдельно хочу отметить скорость и качество работы техподдержки Windows Azure — ребята работают первоклассно! Но будьте готовы к тому, что ТП общается только на английском.
          +1
          Хочу добавить ссылку на описание требований к VPN адаптерам
          msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx

          вендоров там чуть больше, чем два. Если устройство соответствует требованиям, то можно рассчитывать, что после апгрейда платформы шлюз не упадет.
            +1
            В статье есть ссылка на русскую версию
              +1
              — Хорошая новость.
              Добавились Watchguard, F5 и Citrix. Подскажите, а «народные» вендоры рассматриваются, как партнеры продвижения Azure?
              Для новых вендоров (я сейчас не имею возможности проверить) скрипты настройки тоже генерируются?

              Появилась табличка с точными настройками — тоже правильный шаг. При настройке TMG мне приходилось параметры IPsec восстанавливать из скрипта для Cisco.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое