Облако VMware
Работа с виртуальными машинами через VMware Cloud Director
Работа с виртуальным маршрутизатором EDGE gateway
SaaS-решения
Корпоративная почта
Подключение к ящику через web-интерфейс
Настройка Outlook
Настройка iOS и Android для работы с Exchange
Настройка и работа с общими папками
Настройка стандартного приложения "Почта" в MAC OS X
Настройка Outlook IOS/Android
Создание почтового ящика.
Создание списка рассылки
Настройка фильтров и переадресации писем электронного почтового ящика в panel.flexcloud.ru
Изменение прав доступа к электронному почтовому ящику для других пользователей организации
Ошибка Outlook 0x800ccc1a
Настройки DNS для услуги Hosted Exchange в тестовом периоде.
Настройка Mozilla Thunderbird
Параметры подключения к почтовым серверам Cloud4Y
Как исправить ошибку с кодом -1 при создании нового почтового ящика
Как переслать NDR в Outlook
Как мигрировать данные почтового ящика со стороннего хостера через PST файлы
Как переслать NDR в Thunderbird
Как настроить автоархивацию в Outlook
Перенос почты со стороннего сервера (mail.ru, gmail.com, yandex.ru и т.п.) на сервер Exchange
Подключение по протоколам IMAP/POP3 к Outlook 2016
Настройка The Bat!
Подключение по протоколам IMAP/POP3/MAPI к Outlook 2019 и старших версий
Настройки DNS необходимые для работы Hosted Exchange.

Отказоустойчивая конфигурация IPSec c помощью EDGE Gateway

Прежде, чем вы начнете

Технология создания туннелей GRE была добавлена в NSX 6.4. Данная технология реализована c минимальным функционалом, сервисы IPSec и OSPF не видят GRE интерфейсов, так же отсутствет реализация логирования и мониторинга кроме банального пинга. В настоящее время создание GRE туннелей возможно только администраторами NSX через API Rest. Пользователям vCloud данная функция недоступна.

Однако VMWare реализовали создание шифрованных туннелей через функцию Route-Based IPSec VPN. Данная технология идентична Generic Routing Encapsulation (GRE) over IPSec, за исключением того, что перед применением обработки IPSec к пакету не добавляется дополнительная инкапсуляция. В таблице ниже указанно какие вендоры сетевого оборудования поддерживают эту функцию. Отличие от обычного GRE в методах инкапсуляции – в VTI экономится 4 байта путём исключения GRE-заголовка.

Имя вендора Поддержка Route-Based IPSec VPN
Cisco да
Juniper да
Mikrotik нет

 

Введение

В исходной задаче поставлена цель добиться отказоустойчивости при схеме, когда из удаленного ОФИСА создано два зашифрованных туннеля по одному каналу в строну двух Edge (EDGE-2 и EDGE-3) находящихся в разных датацентрах, но соединенных линией L2. Схему вы можете посмотреть ниже.


Нам необходимо настроить инфраструктуру таким образом, чтоб при потере соединения между ОФИСОМ и одним из EDGE мы смогли сохранить доступность инфраструктуры находящейся в подсетях 10.20.20.0/29 и 10.100.100.0/29. Для этого необходимо выполнить следующие шаги:

  1. Развернуть инфраструктуру в каждом VDC (сети, vApp, VM)
  2. Создать Route-Based IPSec VPN туннели между узлами OFFICE-EDGE-2 и OFFICE-EDGE-3
  3. На узлах EDGE-2 и EDGE-3 создать статические маршруты поверх GRE к OFFICE.
  4. На узле OFFICE создать статические маршруты к EDGE-2 и EDGE-3
  5. Протестировать созданную инфраструктуру на доступность.
  6. Зафиксировать доступность всех узлов в схеме отключив один из тунелей.

