Настройка windows в качестве шлюза

Обновлено: 02.07.2024

Для того чтобы повысить уровень безопасности Windows-сервера бывает недостаточно сменить TCP-порт RDP . Рассмотрим настройку шлюза удаленных рабочих столов (Remote Desktop Gateway / Terminal Services Gateway) в домене Active Directory.

Remote Desktop Gateway, что это?

Remote Desktop Gateway - это роль Windows-сервера, обеспечивающая защищенное соединение, с помощью протокола SSL, с сервером по RDP. Главное преимущество этого решения в том, что не требуется развертывание VPN-сервера, для этого и используется шлюз.

Следует отметить, что начиная с Windows Server 2008 R2, были изменены названия всех служб удаленных рабочих столов. Именуемые ранее службы Terminal Services были переименованы в Remote Desktop Services.

Преимущества Remote Desktop Gateway в следующем:

Используя зашифрованное соединение, шлюз позволяет подключаться к внутренним сетевым ресурсам без необходимости использования VPN-соединения удаленными пользователями;
Шлюз дает возможность контроля доступа к определенным сетевым ресурсам, тем самым реализуя комплексную защиту;
Шлюз разрешает подключение к сетевым ресурсам, которые размещены за межсетевыми экранами в частных сетях или NAT;
С помощью консоли диспетчера шлюза появляется возможность настраивать политики авторизации для тех или иных условий, которые должны быть выполнены при подключении к сетевым ресурсам удаленными пользователями. В качестве примера, можно указать конкретных пользователей, которые могут подключаться к внутренним сетевым ресурсам, а также должен ли клиентский компьютер при этом быть членом группы безопасности AD, допустимо ли перенаправление устройства и диска;
Консоль диспетчера шлюза содержит инструменты, предназначенные для отслеживания состояния шлюза. Используя их, вы можете назначить отслеживаемые события для аудита, например, неудачные попытки подключения к серверу шлюза служб терминалов.

Важно! Шлюз служб терминалов должен входить в домен Active Directory. Настройка шлюза выполняется только от имени администратора домена, на любом сервере в домене.

С появлением в Windows Azure технологий виртуальных машин (ВМ) и виртуальных сетей реализация гибридных сценариев, когда часть локальной инфраструктуры переносится в облако или расширяется за счет ресурсов облака, становится вполне выполнимой задачей. Подобные сценарии предполагают наличие туннеля между локальной сетью предприятия и облаком. В этом посте я покажу, каким образом строится такой Site-to-Site (S2S) туннель в случае, когда в качестве облака выступает Windows Azure, а шлюзом в локальной сети является сервер под управлением Windows Server 2012 R2. Будет много картинок.

Давайте представим себе, что некоторая компания заинтересована в расширении своей локальной ИТ-инфраструктуры и хотела бы перенести часть нагрузок в Windows Azure. Для нас сейчас не принципиально, что конкретно будет переезжать в облако: веб-сервер, база данных, портал SharePoint или что-то еще. Важно, чтобы виртуальные машины, развернутые в Windows Azure, «виделись» как часть локальной инфраструктуры Active Directory (AD), были включены (или могли быть включены) в домен и по сути представляли собой просто еще один сегмент корпоративной сети.

Планируемая конфигурация выглядит следующим образом:

Точнее слева на рисунке то, что уже есть, справа то, что предстоит сделать.

В первую очередь мы создадим в Windows Azure виртуальную сеть с именем VPNnet01. В этой сети необходимо предусмотреть как минимум две подсети – одна (можно несколько) для ВМ, вторая для построения туннеля в локальную AD. Наличие выделенной подсети для шлюза является требованием Windows Azure.

Затем организуем туннель между созданной виртуальной сетью и локальной инфраструктурой, причем сначала этот туннель настраивается со стороны Windows Azure, потом со стороны локальной сети.

Наконец, создадим ВМ в Windows Azure и убедимся, что эта виртуальная машина доступна из локальной сети и наоборот, ВМ может взаимодействовать с контроллером домена, расположенным локально.

Создание виртуальной сети в Windows Azure
Настройка шлюза в Windows Azure
Настройка Windows Server 2012 R2 в качестве S2S-шлюза в локальной сети
Создание ВМ в Windows Azure и проверка конфигурации

Итак, необходимо зайти на портал управления Windows Azure и выбрать в разделе NETWORKS создание новой виртуальной сети, нажав кнопку NEW.

