TMG та Remote Desktop Gateway - на одному сервері, mvvrus
TMG та Remote Desktop Gateway – на одному сервері.
Замість вступу.
Фірма Microsoft не страждає на мінімалізм. Вона часто рекомендує відводити під кожну функцію (серверний продукт або роль або групу пов'язаних ролей Windows Server) на окремому сервері. Microsoft можна зрозуміти. З одного боку, фірма вона велика, клієнти їй теж все більше цікаві немаленькі (бо бюджети на IT у них теж немаленькі), а в таких контрах кожна така функція цілком здатна повністю завантажити і не один сервер. З іншого боку, що менше функцій виконує сервер, то простіше забезпечити його працездатність, надійність і безпеку. Нарешті, що більше серверів — то більше вписувалося ліцензій, що з Microsoft — зрозуміло, прямий прибуток.
Але для тих, хто, подібно до мене, працює в малому та середньому бізнесі, такий підхід малоприйнятний — він веде до розтрати серверних ресурсів. І навіть віртуалізація становища не рятує. Якщо використання процесора і пам'яті вона дозволяє зробити більш ефективним, то зі зменшенням витрат на ліцензії справа набагато гірша. Редакція Entetprise практично не дає виграшу в ціні ліцензії на один сервер у порівнянні зі Standard (навіть якщо використовувати її для ліцензування всіх дозволених 4-х віртуальних машин, які не завжди потрібні в такій кількості). Редакція Datacenter для малого-середнього підприємства явно надмірна, особливо якщо врахувати, що їй потрібен сервер з кількома фізичними процесорами — а це в наш час багатоядерних процесорів може бути само по собі розкішшю.
Ось і доводиться мені та моїм колегам шукати та знаходити способи поєднання кількох функцій на одному сервері. Про одне з таких поєднань я зараз розповім.
Постановка задачі та можливі проблеми зсумісністю.
Отже, ми плануємо розмістити на одному сервері, що відіграє роль шлюзу в мережу нашого підприємства, і міжмережевий екран – продукт Threat Management Gateway 2010 (далі – TMG), і шлюз для серверів терміналів – роль Remote Desktop Gateway Windows server 2008 R2 (далі – RDG ). Що може завадити цьому?
Якщо TMG використовується лише як проксі-сервер і міжмережевий екран для вихідних підключень в Інтернет, то встановити і використовувати його разом з RDG просто: спільно використовуваних ресурсів, через які можливий конфлікт, у цьому випадку немає.
На щастя, політики віддаленого доступу, які створює за умовчанням для своїх потреб RDG, налаштовані таким чином, що використовувати їх може лише RDG, на RRAS вони не впливають і навпаки – політики, які використовуються локальним RRAS не впливають на RDG.
Рішення. Примушуємо TMG та RDG працювати спільно.
Наступний крок – встановлення на шлюзі ролі Remote Desktop Services з єдиною службою ролі Remote Desktop Gateway. Роль встановлюється звичайним чином через майстер додавання ролей. На сторінці вибору ролі та вибору служб ролі вибираємо відповідно Remote Desktop Services та Remote Desktop Gateway і погоджуємося з утановкою необхідних ролей (Веб-сервер і сервер політики мережі) та компонентів. На сторінці вибору сертифікатів вказуємо, що сертифікат ми виберемо пізніше (варіант Choose a certificate for SSL encryption later). Політики підключення та ресурсів модно налаштувати і на етапі встановлення ролі, і пізніше – у нашому випадку це не відіграє жодної ролі. Налаштування ролей Network Policy and Access Server та Web Server (IIS) також залишаємо за замовчуванням. Тиснемо кнопку Install і чекаємо установки RDG.
Тепер RDG необхідно налаштувати, тому що у встановленому таким чином станівін ще непрацездатний. Заходимо в оснастку управління RDG (через Server manager або через меню Адміністрація), вибираємо в панелі навігації зліва наш сервер і натискаємо No у відповідь на пропозицію перезапустити службу RD Gateway, тому що сертифікат, який використовується IIS, не відповідає сертифікату RDG (адже сертифікат ми ще не встановили). На панелі деталізації ми бачимо попередження про те, що сервер налаштований не повністю.
Щоб налаштувати RDG на сервері, заходимо в режим редагування його властивостей (за допомогою кнопки Properties на панелі дій чи команди локального меню). На вкладці SSL Certificate вибираємо варіант "Select an existing cerificate ..."
і потім, натиснувши кнопку Import certificate, вибираємо зі списку саме той сертифікат, який використовується прослуховувачем. На вкладці SSL Bridging ставив галочку навпроти Use SSL Bridging та вибираємо варіант HTTPS-HTTP bridging
Натискаємо кнопку OK і вибираємо Yes у вікні з пропозицією перезапустити службу RD Gateway. Після деякого очікування з'являється ще одне вікно, тепер з пропозицією перезапустити пул додатків IIS, що використовується для виконання компонента RPC over HTTP. Знову ж таки, вибираємо Yes.
Адреси, які використовуватиме драйвер http.sys, вказуються командою
netsh http add iplisten
От і все. Налаштований таким чином шлюз крім функцій, що забезпечуються TMG, виконуватиме і функції шлюзу віддалених робочих столів — що у багатьох випадках дозволить позбутися потреби зайвих підключень VPN.