Пересилання 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 описує місце шлюзу серед хоста сеансів та інших компонентів, і це той контекст, який робить його вартість зрозумілою.