Задаем имя виртуальной сети и выбираем AFFINITY GROUP, которая позволяет расположить ваши ВМ в рамках одного ЦОД Windows Azure для сокращения задержек в сети. Если ни одной AFFINITY GROUP у вас еще нет, вам предложено будет такую группу создать.

На следующей странице необходимо задать имя и IP-адрес сервера(-ов) DNS. Строго говоря, это поле не является обязательным, и его можно заполнить/изменить позже. Но для нашего сценария вся информация о DNS уже есть. Поскольку мы планируем использовать ВМ в Windows Azure как часть AD предприятия, то здесь я указываю имя и IP-адрес контроллера домена, традиционно выполняющего и роль DNS-сервера. Все создаваемые в этой сети ВМ автоматически получат именно этот адрес в качестве адреса DNS-сервера. Если поле оставить пустым, то создаваемые впоследствии ВМ будут использовать для разрешения имен службу DNS Windows Azure и при этом, разумеется, включить такие машины в домен не получится. Технически вы сможете потом зайти на конкретную ВМ, например, с помощью RDP и вручную изменить адрес DNS, но предлагаемый на данной странице вариант гораздо удобнее. Кроме того, надо заметить, что вообще не рекомендуется что-либо менять вручную в настройках TCP/IP виртуальных машин. Этими настройками управляет Windows Azure, чтобы вы, в свою очередь, имели надежный доступ к вашим машинам.

Второй важный параметр на странице – чекбокс Configure site-to-site VPN, который нужно не забыть отметить.

NAME – имя сайта, оно может быть произвольным и лишь идентифицирует набор настроек, который на данной странице мы и формируем;
VPN DEVICE IP ADDRESS – внешний IP-адрес VPN-шлюза в локальной сети предприятия, применительно к рассматриваемому сценарию это IPv4-адрес на внешнем сетевом интерфейсе машины с Windows Server 2012 R2;
ADDRESS SPACE – адресное пространство локальной сети или той ее части, к которой хотим предоставить доступ из Windows Azure.

На странице Virtual Network Address Spaces необходимо сформировать виртуальное адресное пространство создаваемой виртуальной сети. ВМ в облаке будут получать IP-адреса как раз из этого пространства. Указав адресный диапазон всей сети, нужно затем разбить его на подсети. Напомню, что требуется как минимум две подсети: для ВМ и шлюза соответственно. В каждой виртуальной сети может быть только одна подсеть шлюза.

Нажимаем кнопку “Complete” и ждем завершение процесса создания виртуальной сети.

Собственно на этом первый этап завершен, и мы можем переходить к настройке шлюза Windows Azure.

После того как сеть создана, щелкаем по ней и видим закладку DASHBOARD.

В меню в нижней части экрана нажимаем CREATE GATEWAY и выбираем Dynamic Routing. Два типа маршрутизации поддерживает на текущий момент Windows Azure. Статическая маршрутизация основана на заданных пользователем политиках (списках доступа), динамическая – на заданных маршрутах и туннельном интерфейсе (любой пакет, попадающий на туннельный интерфейс, пересылается через VPN-туннель). В случае динамической маршрутизации, соответственно, если IP-диапазоны виртуального и локального адресных пространств при создании виртуальной сети в Windows Azure были заданы корректно (не пересекаются, не дублируются и пр.), то пакеты должны правильным образом маршрутизироваться между Windows Azure и локальной инфраструктурой.

Выбор типа маршрутизации определяется тем, какой шлюз используется на стороне локальной инфраструктуры. В документации в разделе Known compatible VPN devices можно посмотреть список поддерживаемых шлюзов и соответствующих им типов маршрутизации.

Остается ждать, пока Windows Azure настроит шлюз. Этот процесс занимает в среднем 15-20 мин.

По окончании на странице можно увидеть внешний IP-адрес созданного в Windows Azure шлюза, и этот адрес следует использовать в качестве конечной точки подключения при настройке шлюза в корпоративной сети.

Для определенных моделей шлюзов (VPN-устройств), в том числе для службы RRAS в Windows Server 2012/R2, Windows Azure может сгенерировать скрипт, который затем необходимо запустить на VPN-устройстве и тем самым сконфигурировать это устройство для организации туннеля в Windows Azure. Чтобы загрузить такой скрипт нужно создать ключ, используемый для туннельной аутентификации, нажав MANAGE KEY,

