Server 2012 - DirectAccess - частина 1 (клієнти Windows 8)
У рамках підготовки до екзамену 70-411 (Administering Windows Server 2012) я пропрацював можливість роботи з технологією DirectAccess.
Т.к. згодом деякі нюанси можуть забути, вирішив написати статтю, в якій буде висвітлено цю роль Server 2012.
У двох словах технологія DirectAccess дозволяє співробітникам, незалежно від того, де вони знаходяться (всередині офісної мережі або десь поза нею) працювати з внутрішніми корпоративними ресурсами, причому з'єднання відбувається прозоро для користувача.
Механізм роботи наступний:
При налаштуванні DirectAccess вказується якийсь внутрішній хост, який перевіряється на доступність клієнтськими ОС. Якщо перевірка на доступність виявиться негативною, клієнт вважатиме, що знаходиться поза офісною мережею і намагатиметься побудувати захищений SSL канал до сервера DirectAccess. Для співробітника дана процедура абсолютно прозора та невидна.
Цю технологію підтримують клієнтські ОС версій Windows 7 Ultimate, Windows 7 Enterprise, Windows 8 Enterprise або Windows 10 Enterprise, включених до домену.
У цій частині статті ми налаштуємо DirectAcces для роботи клієнтських систем Windows 8 (дані системи не вимагають використання PKI на відміну від Windows 7).
У нас вже є (віртуальне середовище Hyper-V):
- Server 2012R2 з роллю DC, який обслуговує домен dzuba.local – ім'я DC01
- На DC01 створюємо групу безпеки dzuba\directaccess_clients (дана група буде використовуватись у подальшому налаштуванні)
- Server 2012R2 з двома мережними інтерфейсами (внутрішня та зовнішня мережа) - на нього буде встановлена роль DirectAccess - ім'я GW
- клієнтська OC windows 8 Enterprise - ім'яWin8
- клієнтська OC windows 7 Enterprise (будемо з нею працювати в наступній частині статті) — ім'я Win7
Підготовляємо сервер GW для встановлення ролей RRAS та DirectAccess:
Налаштування мережної карти local:
Налаштування мережної картки inet:
Розширені налаштування мережевих адаптерів:
Починаємо встановлення ролей:
Після встановлення ролей приступаємо до налаштування.
Натискаємо Open the Getting Started Wizard.
На наступному етапі вибираємо тип розташування нашого сервера.
Сценарія розташування 3:
- Edge - розташування на периметрі мережі з двома мережними адаптерами один з яких дивиться в локальну мережу, а другий в інтернет.
- Behind an adge device (with two network adapters) — розташування за фаєрволом у мережі периметра з двома мережними адаптерами одне із яких дивиться у локальну мережу, а другий у мережу периметра.
- Behind an adge device (with a single network adapter) — розташування локальної мережі з одним адаптером.
Розглянемо всі три варіанти:
Помилка виникає така:
При виборі другого варіанта я зіткнувся з ситуацією, коли після застосування параметрів DirectAccess перестає працювати NAT в RRAS.
Я не знайшов опису цього «обмеження» в документації, але на просторах інтернету така поведінка відома (мабуть, що ця поведінка штатна):
Ця поведінка накладає обмеження на використання технології DirectAccess на сервері із встановленим RRAS та налаштованимNAT.
Тобто такий сервер не може використовуватися в ролі шлюзу для локальної мережі, а використовуватиметься лише як виділений сервер віддаленого доступу.
На мій погляд найоптимальніший варіант це третій - сервер з роллю DirectAcces, який має один мережевий адаптер і встановлений усередині локальної мережі. Для можливості підключення зовнішніх клієнтів необхідно прокинути лише один порт – 443.
Також на цій сторінці ми вказуємо зовнішнє DNS ім'я, до якого будуть підключатися клієнтські ОС, які знаходяться поза офісною мережею — da.dzuba.com.ua (це ім'я вигадане, а в реальних умовах це ім'я має резолвуватися в інтернеті)
Натискаємо далі та потрапляємо на наступну сторінку, де нам потрібно змінити додаткові параметри.
На наступній сторінці нам потрібно змінити групу, на яку буде поширюватися налаштування DirectAccess:
Подальші налаштування такі:
Вказуємо раніше створену групу Dzuba\directaccess_clients і знімаємо пташку з Enable DirectAccess for mobile computers only — якщо ми її залишаємо на GPO будуть застосовуватися додаткові WMI фільтри, які обмежать застосування політики підключення тільки для мобільних комп'ютерів (у нашому тестовому середовищі це не потрібно)
Вказуємо додатковий параметр визначення знаходження клієнтської ОС – вказуємо перевірку на доступність DC01
Натискаємо кнопку Finish і потрапляємо на попередню сторінку, де також натискаємо на кнопку Finish і спостерігаємо, як відбувається конфігурація DirectAccess.
Якщо зайти в Operations Status, ми побачимо, що всі перевірки пройдені без помилок:
Також варто переконатися, що й інші налаштування майстервиконав коректно (Заходимо на DC01 до Group Policy Management)
DirectAccess Server фільтрується для сервера GW:
А політика DirectAccess Clinet фільтрується для групи безпеки directaccess_clients:
Якщо зайти в оснастку DNS сервера, можна побачити створені майстром такі записи:
Опис призначення DNS записів є у блозі Річанда Хікса:
Налаштування завершено, тепер додаємо клієнтський комп'ютер Win8 до групи directaccess_clients та виконуємо перезавантаження клієнта.
Після перезавантаження на клієнті додалося нове підключення до мережі.
Перш ніж приступити до тестів, на віртуальній машині Win8 ми додамо запис у файл hosts, щоб комп'ютер зміг підключитися за ім'ям DNS, яке ми вказали в налаштуванні DirectAcces:
Тепер емулюємо ситуацію, коли клієнт опиняється поза корпоративною мережею (міняємо віртуальний світильник з Private на Ext у властивостях віртуальної машини Win8).
Через кілька секунд можемо спостерігати, що стан Dzuba Connection змінилося:
Якщо ж подивитися на сервер за участю DirectAccess, то в оснащенні Remote Access Management ми можемо побачити інформацію про кількість підключених клієнтів та їх параметри:
Ми закінчили налаштування DirectAcces для роботи з клієнтами Windows 8.
У наступній частині статті ми налаштуємо DirectAccess для роботи з версією клієнтів Windows7.