Как настроить шлюз в windows server

Обновлено: 07.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. Настройка шлюза выполняется только от имени администратора домена, на любом сервере в домене.

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 и создайте новое статическое правило маршрутизации.

Постановка задачи

Я хочу вас научить производить настройку статического IP адреса, маски, шлюза и DNS серверов на вашем сетевом интерфейсе, разными методами, локально и удаленно. Ситуаций может быть очень много. Лично я являюсь приверженцем того, что любой сервер должен иметь выделенный, статический ip-адрес исключительно под него, тут можно долго спорить, что можно делать резервирование на DHCP, через который потом можно быстрее менять настройки, но я придерживаюсь такой политики, так как из отказоустойчивый DHCP может ломаться, если вы можете меня переубедить в моем видении, то прошу в комментарии.

Методы настройки сети в Windows Server 2019

Существует ряд методов и инструментов позволяющих производить настройки вашего сетевого интерфейса, их можно разделить на два подхода:

Локальная настройка сетевых параметров
Удаленная настройка сетевыми параметрами

Среди инструментов можно выделить:

Свойства сетевого интерфейса
Утилита командной строки netsh
Командлеты powerShell
Использование Windows Admin Center
Различные утилиты

Настройка сети через графический интерфейс

Первый метод, можно назвать классическим, так как он самый простой и подойдет для большинства администратором. Тут мы с вами будем использовать оснастку "Центр управления сетями и общим доступом", настроим статический IP-адрес, маску сети, основной шлюз и DNS-сервера через графический интерфейс. У меня есть сервер RDCB01, для которого я выделил IP-адрес 192.168.31.10. На текущий момент айпишник прилетает от DHCP-сервера. Проверим текущие параметры интерфейса через командную строку, в которой нужно написать команду:

Чтобы открыть "Центр управления сетями и общим доступом" со списком сетевых интерфейсов, мы воспользуемся быстрыми командами Windows. Открываем окно выполнить и пишем в нем:

Находим нужный сетевой интерфейс, в моем примере, это единственный Ethernet0 и заходим в его свойства.

Далее находим пункт "IP версии 4 (TCP/Ipv4)"и открываем его свойства, далее мы видим, что выделение сетевых настроек производится в автоматическом режиме, через службу DHCP.

Чтобы вбить статические настройки выбираем пункт "Использовать следующий IP-адрес" и по порядку задаем настройки, подготовленные заранее. В моем случае

IP-адрес 192.168.31.10
Маска подсети 255.255.255.0
Основной шлюз 192.168.31.254
Предпочитаемый DNS-сервер 192.168.31.1
Альтернативный DNS-сервер 192.168.31.2

Сохраняем все настройки и проверяем через Ipconfig /all, что все видится. Так же можете попробовать пропинговать ваш основной шлюз или DNS-сервер. На этом графическая настройка сети в Windows Server 2019 окончена.

Настройка сети через Windows Admin Center

С выходом Windows Server 2019 Microsoft наконец-то создает правильный инструмент для системного администратора, я говорю, о Windows Admin Center. Я вам уже подробно рассказывал, как устанавливать Windows Admin Center и его назначение. Если в двух словах, то это крутая веб консоль позволяющая управлять серверами и рабочими станциями с любого устройства, через ваш браузер. Давайте я покажу, как вы легко можете произвести установку статического Ip-адреса, маски, основного шлюза и DNS на удаленном сервере, через WAC. Напоминаю, что делать я это буду для сервера RDCB01. Давайте его пропингуем и выясним текущий адрес. Я вижу ip-адрес 192.168.31.56.

Открываем в браузере Windows Admin Center и производим подключение к нужному серверу.

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

Для настройки сети нажмите кнопку "Параметры". Как видим стоит автоматическое получение настроек.

Активируем пункт "Использовать следующий IP-адрес" и задаем нужные сетевые настройки, после чего сохраняем изменения.

Подтверждаем применение настроек.

В правом верхнем углу вам покажут, что началось задание по обновлению.

Проверяем, перед этим единственное нужно очистить кэш-DNS. В итоге я вижу, что сервер пингуется по новому адресу.

В итоге удаленная настройка сети на сервере Windows Server 2019 выполнена.

Настройка сети Windows Server 2019 через командную строку

Второй метод заключается в использовании утилиты командной строки netsh. На практике, это используется в скриптах, или при настройке Windows Server в режиме Core. Я опять переведу свои настройки на получение адреса от DHCP сервера. DHCP присвоил мне адрес 192.168.31.56.

Для того, чтобы настроить статический IP-адрес через утилиту Netsh, вам нужно знать правильное имя сетевого адаптера, он легко смотрится при выводе команды Ipconfig /all. В моем примере, это Ethernet0.

netsh interface ip set address "Ethernet0" static 192.168.31.10 255.255.255.0 192.168.31.254

192.168.31.10 - это мой статический Ip-адрес
255.255.255.0 - это моя маска подсети
192.168.31.254 - это мой основной шлюз

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

netsh interface ipv4 set dnsservers Ethernet0 static 192.168.31.1 primary

Прописываем альтернативный DNS адрес

netsh interface ipv4 add dnsservers Ethernet0 192.168.31.2 index=2

В итоге как видим у нас появился второй адрес DNS сервера на нашем сетевом интерфейсе. Настройка выполнена.

Если вам нужно вернуть сетевые настройки на получение адреса от DHCP сервера, то введите команду:

netsh interface ipv4 set dnsservers Ethernet0 dhcp && netsh interface ip set address Ethernet0 dhcp

Настройка сети через PowerShell