Для эргономики восприятия информации все скриншоты относящиеся к тому или иному узлу будут отмечены цветом согласно маске:

  • OFFICE — 45.134.62.220
  • EDGE-2 — 176.53.182.220
  • EDGE-3 — 176.53.182.209

Узел Office представлен в данной статье на EDGE, но вы можете настроить любое поддерживаемое устройство для построения данной схемы.
Также для уменьшения объема информации, дублирование скриншотов с одинаковых узлов будет сведено к минимуму.

Подготовка инфраструктуры

    1. Cоздаем vApp (VAPP_TWO) и ВМ (VM-EDGE-2) в VDC. То же самое делаем для других узлов.

    2. Создаем сеть LAN EDGE-2 10.100.100.0/29 и подключаем ее к EDGE-2. Тоже самое делаем для EDGE-3 (LAN-EDGE-3 10.20.20.0/29) и для Office (192.168.10.0/29)

    3. Переходим в настройки EDGE>VPN>IPSec и выбираем создание IPsec VPN Sites

    4. Создаем Route-Based IPSec согласно матрицы все три узла (со стороны узла Office необходимо настроить два туннеля по одному к каждому узлу EDGE):
      Параметр EDGE-3 EDGE-2 OFFICE
      Name TO Office
      To Office
      To EDGE-1, To EDGE-2
      Local ID 176.53.182.220 45.134.62.220 176.53.182.209
      Peer Subnets 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0
      Encryption Algorithm AES-256 AES-256 AES-256
      Peer Subnets 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0
      Encryption Algorithm AES-256 AES-256 AES-256
      Authentication PSK PSK PSK
      Pre-Shared Key *** *** ***
      Diffie-Hellman Group DH14 DH14 DH14
      Digest Algorithm SHA-256 SHA-256 SHA-256
      IKE Option iKEv-2 iKEv-2 iKEv-2
      Session Type Route-Based Session Route-Based Session Route-Based Session
      Tunnel Interface IP CIDR 172.16.0.2/30 172.10.0.2/30 172.16.0.1/30, 172.10.0.1/30
      Tunnel Interface MTU 1500 1500 1500

       

    5. Настраиваем статические маршруты между созданными туннелями на каждом узле.

      SOURCE NETWORK NEXT HOP DISTANCE
      EDGE-3 to EDGE-2 (L2) 10.100.100.0/29 192.168.3.102 1
      EDGE-3 to Office (VTI) 192.168.10.0/29 172.10.0.1 1
      EDGE-3 to Office через EDGE-2
      192.168.10.0/29
      192.168.3.102
      2
      EDGE-2 to EDGE-3 (L2) 10.20.20.0/29 192.168.3.101 1
      EDGE-2 to Office (VTI) 192.168.10.0/29 172.16.0.1 1
      EDGE-2 to Office через EDGE-3
      192.168.10.0/29
      192.168.3.101
      2

      При создании Static Routes в поле Network указываем подсеть находящуюся за противоположным узлом. В поле Next Hop указываем IP адрес туннеля IPSec противоположного узла.
    6. С узла Office фиксируем доступность подсетей подключенных к EDGE-2 и EDGE-3

    7. Фиксируем прохождение трафика к подсетям через созданные туннели

Проверка доступности после отключения туннеля

    1. Когда все узлы имееют логическую связанность, нам необходимо отключить туннель на маршруте Office > EDGE-2 (172.16.0.0/30) чтоб проверить, что маршрут к подсети находящейся за узлом EDGE-2 будет проходить через EDGE-3. Для этого выключаем IPSec VTI туннель на узле EDGE-2.

    2. Теперь фиксируем, что подсеть на узле EDGE-2 остается доступной, но уже по маршруту через узел EDGE-3


    3. Так же проверяем доступность Office c узла EDGE-2

      Как видим, доступность узла сохранилась, соответствено отказоустойчивость зафиксирована.

Вы уже работаете с сервисами Cloud4Y?

Перейти на вебсайт

Попробовать бесплатно

Вверх!