что такое удаленный шлюз
Сайт ARNY.RU
В Windows 10 был баг, который не позволял снять чекбокс Использовать основной шлюз в удаленной сети в VPN, а именно кнопка Свойства есть, она активна, но при щелчке на ней — ничего не происходит.
Лечилось через скрипт в командной строке:
Эта заметка была написано давненько. Тогда она могла кому-то помочь, сейчас уже неактуальна. К тому же тут всего пару предложений текста. Но что самое интересное, заходы на эту страничку из поисковиков есть. Поэтому решил не удалять её, а наоборот расширить.
Для чего вообще этот чекбокс нужен?
Когда VPN соединение установлено, то есть две возможности:
В этом случае в VPN туннель будет уходить только предназначенный ему трафик. Если за VPN туннелем есть ещё подсети, то они окажутся недоступными с локального компьютера.
Чтобы эти подсети были доступны, нужно на локальном компьютере руками прописывать дополнительные маршруты. Эти маршруты будут указывать, что пакеты для данных подсетей должны быть смаршрутизированы в туннель. В этом минус.
Плюс в том, что туннель никак не повлияет на остальной трафик с локального компьютера. Будет работать интернет и будут доступны удалённые сетевые ресурсы, которые были доступны до подключения туннеля.
При этом методе подключения большая часть пакетов будет отправляться в туннель. Соответственно все сетевые ресурсы (кроме локальных, из подсети компьютера) отвалятся (или опять прописывать маршруты, теперь уже для них). Если на удалённом VPN шлюзе нет интернета (допустим, не настроены адреса DNS серверов), то на локальном компьютере отвалится и интернет.
Если на удалённом шлюзе настроен интернет, то выход в интернет на локальном компьютере будет работать через туннель. Это минус.
Плюс: все подсети, которые доступны с VPN шлюза, будут доступны на локальном компьютере.
Какой метод выбрать.. кому как проще и удобнее. Тут надо сказать: сразу после создания VPN туннеля чекбокс Использовать шлюз в удалённой сети отмечен. То есть будет работать по второму варианту.
Пример
Чтобы было понятнее поясню на примере. Допустим, есть домашняя сеть: компьютер 192.168.0.2, роутер 192.168.0.1, SmartTV 192.168.0.3 и NAS с фильмами 192.168.0.4. И ещё есть ресурс от провайдера интернета (к примеру, FTP с фильмами, играми и программами) с интернет адресом 212.6.X.X. Но доступ к этому ресурсу открыт только из сети провайдера, а из интернета закрыт.
Подсоединение VPN происходит на какой-то интернет адрес, к примеру 185.82.X.X. После установки VPN соединения локальный компьютер получает адрес, связанный с туннелем 172.16.1.2, а удалённый шлюз в туннеле имеет адрес 172.16.1.1. Предположим что за сетью 172.16.X.X есть ещё сеть 10.X.X.X, на 172.16.1.1 существует маршрут в эту сеть.
Соответственно при первом варианте в удалённой сети будут доступны только адреса 172.16.X.X, при этом все адреса локальной сети 192.168.0.X так же доступны. Будет доступен и FTP-сервер провайдера. Будет работать интернет с той скоростью, какая заявлена провайдером, например 100Mbit.
При втором варианте будут доступны удалённые адреса и 172.16.X.X, и 10.X.X.X. Локальные адреса 192.168.0.X доступны, но вот провайдерский FTP отвалится и интернет заработает со скоростью 10Mbit, потому что такая скорость интернета подключена для 185.82.X.X.
Как набросить маршрут?
Допустим, хотим подключаться по первому варианту, но чтобы сеть 10.X.X.X была доступна. Надо запустить cmd.exe, выбрать Запуск от Администратора.
Затем вбить команду:
Первый параметр 10.0.0.0 это сеть назначения, второй 255.0.0.0 это маска подсети, третий 172.16.1.1 это шлюз в удалённую сеть. Если есть трудности с подсетями и масками, то вот статья. Параметр -p укажет компьютеру, что маршрут постоянный и его надо сохранить после перезагрузки. Удалить маршрут:
Как до этого чекбокса добраться?
Там нажимаем кнопку Дополнительно. Открывается новое окошко и (Ура!) наш чекбокс. У меня он, как видите, отмечен, потому что когда я играю в Q3 на удалённом серваке, мне не нужны ни сетевые ресурсы, ни сёрф в интернете.
Если нужна инструкция как создать VPN подключение в Windows 10, то вот ссылка на сайт Microsoft.
Установка и использование Remote Desktop Gateway
В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (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 и создадим сертификат.
Создание групп для терминальных серверов
* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).
Добавим в нашу группу терминальные серверы:
* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.
Настройка политик
Для предоставления доступа к нашим терминальным серверам, создадим политики для подключений и ресурсов.
Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):
Даем название политике:
Задаем параметры авторизации:
* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.
В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:
* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.
Далее настраиваем временные ограничения использования удаленного подключения. Если в этом есть необходимость, оставляем галочки в состоянии Включить и указываем количество минут, по прошествии которых сеанс будет отключен:
В следующем окне мы увидим вне введенные настройки:
Откроется страница создания политики для авторизации ресурса — задаем для нее название:
Указываем группу пользователей, для которой будет применяться политика:
* как и при создании первой политики, мы добавили группу Domain Users.
Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:
* мы выбрали группу, созданную нами ранее в AD.
Указываем разрешенный для подключения порт или диапазон портов:
* в данном примере мы разрешим подключение по порту 3389, который используется по умолчанию для RDP.
Нажимаем Готово:
Политики будут созданы.
Настройка сертификата
Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.
Переходим на вкладку Сертификат SSL:
Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:
Мы увидим информацию о создании сертификата:
Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:
Сервер готов к работе.
Подключение к серверу терминалов через шлюз
Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.
Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:
* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.
Переходим на вкладку Дополнительно и кликаем по Параметры:
Переключаем параметр приложения в положение Использовать следующие параметры сервера шлюза удаленных рабочих столов и указываем внешнее имя сервера:
* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).
Кликаем Подключить:
Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:
Переходим на вкладку Состав и кликаем Копировать в файл:
Указываем путь для выгрузки файла:
Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:
В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:
После снова пробуем подключиться к удаленному рабочему столу через шлюз:
Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).
Настройка Remoteapp через Gateway
Предположим, у нас есть опубликованное приложение Remoteapp и мы хотим подключаться к терминальному серверу через настроенный шлюз. Для этого открываем rdp-файл приложения на редактирование (например, блокнотом) и вносим в него изменения:
Несколько терминальных серверов и dns round robin
При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:
Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:
Выбираем нужную группу компьютеров и нажимаем Свойства:
* в моем случае это была единственная группа, созданная по умолчанию.
На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:
Теперь подключение будет выполняться без ошибок.
Возможные ошибки
При подключении мы можем столкнуть со следующими ошибками.
1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.
Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.
2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).
Обращение к терминальному серверу выполняется по незарегистрированному имени. Необходимо проверить настройку в клиенте подключения или зарегистрировать ресурс, как мы это делали при настройке нескольких терминальных серверов.
3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.
В данном случае нужно проверить, какой сертификат привязан к RDG. Также нужно убедиться, что привязанный сертификат, на самом деле, не просрочен или отозван. В крайнем случае, можно заново создать сертификат.
bearded sysadmin
Архивы
На сегодняшний день количество пользователей, желающих получать доступ к внутренним ресурсам предприятия из дома или кафе, стремительно увеличивается. Такая тенденция наблюдается как в больших корпорациях так и в маленьких компаниях. Поэтому перед системными администраторами всё чаще встает вопрос — а как же удовлетворить потребности пользователей и при этом сохранить безопасность внутренней сети. Для служб RDS таким решением станет использование шлюза доступа к удалённым рабочим столам.
Шлюз удалённых рабочих столов представляет собой сервис посредника между клиентами из внешней сети и коллекцией сеансов, которая расположена во внутренней сети предприятия, и обеспечивающий безопасный обмен данными между ними.
В этой статье рассмотрены следующие вопросы:
Как работает шлюз удалённых рабочих столов?
Если описывать вкратце, то в случае, когда клиент инициирует подключение к шлюзу удалённых рабочих столов, шлюз первым делом устанавливает защищенное соединение между собой и клиентом. Затем, сервер шлюза проверяет учётную запись пользователя или компьютера на право доступа к службе шлюза и, в случае успеха, проводит авторизацию клиента. После того, как клиент авторизирован шлюз проверяет имеет ли клиент право на доступ к запрашиваемому ресурсу. И в том случае, если клиент имеет право на подключение, то шлюз устанавливает соединение между собой и внутренним ресурсом. Вся дальнейшая передача каких-либо данных между внешним клиентом и внутренним ресурсом осуществляется строго через шлюз.
Рис.1 — Работа шлюза удалённых рабочих столов
Нововведения в службе шлюза удалённых рабочих столов
Нововведений в службе RD Gateway по сравнению с предыдущей версией действительно много и вот самые значительные из них:
Что же нового приносят эти функции? Давайте разбираться.
Поддержка транспортного протокола UDP
Как известно, для оптимизации передачи трафика по протоколу RemoteFX используется транспортный протокол UDP. Поэтому его поддержка со стороны шлюза значительно улучшает работу с клиентами, использующими для работы именно протокол RemoteFX. В этом случае, кроме стандартных HTTPS создается дополнительный двусторонний UDP-туннель, защищенный протоколом DTLS (детальнее о нём можно почитать тут). Следует заметить, что созданный туннель обеспечивает не только максимальную производительность, но и определённую степень надёжности, что позволяет получать защищенное соединение с довольно приемлемым качеством отображения.
Поддержка изменения стандартных номеров портов для протоколов HTTPS и UDP
По умолчанию для соединения с сервером шлюза удалённых рабочих столов извне используется порт 443, а для связи с внутренними серверами фермы RDS порт 3389. В Windows Server 2012 появилась возможность изменить номера этих портов на нестандартные. Это бывает необходимо в целом ряде сценариев развёртывания.
Поддержка использования транспорта HTTP вместо RPC over HTTP
Для клиентов, которые используют для связи протокол RDP 8.0 предусмотрена возможность использовать транспорт HTTP вместо RPC over HTTP. Недостаток последнего метода транспортировки заключается в том, что процедуры RPC вызываются и при передаче данных от клиента и к нему, что приводит к увеличению излишней нагрузки на ЦП сервера. И как следствие, использование транспорта HTTP позволяет увеличить число одновременных подключений к шлюзу.
Больше об новшествах в службе RD Gateway можно узнать из официального блога разработчиков RDS.
Установка службы RD Gateway
В рассматриваемом случае, роль службы шлюза удалённых рабочих столов будет устанавливаться на сервер ещё не участвовавший в развёртывании. Поэтому, сначала его необходимо добавить в Диспетчер серверов.
Рис.2 — Добавление нового сервера в Диспетчер серверов
Запустить установку роли RD Gateway можно зайдя в Службы удалённых рабочих столов и там либо нажать на ссылку Шлюз удалённых рабочих столов в панели Обзор развёртывания либо в выпадающем меню Задачи на панели Серверы развёртывания выбрать пункт Добавить серверы шлюзов удалённых рабочих столов.
Рис.3 — Добавление шлюза удалённых рабочих столов к развёртыванию
Любое из описанных выше действий приведёт к вызову мастера установки роли шлюза удалённых рабочих столов. В первом окне выбираем сервер или несколько серверов на которые будет установлена роль RD Gateway.
Рис.4 — Выбор сервера для установки роли шлюза
После выбора серверов, роли шлюза необходимо присвоить самозаверяющий SSL-сертификат. В поле для ввода указываем полное внешнее имя к которому будут подключаться клиенты. В данном случае рассмотрен наипростейший вариант, в котором организация имеет зарегистрированное доменное имя domain.ext и к серверу шлюза можно обратиться по имени rdgw.domain.ext.
Рис.5 — Создание SSL-сертификата для роли шлюза
В окне подтверждения выбора удостоверимся, что заданные настройки верны и если это так, необходимо нажать на кнопку Добавить.
Рис.6 — Окно подтверждения выбора
После того, как сервер добавлен в развёртывание и на него установлены все необходимые службы, потребуется настроить сертификат подлинности. Сделать это можно прямо из окна развёртывания нажав на ссылку Настроить сертификат в уведомлении или позже зайдя в Свойства развёртывания (Диспетчер серверов > Службы удалённых рабочих столов > Общие сведения > Обзор развёртывания > Задачи).
Рис. 7 — Выполнение установки роли службы шлюза
В окне управления сертификатами, для роли шлюза удалённых рабочих столов, как и для прочих, можно задать уже существующий сертификат или создать новый. Так как в данном цикле статей не рассматриваются вопросы функционирования центров сертификации, то создадим новый самоподписанный сертификат. Для этого выбираем пункт Шлюз удалённых рабочих столов и затем Создать новый сертификат.
Рис.8 — Окно управления сертификатами служб RDS
При создании нового сертификата указываем внешнее доменное имя, по которому будут подключаться пользователи, пароль и место хранения сертификата. Кроме всего этого, необходимо установить галочку Разрешить добавление сертификата в хранилище «Доверенные корневые центры сертификации» на конечных компьютерах. Это необходимо для того, чтобы на клиентских компьютерах сертификат можно было установить вручную.
Рис.9 — Создание нового сертификата
После создания сертификата, необходимо применить его, нажав на соответствующую кнопку.
Рис.10 — Успешная установка сертификата для шлюза удалённых рабочих столов
Когда сертификат успешно создан и применен, из окна Ход выполнения (рис.7) можно перейти к свойствам шлюза удалённых рабочих столов. К этим же свойствам можно получить доступ и через Свойства развёртывания.
Окно свойств шлюза RDS позволяет настроить самые основные параметры, а именно: выполнить ли конфигурацию RD Gateway в автоматическом режиме, задать настройки вручную либо вовсе не использовать службу шлюза удалённых рабочих столов. Если выбрана опция Использовать следующие параметры сервера шлюза удалённых рабочих столов, то нижеследующие параметры потребуется указать вручную:
После того, как служба шлюза удалённых рабочих столов была успешно установлена на выбранный сервер, во вкладке Общие сведения окна Службы удалённых рабочих столов в Диспетчере серверов можно увидеть, что иконка шлюза в обзоре развёртывания изменилась и приобрела вид туннеля, а на панели Серверы развёртывания добавился новый сервер.
Рис.12 — Службы удалённых рабочих столов после добавления сервера шлюза
Подключение пользователей к ресурсам фермы RDS с помощью шлюза
Все настройки клиента относительно использования шлюза выполняются в окне Подключения к удалённому рабочему столу (mstsc.exe). Для того, чтобы задать клиенту параметры подключения к шлюзу, необходимо на вкладке Дополнительно в разделе Подключение из любого места нажать кнопку Параметры.
Рис.13 — Настройки Подключения к удалённому рабочему столу
Окно параметров содержит в себе ровно те же настройки, что и окно свойств шлюза в настройках развёртывания RDS (рис.11). Здесь указываем полное доменное имя сервера шлюза, метод проверки подлинности, необходимость использования шлюза при подключении в локальной сети и необходимость использования учётных данных шлюза для удалённого компьютера. После нажатия на кнопку Подключить будет выполнено подключение к ферме RDS с помощью шлюза удалённых рабочих столов.
Рис.14 — Параметры подключения к шлюзу удалённых рабочих столов
На Windows RT и Windows 8/8.1 можно осуществлять подключение с помощью приложения Удалённый рабочий стол. Для того, чтобы указать сервер шлюза, через который будет установлено подключение, необходимо зайти в настройки приложения. Сделать это можно в окне приложения, нажав комбинацию клавиш Win+I, или зайдя в пункт Параметры панели Charms. Из панели параметров необходимо перейти в Параметры соединения, где, среди прочих настроек, можно указать параметры шлюза удалённых рабочих столов.
Рис.15 — Параметры шлюза удалённых рабочих столов в приложении Удалённый рабочий стол
В случае когда развернуты приложения RemoteApp и они подключены средствами Панели управления, приложений Удалённый рабочий стол или GPO, достаточно сперва выполнить обновление приложений (как описано в статье RDS на основе сеансов в Windows Server 2012 R2. Часть 4 — Распространение приложений RemoteApp и удалённых рабочих столов) и затем можно подключаться из внешней сети. Настройки шлюза при этом будут подхватываться в автоматическом режиме.
Рис.16 — Соединения с шлюзом удалённых рабочих столов
Если пользователь получает доступ к полному удалённому рабочему столу, то в свойствах подключения можно посмотреть информацию касательно шлюза. Сделать это можно с помощью пункта Сведения о шлюзе контекстного меню окна соединения.
Рис.17 — Сведения о шлюзе
В этой статье были рассмотрены основные вопросы касающиеся службы шлюза удалённых рабочих столов, а именно процесс работы шлюза и установка роли шлюза в существующее развёртывание RDS. А так же подключение к ресурсам фермы удалённых рабочих столов через шлюз с помощью приложений Подключения к удалённому рабочему столу (mstsc.exe) и Удалённый рабочий стол.
В следующем материале будет рассмотрена настройка серверов шлюзов с помощью инструмента Диспетчер шлюза удалённых рабочих столов.