Чтобы настроить статический адрес на сетевом интерфейсе с помощью командлетов, вам необходимо открыть от имени администратора оболочку PowerShell.

Прежде чем мы начнем настройку сети через PowerShell в нашей Windows Server 2019, нам как и в случае с netsh, нужно выяснить имя сетевого интерфейса. Для этого вводим команду:

В результате я вижу имя интерфейса Ethernet0.

Пишем команду, где обратите внимание префикс сети 255.255.255.0 задается в виде -PrefixLength 24. На выходе вы сразу увидите примененные настройки.

Get-NetAdapter -Name Ethernet0 | New-NetIPAddress -IPAddress 192.168.31.10 -PrefixLength 24 -DefaultGateway 192.168.31.254

Зададим теперь оба DNS-сервера через команду

Get-NetAdapter -Name Ethernet0 | Set -DnsClientServerAddress -ServerAddresses 192.168.31.1, 192.168.31.2

Посмотрим текущие сетевые настройки через команду:

Как видите все сетевые настройки в моем Windows Server 2019 успешно применены.

Удаленная настройка сети

Выше я уже показал вам метод удаленной настройки сети через Windows Admin Center, но существует и еще несколько методов, которые мне были полезны в моей практике. Первое, это использование все того же PowerShell. И так у меня есть компьютер W10-cl01 с Windos 10 и предположим хочу с него настроить сеть на сервере RDCB01.

Хочу отметить, что для этого метода у вас должно быть настроено использование WinRM (Службы удаленного управления Windows)

Открываем PowerShell, командой hostname я показываю, что сижу на компьютере W10-cl01. Далее для удаленного подключения вводим команду:

Я успешно подключился, теперь повторно введя команду hostname, я вижу, что сижу на компьютере RDCB01, и можно вводить команды описанные выше.

Второй метод удаленной настройки сети на Windows Server 2019, это использование утилиты PsExec.exe, я,о ее настройке и установке рассказывал в статье "Включить RDP Windows удаленно и локально".

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

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

3 Responses to Настройка сети в Windows Server 2019, за минуту

Все зависит как построена у вас топология. Классический вариант, что у сетевой карты 1 сетевой адаптер и интернет идет по нему. Если серверу нужен выделенный IP-адрес и нет оборудования проксирования, то задействуется второй сетевой адаптер. Если у вас три может есть необходимость иметь какую-то защищенную сеть или другой VLAN, если нет то можно сделать тиминг.

Иван, день добрый! У меня есть сеть из 4 компьютеров один из них сервер на котором 3 сетевые карты. Мне нужно чтобы компьютеры были в домене и получали доступ в интернет. И я имел удаленный доступ к серверу.

В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:

1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.

Пошагово, мы выполним следующие действия:

Установка роли

Открываем Диспетчер серверов:

Переходим в Управление - Добавить роли и компоненты:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

. просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:

Откроется окно для настроек политик:

. нажимаем Далее.

Откроется окно роли IIS:

. также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

В последнем окне ставим галочку Автоматический перезапуск конечного сервера, если требуется:

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Настройка RDG

Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.

Создание групп для терминальных серверов

Политика ресурсов позволит задать нам конкретные серверы, на которые терминальный шлюз позволит нам подключаться. Для этого мы откроем консоль Active Directory - Users and computers (Пользователи и компьютеры Active Directory) и создаем группу:

* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).

Добавим в нашу группу терминальные серверы:

* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.

Закрываем консоль Active Directory - Users and computers.

Настройка политик

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

В диспетчере сервера переходим в Средства - Remote Desktop Services - Диспетчер шлюза удаленных рабочих столов:

Раскрываем сервер - кликаем правой кнопкой по Политики - выбираем Создание новых политик безопасности:

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

Даем название политике:

Задаем параметры авторизации:

* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.

В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:

* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.

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

В следующем окне мы увидим вне введенные настройки:

Откроется страница создания политики для авторизации ресурса — задаем для нее название:

Указываем группу пользователей, для которой будет применяться политика:

* как и при создании первой политики, мы добавили группу Domain Users.

Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:

* мы выбрали группу, созданную нами ранее в AD.

Указываем разрешенный для подключения порт или диапазон портов:

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

Нажимаем Готово:

Политики будут созданы.

Настройка сертификата

Запускаем «Диспетчер шлюза удаленных рабочих столов» - кликаем правой кнопкой по названию нашего сервера - выбираем Свойства:

Переходим на вкладку Сертификат SSL:

Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:

Задаем или оставляем имя для сертификата - нажимаем OK:

Мы увидим информацию о создании сертификата:

Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:

Сервер готов к работе.

Подключение к серверу терминалов через шлюз

Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.

Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:

* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.

Переходим на вкладку Дополнительно и кликаем по Параметры:

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

* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).

Кликаем Подключить:

Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:

Переходим на вкладку Состав и кликаем Копировать в файл:

Указываем путь для выгрузки файла:

Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:

Выбираем Локальный компьютер - Далее:

В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:

После снова пробуем подключиться к удаленному рабочему столу через шлюз:

Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).

Настройка Remoteapp через Gateway

Предположим, у нас есть опубликованное приложение Remoteapp и мы хотим подключаться к терминальному серверу через настроенный шлюз. Для этого открываем rdp-файл приложения на редактирование (например, блокнотом) и вносим в него изменения:

gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.

Несколько терминальных серверов и dns round robin

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

Для решения переходим в настройку шлюза - кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:

Выбираем нужную группу компьютеров и нажимаем Свойства:

* в моем случае это была единственная группа, созданная по умолчанию.

На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:

Теперь подключение будет выполняться без ошибок.

Возможные ошибки

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

1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.

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

3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.

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

Читайте также: