В этой статье мы подробно рассмотрим, как создать интернет-шлюз на базе Windows Server 2022, используя возможности Remote Desktop Gateway и роли сервера шлюза. Этот процесс позволяет настроить сервер для раздачи интернета в локальную сеть через два сетевых интерфейса: один для приема интернет-трафика, другой для его распределения. Это решение удобно для создания шлюзов в корпоративных и виртуальных сетях, обеспечивая централизованное управление доступом к сети.
Приобрести Windows Server 2022 можно у нас в магазине от 2790 ₽.
Скачать оригинальные дистрибутивы Windows Server 2022 можно в нашем каталоге.
Требования для настройки шлюза
Для того чтобы создать интернет-шлюз, вам потребуется сервер с двумя сетевыми интерфейсами:
— Откройте «Параметры сети и интернет» в правом нижем углу
— Перейдите в Ethernet > Настройка параметров адаптера
Здесь должно быть два сетевых интерфейса
— LAN-интерфейс для локальной сети (внутренней)
— WAN-интерфейс для подключения к интернету (внешней)
Также у нас есть два тестовых виртуальных компьютера, на которых мы будем проверять подключение к интернету.
Шаг 1: Проверка сетевых интерфейсов
1. На сервере должно быть два сетевых адаптера: один для внутренней сети (LAN-интерфейс), другой для внешней сети (WAN-интерфейс).
2. WAN-интерфейс получает интернет, а через LAN-интерфейс будет происходить его раздача.
Проверьте статус подключения на тестовых компьютерах.
— Нажмите «пуск» и в поиске введите «cmd»
— В командной строке введите ping 8.8.8.8 -t
В данный момент интернета на них нет.
Шаг 2: Установка роли «Удаленный доступ»
1. Откройте Диспетчер серверов и выберите Добавить роли и компоненты.
2. Нажмите Далее несколько раз, пока не дойдете до списка ролей.
3. В списке выберите Удаленный доступ и нажмите Далее несколько раз, пока не дойдете до Cлужбы ролей.
4. В окне компонентов выберите Маршрутизация и нажмите Добавить компоненты.
5. Нажмите Далее пока не дойдете до Подтверждение
6. После чего установите компоненты нажав на Установить.
7. После окончания установки нажмите «Закрыть»
Шаг 3: Настройка маршрутизации и удаленного доступа
1. После установки роли, в Диспетчере серверов появится оснастка Удаленный доступ.
2. Откройте оснастку и перейдите в раздел Средства.
3. В списке выберите Маршрутизация и удаленный доступ.
4. Щелкните правой кнопкой мыши на сервере и выберите Настроить и включить маршрутизацию и удаленный доступ.
5. В мастере настройки Нажмите Далее.
6. Выберите Преобразование сетевых адресов (NAT) и нажмите Далее.
7. Выберите WAN-интерфейс в качестве интерфейса для подключения к интернету.
8. Нажмите Готово для завершения настройки.
Шаг 4: Проверка подключения к интернету
1. После завершения настройки маршрутизации проверьте подключение к интернету на тестовых компьютерах. Теперь интернет должен появиться на обоих устройствах.
2. Выполните команду ping 8.8.8.8 -t на каждом компьютере, чтобы убедиться, что интернет-соединение установлено.
Заключение
Вы успешно настроили интернет-шлюз на базе Windows Server 2022 с использованием двух сетевых интерфейсов и функции маршрутизации. Теперь сервер может раздавать интернет во внутреннюю сеть через LAN-интерфейс. Такой способ настройки удобен для создания шлюзов в корпоративных или виртуальных сетях.
Лицензионный ключ активации Windows Server 2022 от
В этой статье посмотрим, как с помощью встроенных средств на базе сервера с 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 ее интерфейс и процесс настройки практически не изменился.
В первую очередь нужно установить роль 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 и создайте новое статическое правило маршрутизации.
Примечание. Статический маршрут также можно добавить из командной строки с помощью команд Route или netsh.
This guide is for those who wants to simulate I virtual enterprise environment, and use a Windows Server as a virtual Gateway. In this example I´m going to use 2 separate VLAN and use the Gateway as a Router and also NAT all communications to the Internet. This way only one server faces the internet, and you could also have a firewall on the server.
SETUP:
1 Server 2016 Core, Name (GW) , Workgroup (but could be domain joined), used as gateway and router.
2 Server 2016 GUI, Name (MGM,MGM2), Workgroup (but could be domain joined), used for verification.
Setup Hyper-V:
On the GW server I need 3 network cards. One connected to an External switch and the other two connected to the same Private switch.
The two Private Switches I configure with VLAN ID.
The MGM server has the VLAN 102 and the MGM2 has the VLAN 103 switch connected to them.
Setup GW Server:
Server is installed and fully patched.
On the server we now have three network cards. And I will rename them to External, VLAN 102 and VLAN 103.
First we check what Network cards we have, so logon to the server and start Powershell, and then we check what network adapters we have.
Get-NetAdapter
When looking at the LinkSpeed I see that one connection is at 1 Gbps, so that should be my External network, and the rest the internal. Bydefault the names of the cards is in order of installation, so if you first create the internal ones, they will have the lower number. So if you add them one by one, you will know which adapter is which.
Then we rename the cards, just so it will be easier to see.
Get-NetAdapter -Name "Ethernet" | Rename-NetAdapter -NewName "External" Get-NetAdapter -Name "Ethernet 2" | Rename-NetAdapter -NewName "VLAN 102" Get-NetAdapter -Name "Ethernet 3" | Rename-NetAdapter -NewName "VLAN 103"
And when we check again we see the new names.
Get-NetAdapter
Then we must set a IP-address of the network cards, in this case External gets from a DHCP, so we don´t need to change that one.
So for the VLAN 102
New-NetIPAddress -InterfaceAlias "VLAN 102" -IPAddress 192.168.102.1 -PrefixLength 24 -DefaultGateway 192.168.102.1
And for VLAN 103
New-NetIPAddress -InterfaceAlias "VLAN 103" -IPAddress 192.168.103.1 -PrefixLength 24 -DefaultGateway 192.168.103.1
This is not needed but I always want to enable IMCP, so lets enable that in the windows firewall.
Enable-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)"
Just a quick check that we have internet connectivity
Test-NetConnection
So now on with installing the RRAS. So install the Routing role and restart the server.
Install-WindowsFeature Routing -IncludeManagementTools -Restart
When the server has rebooted, log on to it again and start powershell.
Configuration RRAS:
The next part there is two solutions as I see it, the old way by using he GUI from another server, and another when you using NETSH. If you ever want to use the GUI and see what NAT that is in use and the stats for packages, then I recommend using the GUI. If anyone know a way to be able to use powershell or other ways to configure this and it will show up the same in the GUI let me know. I will now show both ways to configure this.
RRAS GUI:
From the MGM server, set it up on VLAN 102 with a IP and set the default GW to the IP of the GW server IP for VLAN 102. If using MGM2 set up with that IP and use that GW IP. Below I use MGM.If the server is in workgroup make sure that the same Admin account is on both servers with same password for easier management. If in domain, make sure your account has admin rights.
Now. On the MGM server. Install RSAT för RRAS via powershell. Restart not needed.
Install-WindowsFeature RSAT-RemoteAccess -IncludeAllSubFeature
Now start the “Routing and Remote Access” GUI.
In the GUI, right click on top of the tree and choose “Add Server”
Check The following computer and type in the IP-address of the gateway (in this case the MGM server is on VLAN 102 so we choose 192.168.0.1 to connect to the GW), and then click on connect.
Now right click on 192.168.102.1 and choose “Configure and Enable Routing and Remote Access”.
Click Next.
Select NAT and click on Next.
Select our External Network card and click on Next.
Select one of the cards (VLAN) that will be able to access internet, and click Next. In this you can´t add more then one card, but we will add it later.
The next screen will only show up if server is in a workgroup. You can choose if you want the GW to forward all DNS request towards the internet or if you will use a internal DNS and DHCP. In this case just to show how it works, so I will chose to let the GW forward all traffic. In a fully simulated environment, I would have the GW domain joined.
Click Next.
Click Finish and led RRAS be configured.
NB if you have enabled “Windows Firewall Remote Management” in the firewall you will get the following error message. This is not an Issue, because installing the Routing Role in the GW already has enabled the FW rules (at least on core).
Now expand 192.168.102.1 and the IPv4 and then NAT. If NAT does not show up, there is probably a GUI error, and a reboot of the RRAS console or the MGM server will fix that. We see that our VLAN 102 and the External Network is connected in NAT.
To add VLAN 103, right click on NAT and choose “New Interface.”
Select VLAN 103 and click on OK.
Select Private Interface and click on OK.
Now VLAN 103 should be visible under NAT.
Now, we can go on with verification.
RRAS Core:
NB, if you use this way you cant use the GUI from a 2016 server to view anything, it will throw a message that legacy is not supported and powershell must be used.
On the GW server install the install the RomoteAccess, and just because we want an output we add -PassThru
Install-RemoteAccess -VpnType RoutingOnly -PassThru
The next commands is using NETSH so start it by typing in NETSH and enter the NETSH interface. Then type “routing ip nat” to enter that.
And now add config in netsh. The first row will install the NAT functionality, this will throw a message that it does not find the file specified, but it will stil work. Row 2 will add the External Adapter with mode Full. Row 3 will add the VLAN 102 adapter. Row 4 will add the VLAN 103 adapter
install add interface "External" mode=full add interface "VLAN 102" add interface "VLAN 103" exit
And the its on to verification.
Verfification:
Now from the MGM server, make sure you have a functional DNS-server setting, or set google as one and the run Test-NetConnection.
Test-NetConnection
And from VLAN 103
So we see that internet access is working from both WLAN, and to test if the Routing works (starts working as soon NAT is in place). From VLAN 102 to VLAN 103, and we add -TraceRoute just to see the route.
Test-NetConnection 192.168.103.33 -TraceRoute
And from VLAN 103 to VLAN 102
Test-NetConnection 192.168.102.33 -TraceRoute
DONE
В нескольких предыдущих постах, посвященных технологии виртуализации сети (Hyper-V Network Virtualization, HNV), я рассказал об архитектуре, настройках, а также новых возможностях HNV в Windows Server 2012 R2. Сегодня речь пойдет о, пожалуй, самой сложной теме – построении HNV-шлюза на базе Windows Server 2012 R2 для предоставления виртуализованным сетевым сегментам доступа во внешний мир. Будет много скриншотов.
В большинстве случаев виртуальным машинам (ВМ), развернутым в виртуализованных сетях, необходимо взаимодействие с внешним миром – для связи с другими объектами ЦОД-а, для выхода в Интернет, для доступа к корпоративной сети компании, которая расположила в ЦОД-е эти самые ВМ и пр. Применительно к технологии HNV внешним миром является все что угодно, находящееся за пределами виртуализованной сети. И прежде чем двигаться дальше, необходимо лишний раз определиться с терминологией, которая за два года существования HNV слегка видоизменилась.
Терминология
Итак, определяющим понятием HNV является сеть заказчика (Customer Network), обладающая уникальным идентификатором Routing Domain ID (RDID). Это и есть та самая виртуализованная сеть. Для Customer Network существует несколько синонимов, в зависимости от того, каким инструментом вы пользуетесь:
- в VMM это VM Network;
- в PowerShell это Routing Domain;
- во многих статьях и блогах это Tenant или Tenant Virtual Network.
Но все эти термины суть Customer Network. Каждая сеть заказчика состоит из одной или более виртуальных подсетей (Virtual Subnet), и у каждой виртуальной подсети есть свой уникальный 24-битный идентификатор VSID. Маршрутизация пакетов между ВМ, принадлежащими одной сети заказчика, осуществляется автоматически, независимо от того, расположены ли эти машины в одной виртуальной подсети или в разных, на одном физическом хосте, или на разных. А вот если нужна связь с внешним миром, то есть необходимо передать пакеты за пределы Customer Network, то должен быть настроен HNV-шлюз (HNV Gateway, HNVGW).
Варианты реализации шлюза
HNV-шлюз может представлять собой либо готовое аппаратное решение, либо хост на базе Windows Server 2012 R2. На текущий момент на рынке доступны три аппаратных решения:
- от nAppliance
- от Iron Networks
- от F5
В этом посте я сосредоточусь на создании HNV-шлюза на базе Windows Server 2012 R2, при этом управление HNV в моей демонстрационной сети, в том числе настройка шлюза, будет осуществляться с помощью System Center 2012 R2 Virtual Machine Manager (VMM). Используя далее сокращение VMM, я предполагаю именно версию R2, если явно не указано иное.
Напомню, что строго говоря, HNV – это технология Windows Server 2012 и выше, и она может быть настроена без VMM, просто с помощью командлетов PowerShell. Привожу ссылки на примеры соответствующих скриптов без использования и с использованием HNV-шлюза. Но в реальных сценариях для управления HNV применяется VMM, который берет на себя роль централизованного хранения и распространения политик HNV.
Архитектура шлюза
Архитектурно HNV-шлюз на базе Windows Server 2012 R2 представляет собою физический хост, на котором запущена одна или несколько ВМ, выполняющих маршрутизацию пакетов из виртуализованных сетей во внешний мир и обратно. Обращаю внимание, это именно
физический
хост. Реализовать HNV-шлюз просто в виде виртуалки не получится уже хотя бы потому, что для инкапсуляции пакетов (см. пост о концепции HNV) необходима роль Hyper-V, а вложенную виртуализацию Hyper-V не поддерживает.
Справедливости ради стоит отметить, что технически шлюз можно построить и на базе Windows Server 2012. Но при этом, во-первых, шлюз с Windows Server 2012 потребует запуска стольких ВМ, сколько у вас Customer Networks, и масштабирование такого решения затруднительно. Во-вторых, для управления таким шлюзом с помощью VMM необходимо будет написать провайдер для VMM. Использование же Windows Server 2012 R2 + System Center 2012 R2 Virtual Machine Manager – это практически готовый HNV-шлюз «из коробки». В Windows Server 2012 R2 реализован мультитенантный шлюз, позволяющий задействовать одну ВМ для маршрутизации трафика различных виртуализованных сетей, а в System Center 2012 R2 Virtual Machine Manager уже встроен провайдер для управления таким шлюзом.
Какие варианты работы HNV-шлюза существуют? Таковых два.
Private Cloud (Routing)
Первый вариант реализует маршрутизацию трафика из Customer Network в сеть ЦОД-а, причем маршрутизация может быть как прямой, так и c трансляцией адресов (NAT).
На рисунке изображена прямая маршрутизация, которая имеет смысл, если пространства CA-адресов разных тенантов (Customer Networks) не пересекаются и им нужен доступ в корпоративную сеть. Или, как на рисунке, есть только один тенант с несколькими подсетями. Для частного облака, когда тенанты, например, представляют собой виртуализованные сети различных департаментов крупного предприятия, вполне возможный вариант.
При использовании NAT каждому тенанту HNV-шлюз ставит в соответствие выделенный IP-адрес на своем внешнем интерфейсе, и все пакеты от виртуальных машин тенанта отправляются во внешний мир с этим выделенным IP в поле «IP-адрес отправителя».
Hybrid Cloud (Site to site VPN)
Второй вариант предполагает построение туннеля типа «сеть-сеть» от HNV-шлюза до необходимой точки, например, через Интернет до корпоративной сети заказчика.
Это как раз типовой хостерский сценарий, когда ВМ заказчика располагаются в ЦОД-е хостера и связываются через VPN с сетью заказчика. Технология HNV при этом позволяет заказчику сохранить настройки IP и не бояться за работоспособность софта внутри ВМ, а хостеру –расположить у себя виртуалки с нужными заказчику IP, изолируя эти виртуалки от других ВМ и не настраивая VLAN-ы.
Завершая архитектурный раздел поста, отмечу кратко в чем же заключается мультитенантность шлюза на базе Windows Server 2012 R2.
Представьте себе, что в ЦОД-е виртуализованы сети двух заказчиков, Contoso и Woodgrove, использующие абсолютно одинаковые CA-пространства: 10.0.0.0/24. Как «развести» пакеты этих заказчиков на HNV-шлюзе? Первое возможное решение – создать на шлюзе для каждого заказчика свою ВМ и указать ее в настройках соответствующей сети заказчика в качестве default gateway. Таким образом, пакеты, направленные во внешний мир из Contoso, всегда будут приходить на сетевой интерфейс одной ВМ шлюза, пакеты из Woodgrove – на интерфейс второй ВМ и т. д. Как упоминалось, шлюз на базе Windows Server 2012 именно такой подход и использовал бы.
В Windows Server 2012 R2 для маршрутизации появилась возможность использовать так называемые ячейки (compartments). В виртуальной машине для каждого тенанта создается некий объект «ячейка» (compartment), в которую включаются виртуальные сетевые интерфейсы, IP-адреса, таблица маршрутизации, ARP-таблица и пр. Элементы одной ячейки изолированы от элементов другой ячейки. Маршрутизация пакетов от Contoso, таким образом, осуществляется в рамках соответствующей ячейки и не пересекается, не влияет на маршрутизацию пакетов Woodgrove в другой ячейке, даже если записи в таблицах маршрутизации этих ячеек выглядят одинаково. Такой подход позволяет использовать одну ВМ для маршрутизации пакетов разных тенантов без каких-либо конфликтов.
Как видно на рис. выше, существует ячейка по умолчанию (default compartment), которая включает в себя сетевые настройки, задаваемые при создании ВМ, и две ячейки для тенантов, появившиеся в процессе настройки HNV-шлюза.
Создание шлюза
Подкрепившись теорией, перейдем непосредственно к созданию шлюза. Для простоты я рассмотрю вариант шлюза без кластеризации, хотя понятно, что в реальном ЦОД-е такой важный элемент виртуализации предполагает работу в режиме высокой доступности. Детальный документ о том, как сделать HNV-шлюз высокодоступным можно найти здесь.
Основные шаги по созданию шлюза включают в себя следующее:
- настройка логических сетей и сетей ВМ;
- настройка хоста для роли шлюза
- подготовка ВМ для шлюза
- добавление шлюза в VMM
- настройка шлюза для конкретных сетей ВМ
Давайте по порядку.
Настройка логических сетей и сетей ВМ
Этот пункт довольно подробно описан в одном из предыдущих постов, поэтому покажу лишь, как логические и виртуальные сети выглядят у меня в лабораторном свечном ЦОД-ике Contoso.
Для нашей задачи нужны три логические сети: внешний сегмент (Contoso_External_LN01), сеть для управления шлюзом (Contoso_Management_LN01) и сеть (Contoso_HNV_LN01), поверх которой собственно создаются виртуализованные сети. IP-пул сети Contoso_HNV_LN01 задает PA-пространство, а в свойствах этой сети обязательно должен быть помечен чекбокс, разрешающий использование технологии HNV.
Сети ВМ (VM Networks, они же сети заказчиков, они же Customer Networks) выглядят так:
Вы видите две сети ВМ для компаний Adatum и Fabrikam, использующие пересекающееся адресное пространство (10.30.1.0/24). В колонке Gateway Connection видно, что пока ни одна из сетей ВМ не использует шлюз.
Настройка хоста для роли шлюза
В общем-то любой хост с Windows Server 2012 R2, которым управляет VMM, можно настроить в качестве HNV-шлюза. По-хорошему, у этого хоста должно быть несколько физических сетевых интерфейсов, смотрящих в нужные сегменты (внешний, сегмент управления, сегмент HNV). Однако из архитектурной части поста следует, что собственно маршрутизацией пакетов в шлюзе занимается ВМ. Поэтому сколько физических сетевушек должно быть в хосте, выполняющем роль шлюза, определяется вопросами производительности, надежности (можно использовать тиминг, например) и, конечно, логикой того, как и куда вы хотите отправлять пакеты. Конкретно в моем стенде хост-шлюз содержит всего один физический сетевой интерфейс, мне этого пока вполне хватает для экспериментов.
Но в любом случае, в свойствах хоста, выбранного на роль шлюза, следует установить вот этот чекбокс
Он предотвратит запуск на шлюзе любых «рядовых» ВМ, предполагающих использование HNV. В реальной ситуации вы вообще вряд ли будете запускать на шлюзе еще что-то, кроме компонент самого шлюза.
Подготовка ВМ для шлюза
Теперь поговорим о той самой ВМ, которая будет осуществлять маршрутизацию пакетов с помощью compartments. Проще всего развернуть ее с помощью сервисного шаблона (service template). В этом случае можно сразу же сказать VMM, чтобы при развертывании ВМ в ней была поднята служба RRAS, чтобы для высокой доступности таких машин было поднято две на кластере и пр. Но, во-первых, мы договорились сделать все руками, чтобы лучше понять, что происходит, во-вторых, сервисные шаблоны не поддерживают ВМ второго поколения, которые разворачиваются, да и работают пошустрее.
Поэтому я создал шаблон ВМ второго поколения на базе VHDX с образом Windows Server 2012 R2. В этом процессе нет ничего необычного, покажу лишь сетевые настройки в шаблоне.
Вы видите три виртуальных сетевых адаптера (vNIC): один подключен ко внешней сети (см. рис.), второй к сети управления, третий можно в шаблоне оставить в состоянии Not Connected, а в процессе или сразу после развертывания ВМ, подключить его через виртуальный коммутатор (Hyper-V Extensible Switch) к сети, в которой используется HNV. Обычно при описании шлюза эту сеть называют Backend.
Разворачиваем теперь ВМ на основе этого шаблона на хост, который мы выбрали и настроили в качестве шлюза в предыдущем пункте. Обратите внимание на имя, которые вы дадите этой ВМ. Оно понадобится впоследствии при конфигурации шлюза.
После того, как ВМ развернута, зайдем в нее, подключим сетевой адаптер к Backend-сети, отключим Firewall и для удобства переименуем сетевые адаптеры так, чтобы имена отражали их предназначение, например
Теперь в ВМ (я назвал ее GatewayVM01) необходимо установить роль Remote Access. Делается это стандартно через Server Manager, Manage -> Add Roles and Features. Нажимаем Next, пока не дойдем до выбора роли, выбираем Remote Access, затем снова Next, пока не дойдем до Role Services, где помечаем две службы
Жмем до упора Next и Install. После завершения установки нажимаем Open the Getting Started Wizard
и в окне открывшегося мастера выбираем Deploy VPN only.
В итоге, откроется хорошо знакомая консоль RRAS, из которой видно, что служба пока не сконфигурирована.
Тем самым мы настроили хост и соответствующую ВМ, и теперь все готово, чтобы добавить эту «заготовку» в качестве HNV-шлюза в консоль VMM для последующей конфигурации.
Добавление шлюза в VMM
В консоли VMM переходим в раздел Fabric, нажимаем Add Resources и выбираем Network Service. На первой странице мастера даем шлюзу осмысленное имя и описание
Затем выбираем Microsoft в качестве производителя и Microsoft Windows Server Gateway в списке моделей
На странице Credentials необходимо выбрать Run As account для доступа к устройству. Эта запись должна иметь административные права на ВМ шлюза. В нашем случае ВМ не включалась в домен, поэтому указываем запись с паролем локального администратора. Если в VMM такой записи нет, ее тут же можно создать.
Самый, пожалуй, интересный параметр – строка подключения (Connection String), в которой с помощью трех параметров VMHost, GatewayVM и BackendSwitch необходимо указать имя хоста и ВМ «заготовки» и имя виртуального коммутатора на хосте, через который ВМ подключается к Backend-сети. Обратите внимание, что в строке подключения нет пробелов, разделителем служит точка с запятой (;).
Кроме трех перечисленных выше существует еще несколько параметров, описание которых можно найти здесь (см. п.16). В частности, DirectRoutingMode=True настроит шлюз на работу в режиме прямой маршрутизации.
При заданной выше строке подключения сертификаты не используются, поэтому на странице Certificates просто нажимаем Next.
На странице Provider нажимаем кнопку Test и убеждаемся, что все тесты проходят без ошибок.
На странице Host Group указываем, какие хостовые группы могут пользоваться данным шлюзом
Проверяем настройки на станице Summary, и если все правильно, жмем Finish.
Проверьте, что соответствующие задачи в разделе Jobs успешно завершены. Остается настроить сетевые интерфейсы только что созданного HNV-шлюза. В разделе Fabric -> Networking -> Network Service консоли VMM щелкните правой кнопкой мыши по шлюзу, выберите Properties и перейдите на закладку Connectivity. Здесь нужно включить Front End Connection и Back End Connection и выбрать правильные сетевые адаптеры ВМ и соответствующие сайты логических подсетей.
Вот теперь VMM знает, какие адаптеры ВМ шлюза для каких целей предназначены, и должным образом сконфигурирует службу RRAS внутри этой ВМ. Когда отработают job-ы, в консоли RRAS ВМ шлюза вы увидите, что служба запущена и работает как мультитенантный шлюз.
Дело за малым, настроить требуемые сети ВМ на использование созданного HNV-шлюза.
Настройка шлюза для конкретных сетей ВМ
В консоли VMM переходим в раздел VMs and Services, щелкаем VM Networks, выбираем нужную сеть ВМ и нажимаем кнопку Properties. Идем на закладку Connectivity и разрешаем использование HNV-шлюза этой сетью. Для сети Fabrikam, например, включаем NAT
VMM автоматически выделит из IP-пула логической сети, ассоциированной с внешним интерфейсом HNV-шлюза, адрес, в который будут транслироваться адреса отправителей всех пакетов из сети Fabrikam. Но вы можете вручную выбрать IP из пула, указав его в поле IP address
Закрыв окно свойств, в нижней части консоли VMM можно увидеть, какой конкретно внешний адрес используется для данной сети ВМ
Аналогично поступаем для сети Adatum и всех других виртуализованных сетей, которым нужен внешний доступ с поддержкой NAT.
Теперь давайте посмотрим, как настраивается подключение ко внешнему миру через VPN, то есть реализуем сценарий Hybrid Cloud (Site to site VPN). При этом я предполагаю, что VPN-устройство в корпоративной сети уже настроено, использует протокол IKEv2 и аутентификацию на основе Preshared Key, что типично для туннелей «сеть-сеть», и его внешний IP нам известен.
В свойствах той же сети ВМ Fabrikam на уже знакомой закладке Connectivity помечаем самый верхний чекбокс
При этом в окне свойств сети ВМ появляется новая закладка VPN Connections, где нужно кнопкой Add добавить VPN-подключение, указать его имя и IP-адрес VPN-устройства, до которого строится туннель
В разделе Authentication указываем подготовленную запись Run As account с прописанным Preshared Key,
и в разделе Routes прописываем нужные маршруты, например
Как вы могли обратить внимание, для динамического обновления маршрутов реализована поддержка BGP.
Можно посмотреть на расширенные настройки в Advanced, скажем поменять VPN-протокол или параметры шифрования, но если ничего этого не требуется, то жмем ОК. В нижней части консоли VMM для настроенной сети ВМ теперь будет отображаться что-то вроде
Как только из любой ВМ, запущенной в виртуализованной сети Fabrikam, попробуем сделать ping на адрес из подсети, указанной с настройках VPN-туннеля, например, 10.30.50.101, HNV-шлюз поднимет туннель и установит связь с заданным VPN-устройством, а через него с корпоративной сетью
Дело сделано!
Если информации из этого поста оказалось недостаточно, можете воспользоваться подробным пошаговым руководством для создания лабораторного стенда.
Остается открытым один вопрос, как собственно происходит маршрутизация пакетов при использовании HNV-шлюза, как это выглядит внутри шлюза? Но это уже уровень сложности 400 для особо искушенных. 
Хотя, если таковые найдутся, готов написать.
Надеюсь, материал был полезен.
Спасибо!
Опубликовано:
Используемые термины: Remote Desktop Gateway, Active Directory, Терминальный сервер.
В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:
1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.
2. Два терминальных сервера — настроено по инструкции Установка и настройка терминального сервера на Windows Server.
Пошагово, мы выполним следующие действия:
Установка серверной роли
Настройка шлюза
Создание групп в AD
Создание политик RDG
Привязка сертификата
Настройка клиента для подключения
Remoteapp через Gateway
DNS round robin
Часто встречаемые ошибки
Установка роли
Открываем Диспетчер серверов:
Переходим в Управление — Добавить роли и компоненты:
При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):
На страницы выбора типа установки оставляем выбор на Установка ролей или компонентов:
Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:
Ставим галочку Службы удаленных рабочих столов:
Дополнительные компоненты нам не нужны:
… просто нажимаем Далее.
На странице служб удаленных рабочих столов идем дальше:
Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты:
Откроется окно для настроек политик:
… нажимаем Далее.
Откроется окно роли 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.
Нажимаем Готово:
Политики будут созданы.
Настройка сертификата
Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.
Запускаем «Диспетчер шлюза удаленных рабочих столов» — кликаем правой кнопкой по названию нашего сервера — выбираем Свойства:
Переходим на вкладку Сертификат 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
gatewayusagemethod:i:1
…
* где:
- gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
- gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.
Пробуем подключиться.
Несколько терминальных серверов и dns round robin
При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:
Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:
Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:
Выбираем нужную группу компьютеров и нажимаем Свойства:
* в моем случае это была единственная группа, созданная по умолчанию.
На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:
Теперь подключение будет выполняться без ошибок.
Возможные ошибки
При подключении мы можем столкнуть со следующими ошибками.
1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.
Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.
2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).
Обращение к терминальному серверу выполняется по незарегистрированному имени. Необходимо проверить настройку в клиенте подключения или зарегистрировать ресурс, как мы это делали при настройке нескольких терминальных серверов.
3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.
В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.