Пересылка SSH, VPN или RD Gateway: какой путь для одного рабочего стола RDP?

Все три варианта передают RDP, поэтому протокол не является решающим фактором. Настоящий вопрос в том, сколько доступа должен получить один пользователь и кто эксплуатирует то, что его даёт. Переадресованный TCP-порт, маршрутизированная частная сеть и шлюз рабочего стола отвечают на этот вопрос в трёх разных размерах. Сначала выберите размер, а продукт последует за ним.

Вопрос в масштабе, а не в протоколе

Запишите, к чему пользователю на самом деле нужно прикасаться. Если ответ — один рабочий стол, проект, предоставляющий подсеть, слишком широк. Если ответ — рабочий стол плюс общие файлы плюс консоль администрирования, проект с переадресацией одного порта вернётся в следующем месяце ещё за двумя переадресациями. Список назначений — это требование; всё остальное — реализация.

Держите идентичность входа отдельно от учётной записи Windows, которая входит на рабочий стол. В каждом проекте ниже есть и то и другое, а их смешение — это то, как учётная запись хоста перехода получает больше прав, чем кто-либо предполагал.

Одна переадресованная служба TCP

Одобренный хост перехода SSH может переадресовать локальный слушатель на службу RDP, до которой он дотягивается. Привяжите этот слушатель к loopback, когда он существует только для машины самого пользователя, что и является обычным смыслом локальной переадресации. Переадресация — удобство для одного человека, а не служба для команды.

Вход по SSH аутентифицирует доступ к пути переадресации и ничего больше. Аутентификация Windows и авторизация RDP по-прежнему происходят в пункте назначения, поэтому действительная учётная запись перехода не является действительным сеансом рабочего стола. Это два независимых шлюза, и оба должны открыться.

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

Маршрутизированное частное рабочее пространство

VPN даёт частный DNS и доступ к нескольким совместно используемым службам, и в этом его настоящая ценность. Скрытие одного порта рабочего стола — побочный эффект, а не причина его строить. Это различие важно, когда кто-то спрашивает, зачем VPN вообще существует.

Ограничьте маршруты и права на ресурсы намеченными назначениями. Подключённый пользователь не получает автоматически всю локальную сеть, а межсетевой экран назначения плюс права входа Windows остаются отдельными границами, которые VPN не заменяет.

Такая схема удобна для уже сложившегося управляемого рабочего пространства. Цена в том, что ввод в эксплуатацию, требования к устройствам, поведение распознавания имён и политика подключения становятся частью рабочей среды пользователя, и кто-то должен ими владеть. Сравните эту цену с лицензированием шлюза, прежде чем считать VPN более дешёвым вариантом.

Шлюз, специфичный для RDP

Remote Desktop Gateway обеспечивает границу, специфичную для RDP, а не сетевую. Его политика авторизации подключений решает, кто может подключаться, а политика авторизации ресурсов решает, до каких внутренних ресурсов они могут дотянуться через него. Обе политики являются частью продукта, а не необязательными дополнениями.

Планируйте сертификаты, интеграцию идентичности и необходимые транспорты вместе. Шлюз не является анонимным ретранслятором TCP, и развёртывание его в таком виде обходит политики, которые его оправдывают. Он также несёт лицензионные и эксплуатационные требования, которых нет у одного переадресованного порта. Заложите их в бюджет до проектного обзора, а не после.

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

Что по-прежнему нужно всем трём

Сохраняйте проверки идентичности хоста в каждом проекте. Локальный псевдоним или туннель не делают неожиданный сертификат безвредным, а принятие несовпадающего сертификата, чтобы пройти через прокси, сводит на нет смысл туннеля. Имя в клиенте и имя в сертификате нужно сознательно согласовать.

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

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