а затем щелкнуть по ссылке Download VPN Device Script справа на странице.

В открывшемся окне выберете производителя шлюза, платформу и операционную систему и загрузите скрипт.

Теперь полученный скрипт необходимо перенести на VPN-устройство и выполнить настройку.

Следует убедиться в том, что полученный на предыдущем этапе скрипт содержит корректные значения адресного пространства виртуальной сети и внешнего адреса шлюза Windows Azure. Эти значения выделены в приведенном фрагменте скрипта.

Если все верно, остается просто запустить это скрипт на машине с Windows Server 2012 R2, которая будет выполнять роль шлюза. Подчеркиваю, выше приведен лишь фрагмент. Запускать надо, конечно, весь скрипт целиком, причем под учетной записью с правами администратора. Например, это можно сделать в PowerShell ISE.

По приведенному фрагменту видно, что скрипт устанавливает и настраивает службу Routing and Remote Access Services (RRAS). Давайте посмотрим, как выглядят некоторые настойки RRAS после успешного выполнения скрипта.

Во-первых, в разделе Network Interfaces можно заметить интерфейс с именем, соответствующим внешнему IP-адресу шлюза в Windows Azure, причем состояние этого интерфейса должно быть Connected. Если это не так, щелкните по нему правой кнопкой мыши и в контекстном меню выберете Connect.

В свойствах этого интерфейса, используемого, как вы понимаете, для построения туннеля, мы найдем IP-адрес шлюза Windows Azure,

а также на закладке Security используемый протокол (IKEv2) и сгенерированный в Windows Azure ключ.

Кроме того, в разделе Static Routes появился статический маршрут, пересылающий по туннелю все пакеты с адресами получателя, принадлежащими виртуальной сети Windows Azure.

Сам RRAS-сервер сконфигурирован в качестве маршрутизатора, в чем можно убедиться посмотрев его свойства.

Используя приведенную информацию, вы сможете вручную настроить службу RRAS, если по каким-либо причинам скрипт отработал с ошибками.

Если же все в порядке, то вернувшись на закладку DASHBOARD виртуальной сети, созданной в Windows Azure, вы увидите примерно такую картину:

Либо она станет такой после нажатия кнопки CONNECT внизу страницы.

Теперь, когда туннель создан, остается проверить конфигурацию.

Для этого давайте создадим ВМ в Windows Azure и попробуем включить эту ВМ в AD локальной инфраструктуры. Шаги достаточно стандартные, в разделе VIRTUAL MACHINES нажимаем NEW и выбираем FROM GALLERY,

в качестве гостевой ОС выбираем, например, Windows Server 2012,

задаем имя ВМ, логин и пароль администратора,

и убеждаемся, что машина будет подключена к созданной ранее виртуальной сети.

На последней странице оставляем все без изменений.

После того как ВМ запустится, можно подключиться к ней по RDP и посмотреть параметры IP. В данном случае видно, что ВМ получила адрес 10.50.1.4 из адресного пространства виртуальной сети, при этом в качестве адреса DNS-сервера указан адрес контроллера домена (192.168.3.200).

Проверим разрешение имен и ping на контроллер домена, если конечно Firewall разрешает ICMP.

Коммуникации настроены, остается просто включить ВМ в домен, и это уже самая обычная процедура, на которой я останавливаться не буду.

Итак, мы прошли все этапы, и теперь наша локальная инфраструктура расширена сетевым сегментом в Windows Azure. В этом сегменте можно создавать дополнительные подсети, запускать ВМ нужной конфигурации, переносить в них требуемые сервисы, настраивать их мониторинг и использовать таким образом ресурсы облака для решения стоящих перед ИТ-департаментом задач.

Я привел достаточно подробное описание настроек для того, чтобы вы смогли при необходимости воспроизвести рассмотренные шаги. Как упоминалось, на сайте Windows Azure вы сможете найти скрипты для разных типов VPN-шлюзов. Но даже если в этом списке нет вашего устройства, вы можете настроить свой шлюз, понимаю логику работы и используемые протоколы и механизмы аутентификации Windows Azure. В общем, лучший способ изучить технологию – попробовать самому. :)

Надеюсь, материал был полезен!

20.11.2014

Windows Server 2012 R2

комментариев 19

В этой статье посмотрим, как с помощью встроенных средств на базе сервера с Windows Server 2012 R2 организовать простой межсетевой маршрутизатор. И хотя на практике маршрутизаторы на базе компьютеров используются довольно редко (аппаратные маршрутизаторы, как правило, имеют более высокую производительность, надежность и несколько дешевле выделенного компьютера), в тестовых или виртуальных средах, когда нужно срочно настроить маршрутизацию между несколькими подсетями, маршрутизатор на базе Windows Server вполне себе приемлемое решение.

Итак, в роли маршрутизатора будет выступать сервер с ОС Windows Server 2012 R2. Сервер имеет 2 сетевых интерфейса: физических или виртуальных, если сервер запущен на гипервизоре. Каждому интерфейсу сервера назначен выделенный IP адрес из различных подсетей. Для удобства, мы переименовали названия сетевых интерфейсов в Панели управления сетями и общим доступом:

Сетевая карта 1 (сетевая карта подключена во внутреннюю LAN сеть):

Имя: LAN

IP: 10.0.1.1

Сетевая карта 2 (сетевая карта во внешней сети ):

Имя: Internet

IP: 192.168.1.20

Наша задача – организовать маршрутизацию пакетов из локальной подсети 10.0.1.0 во внешнюю подсеть 192.168.1.0 (как правило, такая сеть имеет выход в интернет) через NAT. Такую схему можно реализовать в случае необходимости организации доступа клиентов из внутренней сети в интернет.

Маршрутизация в Windows Server 2012 R2 реализуется на базе роли Remote Access (RRAS). Данная служба появилась еще в Windows Server 2003 и до текущей в версии Windows Server ее интерфейс и процесс настройки практически не изменился.

Совет. Ранее мы показывали, как с помощью данной службы создать VPN сервер на базе 2012 R2 и настроить DHCP-relay агент.

В первую очередь нужно установить роль Remote Access. Для этого откроем консоль Server Manager, выбираем Manage -> Add Roles and Features, находим и отмечаем роль Remote Access, в ее составе выбираем службу Routing, и, соглашаясь со всеми предложенными по умолчанию компонентами, запускаем ее установку (Install).

После окончания установки открываем консоль Routing and Remote Access (rrasmgmt.msc), щелкаем по имени сервера (с красной стрелкой) и выбираем Configure and Enable Routing and Remote Access.

В открывшемся окне выбираем пункт Network Address Translation (NAT).

На следующей шаге (NAT Internet Connection) нужно выбрать сетевой интерфейс, подключённый ко внешней сети / Интернету (в нашем примере это интерфейс Internet с ip 192.168.1.20). Этот интерфейс будет «публичным интерфейсом» нашего NAT роутера.

Далее будет предложено указать должен ли NAT роутер обеспечить клиентов внутренней сети сервисами DHCP и DNS. Как правило, этот функционал во внутренней сети уже имеется, поэтому в нем мы не нуждаемся.

На этом базовая настройка маршрутизации на Windows Server 2012 R2 завершена. Сервер уже должен выполнять маршрутизацию пакетов между двумя подключенными сетями и выполнять трансляцию сетевых адресов (NAT).

Чтобы в этом убедиться, в консоли RRAS откройте свойства сервера. На вкладке General показано, что IPv4 маршрутизация включена (т.е. пакеты IPv4 будут пересылаться с одной сетевой карты на другую).

Проверить работу маршрутизации можно, указав на клиентском компьютере во внутренней сети (к которой подключен интерфейс сервера LAN) в качестве шлюза IP-адрес сервера (10.0.1.1), и выполнить ping или трассировку маршрута к ресурсу, расположенному во внешней сети или интернете. Эти попытки должны быть успешными.

Примечание. Windows Server 2012 R2 поддерживает статическую маршрутизацию, протокол динамической маршрутизации RIPv2 и BGPv4. Поддержка OSPF была прекращена еще в Windows Server 2008.

В нашем случае на сервере осуществялется статическая маршрутизация. Если нужно добавить новый маршрут, щелкните ПКМ по Static Routes, выберите пункт меню New static route и создайте новое статическое правило маршрутизации.

Сказать по правде, эту статью я не хотел писать в принципе. Делать подобное – не более, чем извращение в широком смысле этого слова. Однако иногда приходится делать интернет-шлюз на базе обычной клиентской версии Windows.

Вообще, обычно для этих целей выделяют простенькую машину, на которую заливают серверную версию nix (тут реализаций может быть несколько, на выбор админа), дабы раз «поднять» шлюз и все. Благодаря тому, что все в nix системах регулируется скриптами и конфигурационными файлами, подобный сервер становится почти надежным решением. Кроме того, в таком решении легко развернуть тот же squid для шейпинга интернета и запрета некоторых сайтов и т.д. Благодаря консольному виду (хотя, признаться честно, иногда и я сам ставлю простенький X сервер для того, чтобы техники из техподдержки хотя бы немного делали то, что я хочу от них) «продвинутые» пользователи навряд ли полезут туда, где «че то с экраном не то. Какие-то буковки на экране», что исключает фактор влезания не туда, куда надо. Кроме того, главным источником глюков всех времен и народов была и остается графическая подсистема. Без нее непонятных ошибок просто не возникнет.

Однако вариант с тем же Линуксом мало устраивает небольшие конторки, где парк машин не более 10 штук. Часто «админить» такой парк берется либо сам руководитель, либо кто-то из продвинутых сотрудников. В итоге о серверных осях они, в лучшем случае, только слышали. Тем не менее, в подобных случаях они все же хотят некое подобие недосервера у себя в офисе.

Преимущества такого решения налицо – можно использовать привычную Windows, в случае дополнительных функций обвешать ее опенсорсными программами типа DHCP сервера, брэндмауэрами с интуитивным графическим интерфейсом типа Kerio и т.д. Если это действительно небольшой офис, то подобное решение имеет право на жизнь, так как серверный Windows приобретать глупо и бессмысленно, а свободных «красноглазиков» (линуксоидов) все же не так много, как хотелось бы.

Если вы читаете данную статью, то первым вашим шагом на пути создания интернет-шлюза на базе Windows будет как раз организация раздачи интернета в локальную сеть. Для этого вам понадобятся две сетевые карты – одна для получения интернета, другая, собственно, для раздачи.

Естественно, что на них должны стоять драйвера. Теперь вам нужно определиться с тем, какая карточка будет выполнять свою роль и воткнуть в них патчкорды. Здесь все достаточно просто. Теперь нужно настроить Windows.

Я рекомендую использовать Windows XP как наиболее простую и относительно надежную ось для этих целей. Просто при использовании той же Windows 7 иногда бывают проблемы «отваливания» компьютеров из сетевого окружения, что нам ни к чему. Вам нужно будет настроить специальным образом сетевые карточки.

Для этого зайдите в панель управления ->Сетевые подключения и выберите там сетевую карту, которая должна принимать интернет. Если вы получаете интернет по VPN подключению, то нужно использовать именно VPN подключение!

Теперь нажмите правой кнопкой мышки на нужную сетевую карту, нажмите пункт «Свойства» и выберите вкладку Дополнительно.

Теперь найдите раздел Общий доступ к подключению к Интернету и и поставьте галочки как на скриншоте. В окошке подключение домашней сети нужно выбрать вашу вторую сетевую карту, которая будет раздавать интернет. После этого нажимаете OK и ждете пока система не сконфигурирует вторую карту.

В принципе, на шлюзе это все. Карте, что смотрит в сеть присвоятся ip 192.168.0.1 и маска 255.255.255.0. Заметьте, что в нашем случае появляется даже DHCP сервер, который будет динамически присваивать айпишники новым компьютерам в сети. Но лучше настраивать их вручную.

Здесь все просто – в качестве основного шлюза мы пописываем 192.168.0.1., маску указываем ту же самую, а сам IP можно назначить любым из диапазона 192.168.0.2 до 192.168.0.255. В качестве DNS просто укажите 192.168.0.1

Если вы все сделали по моей инструкции, то поздравляю – вы только что подняли «недосервер» интернет-шлюза. Теперь на него можно ставить сторонние программы и обслуживать малый офис.

Локальный шлюз данных — это программное обеспечение, которое вы устанавливаете в локальной сети. Шлюз облегчает доступ к данным в этой сети.

Как мы объясняем в обзоре, вы можете установить шлюз либо в личном режиме, который относится только к Power BI, или в стандартном режиме. Мы рекомендуем стандартный режим. В этом режиме шлюз можно установить автономно или в добавить кластер. Мы рекомендуем второй вариант, так как он обеспечивает высокий уровень доступности.

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

Требования

Минимальные требования

Минимальное разрешение экрана, поддерживаемое для локального шлюза данных, составляет 1280 x 800.

Связанные соображения

Шлюзы не поддерживаются в установках Server Core.
Шлюзы не поддерживаются в контейнерах Windows.
Пользователь, устанавливающий шлюз, должен быть администратором шлюза.
Шлюз нельзя устанавливать на контроллер домена.
Если вы планируете использовать проверку подлинности Windows, установите шлюз на компьютере, входящем в ту же среду Active Directory, что и источники данных.
Не устанавливайте шлюз на компьютере, например, ноутбук, который может отключиться, перейти в спящий режим или быть отключен от Интернета. Шлюз не может работать ни в одном из таких случаев.
Если шлюз используется беспроводную сеть, его производительность может снизиться.
Вы можете установить другие приложения на компьютере шлюза, но это может понизить производительность шлюза. Если вы все же устанавливаете другие приложения на компьютер шлюза, обязательно внимательно следите за шлюзом, чтобы проверить, нет ли конфликта ресурсов.
На одном компьютере можно установить до двух шлюзов: один работает в персональном режиме, а другой — в стандартном. На одном компьютере не может быть два шлюза, работающих в одном режиме.
Локальный шлюз данных (стандартный режим) должен быть установлен на компьютере, подключенном к домену с доверительными отношениями с целевым доменом.

Загрузка и установка стандартного шлюза

Так как шлюз работает на компьютере, на котором он установлен, обязательно установите его на компьютер, который всегда будет включен. Для повышения производительности и надежности мы рекомендуем подключать этот компьютер к проводной сети, а не к беспроводной.

Локальный шлюз данных (стандартный режим) должен быть установлен на компьютере, подключенном к домену с доверительными отношениями с целевым доменом.

В установщике шлюза оставьте путь установки по умолчанию, примите условия использования и выберите Установить.

Введите адрес электронной почты для вашей учетной записи организации Office 365, затем выберите Войти.

Шлюз связан с вашей учетной записью организации Office 365. Вы управляете шлюзами из соответствующей службы.

Итак, вы вошли в учетную запись.

Введите имя для шлюза. Имя должно быть уникальным для клиента. Кроме того, введите ключ восстановления. Этот ключ потребуется в том случае, если вы решите восстановить или переместить шлюз. Выберите Настроить.

Обратите внимание на флажок Добавить в существующий кластер шлюза. Мы будем использовать этот флажок в следующем разделе этой статьи.

Также обратите внимание, что вы можете изменить регион, соединяющий шлюз с облачными службами. Дополнительные сведения см. в разделе Выбор региона центров обработки данных.

Для национальных облаков в настоящее время мы поддерживаем установку шлюзов только в регионе PowerBI по умолчанию вашего клиента. Средство выбора региона в установщике поддерживается только для общедоступного облака.

Наконец, вы также можете предоставить свои собственные данные ретранслятора Azure Relay. Дополнительные сведения о том, как изменить сведения о Azure Relay, см. в разделе Задание Azure Relay для локального шлюза данных.

Просмотрите сведения, представленные на последнем экране. Поскольку в этом примере используется та же учетная запись для Power BI, Power Apps и Power Automate, шлюз доступен для всех трех служб. Выберите Закрыть.

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

Добавление второго шлюза для создания кластера

Кластер позволяет администраторам шлюза избежать единой точки отказа в системе доступа к локальным данным. Если основной шлюз данных станет недоступен, все запросы будут направляться на второй добавленный шлюз и т. д.

Так как на компьютере можно установить только один стандартный шлюз, для установки каждого дополнительного шлюза в кластере потребуется другой компьютер. Это требование — разумный подход, так как избыточность всегда полезна для кластера.

Шлюзы кластера, находящиеся в состоянии "не в сети", отрицательно влияют на производительность. Эти участники должны быть удалены или отключены.

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

Для создания кластеров шлюзов высокой доступности вам потребуется обновление за ноябрь 2017 года или более позднее обновление программного обеспечения шлюза.

Скачайте шлюз на другой компьютер и установите его.

После входа в свою учетную запись организации Office 365, зарегистрируйте шлюз. Выберите Добавить в существующий кластер. В списке Доступные кластеры шлюзов выберите основной шлюз, который является первым шлюзом, который вы установили. Введите ключ восстановления для этого шлюза. Выберите Настроить.

Загрузка и установка шлюза в персональном режиме

В установщике шлюза введите путь установки по умолчанию, примите условия использования и выберите Установить.