Directaccess в Windows Server 2012 / 2012 R2

С момента появления технологии Directaccess в Windows Server 2008 R2 уже прошло достаточно времени чтобы она начала приживаться в корпоративной окружении. В этой статье я рассмотрю, на мой взгляд, важные моменты касаемо сути и практической пользы, которую несет эта технология. Хотя текущая версия серверной операционной системы 2012 R2, само обновление R2 особых изменений не принесло. Поэтому, данная статья справедлива как версии 2012, так и к 2012 R2, собственно этим и обуславливается название. Во время написания статьи, я буду предполагать, что читатель не знаком с технологией и видит ее впервые. Если же есть теоретический и практический опыт, предлагаю к рассмотрению будущие статьи в которых будут изложены варианты развертывания Directaccess. Ниже, предлагается логическая структура содержания этой статьи:

  • Что такое Directaccess?
  • Преимущества Directaccess
  • Что нового в Directaccess Server 2012 / 2012 R2
  • Технологический фундамент
  • Как Directaccess работает?
  • Выводы

Что такое Directaccess?

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

Важно определиться зачем это нужно, ведь такие продукты как Exchange, Lync, SCCM обладают шлюзовыми технологиями которые обеспечивают поддержку внешних клиентов. К сожалению, такие сервисы как Active Directory не обладают подобным функционалом, так как во время их создания не предполагалось такое использование. Выход же будет в использовании ряда других технологий, которые смогут обеспечить “общение” удаленного клиента с ресурсами так как будто он находится в пределах сети организации. К таким можно отнести виртуальные частные сети (VPN) и Directaccess.

Directaccess – это набор технологий, дающий возможность клиенту прозрачно подключатся к корпоративной инфраструктуре. Чуть ранее, я упомянул о двух технологиях, одна из которых VPN. Говоря о VPN, со стороны пользователя это выглядит так: пользователь должен зайти в систему и подключится к VPN серверу, только после успешного подключения он сможет получить доступ к нужным ему ресурсам. А стороны IT персонала: пока пользователь не подключится, компьютер является не управляемым, что есть плохо. Выводом будет тот факт, что в случае желания IT персонала получить доступ к рабочей станции, он является заложником воли пользователя, что есть плохо. Directaccess решает эту проблему.

Отходя от полемики, технически компьютер при подключении к сети проверяет свое местоположение (корпоративная ли нет). Если он подключен к сети интернет, он пытается установить свой собственный туннель, по которому он будет получать групповые политики, общаться с контроллером домена и т.д. Пользователь же, когда осуществляет вход в систему, инициализирует поднятие второго туннеля. По факту получается так, что сам компьютер никаким образом не зависит от пользователя, что не может не радовать.

Преимущества Directaccess

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

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

Что нового в Directaccess Server 2012 / 2012 R2 по сравнению с Server 2008 R2

Впервые технология появилась в версии Server 2008 R2, и, хотя она с самого старта предвещала огромный потенциал, реализация требовала весьма внушительных затрат. Основные требования к развертыванию, в редакции 2008 R2, были очень серьезные:

  • Наличие инфраструктуры IPv6. Самая большая проблема с которой сталкивались компании на моменте внедрения. Причин не перехода, на новую версию протокола IP можно найти массу, начиная от банального отсутствия поддержки на стороне сетевого оборудования заканчивая не полной поддержкой самих операционных систем. Конечно же существовал выход из ситуации в использовании NAT64/DNS64 преобразования IPv6 в IPv4, но для этого необходимо было покупать довольно тяжеловесный продукт Unified Access Gateway (UAG). Продукт довольно сложный в конфигурировании и не отличавшиеся дешевизной.
  • Поддерживался только сценарий пограничного сервера с двумя сетевыми адаптерами и наличием 2-х публичных IPv4 адресов на внешнем интерфейсе.
  • PKI инфраструктура. Для работы IPsec одно из требований, это наличие инфраструктуры открытого ключа. Даже сей час не у многих компаний инфраструктура реализована.

В редакциях 2012 и 2012 R2, технология была улучшена в сторону облегчения развертывания. Основные возможности:

  • Добавлены дополнительные сценарии развертывания. В отличии от Server 2008 R2, версия в Server 2012 / 2012 R2 поддерживает 3 сценария
  1. пограничный сервер с двумя сетевыми интерфейсами;
  2. пограничный сервер в DMZ зоне с двумя сетевыми интерфейсами;
  3. сервер во внутренней сети с одним интерфейсом. Причем допускается что на интерфейсе будет установлен частный IPv4 адрес.
  • При развертывании сервера в качестве пограничного, требование в наличии 2-х публичных IPv4 адресов не является обязательным, но рекомендованным.
  • Наличие PKI. Данное требование стало не обязательным при использовании клиентов Windows 8/8.1 редакции Enterprise или Ultimate. Это стало возможным из-за использования нового метода аутентификации компьютеров  – Kerberos-прокси. Суть метода заключается в том, что запрос проверки подлинности от клиента будет передаваться proxy-службе Kerberos работающая на стороне DA сервера. Далее служба от имени клиента будет слать Kerberos запросы к контроллерам домена. Если же используются мобильные клиенты Windows 7 Enterprise или Ultimate, наличие PKI остается обязательным.
  • Наличие инфраструктуры IPv6. Теперь наличие инфраструктуры IPv6 не обязательно. NAT64/DNS64 строены в сервер Directaccess и не требуют для своего развертывания UAG.
  • Поддержка сценариев геораспределенности Directaccess серверов, развертывания в многодоменных лесах Active Directory.
  • DirectAccess поддерживает сценарий, при котором клиенты не получают доступ к внутренним ресурсам корпоративной сети, а само подключение будет служить только для удаленного управления.
  • Управление через Powershell.
  • Ведение отчетов о подключении внешних клиентов.
  • Возможность развертывания Directaccess и VPN на одном сервере и управление через единую консоль управления. В редакции Server 2008 R2, DirectAccess и RRAS были отдельными службами и не могли быть развернуты на одном сервере.

Технологический фундамент

Как и положено хорошей технологии, DA стоит на технологических китах, их всего четыре:

  • Использования протокола IPv6
  • Транзитные технологии
  • IPSec поверх IPv6
  • Таблица политики разрешения имен (Name Resolution Policy Table, NRPT)

IPv6

Directaccess построен на IPv6 и без него работать не умеет. Выбор именно 6-й версии обуславливается тем, что она избавлена от множества недостатков присущих IPv4 и ориентирована на ближайшее будущее. Преимуществ 6-й версии над 4-й множество и это тема отдельной статьи. Нам же интересны те, которые нам помогут в понимании работы DA.

Огромное адресное пространство. В реализации IPv4 все адресное пространство составляет 232. Это является проблемой существующего интернета, так как количество хостов уже давно вышло за пределы максимального. Реализация протокола 6-й версии эту проблему решает, так как обладает адресным пространство уже 2128. Пространство огромно, и по мнению экспертов его хватит на ближайшее будущее. В спецификации IPv4, прописаны так называемые частные сети, к ним относятся адреса из диапазонов 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Эти адреса служат для построения частных сетей предприятий. В реализации IPv6, так же присутствуют диапазоны частных адресов. При использовании частного пространства IPv6, клиент получит уникальный адрес не только в пределах частной сети, но и в пределах всех сети интернет.

Отсутствие NAT. В спецификации IPv6 эта технология отсутствует. Когда возникает этот вопрос, многие IT специалисты впадают в ступор, так как теперь на интерфейсе каждого сервера будет реальный IPv6 адрес, и вариант «а давайте-ка мы закрутим гайки на фаерволе и все будет хорошо» просто стал не актуальным.

Важно понимать, во время разработки спецификации протокола IPv4, использование NAT вообще не предполагалось. Задача, которую эта технология должна была решить, это как раз нехватка адресного пространства, но никак не обеспечение сетевой безопасности.

Для решения самого вопроса безопасности конечных хостов, в распоряжении IT специалистов есть те же Firewall-ы, которые необходимо настроить на прием, только определенного вида трафика. Помимо всего, существуют прочие прелести сетевой безопасности, которые выходят за рамки текущей статьи.

Directaccess использует только туннели построены на IPSec, что дает взаимную аутентификацию клиента и сервера, на уровне хостов, потом на уровне сертификатов и учетных данных пользователя. Так как NAT был расстрелян в спецификации IPv6, для нас появляется возможность не ограничиваться подключением типа точка-точка (стандартная работа NAT), а использовать сервер Directaccess как IPv6 маршрутизатор и напрямую, от внешнего клиента до запрашиваемого сервера, строить IPSec туннели.

Транзитные технологии

В идеальном сценарии использования Directaccess предполагается, 3 участника: клиент, сервер Directaccess и сам сервер к которому обращаются, при чем у всех троих должны быть IPv6 адреса. К сожалению, реальность такова, что не везде есть поддержка протокола 6-й версии и наличие IPv4 может быть, как на отрезке между клиентов и сервером DA, так и между сервером DA и запрашиваемым сервером. Для того чтобы DA все же работал в условиях IPv4, в нашем арсенале есть ряд транзитных технологий, которые сослужат хорошую службу. К ним относится 6to4, Teredo, IP-HTTPS, ISATAP.

Когда клиент начинает строить туннель, ему необходимо выбрать одну из транзитных технологий. На выбор непосредственным образом будет влиять текущая IP конфигурация  которую он получил  от провайдера. Рассмотрим возможные варианты:

  1. DA клиент от ISP получил IPv6-адрес. Это идеальный вариант, в этом случае его пакеты будут маршрутизироваться к DA серверу без использования каких-либо транзитных технологий.
  2. Клиент получает реальный IPv4-адрес. Это более распространённый вариант, в этом случае использоваться транзитная технология 6to4. С ее помощью на клиенте будет сформирован IPv6-адрес вида 2002:WWXX:YYZZ::/48, начинающийся с 2002 (префикс 2002 указывает на транзитную технологию 6to4) содержащий в полях WWXX:YYZZ публичный IPv4-адрес. 6to4 Теперь, будет происходить инкапсуляция пакетов IPv6 в пакеты IPv4 с последующей доставкой по месту назначения через сети IPv4.
  3. Клиент от провайдера получил IPv4 адрес типа 192.168.15.86. Это еще более распространённый вариант, в этом случае используется технология Toredo. Задача Toredo, это прохождение IPv6 трафика не только через IPv4 сети, но и через NAT трансляцию. По структуре, формат пакета Toredo сложнее чем 6to4 и выглядит так: Teredo Все адреса Teredo начинаются с префикса 2001, а поля Obscured External Port и Obscured External Address содержат соответственно внешний UDP-порт и внешний IP-адрес, используемые NAT.
  4. Клиент от провайдера получил IPv4 адрес типа 192.168.15.86 но открыты только порты 80 и 443. Вариант, с которым можно столкнутся во время использования публичных точек Wi-Fi либо в различных гостевых сетях или сетях за прокси серверами. В этом случае используется протокол IP-HTTPS, как следует из названия, протокол обеспечивает передачу IPv6 адреса с помощью инкапсуляции в HTTPS. Эта транзитная технология будет использоваться только в случае, если использование всех вышеперечисленных технологий не увенчалось успехом.

После того, как пакет добрался до DA сервера, задачей сервера будет доставить его к получателю. В идеальном сценарии у получателя IPv6 адрес, в этом случае будет осуществлена маршрутизация. Если же инфраструктуры IPv6 нету, на помощь приходит еще одна транзитная технология ISATAP. Использование ISATAP требует, чтобы на хосте был назначен IPv4 адрес, на его основании будет сформирован IPv6 адрес у которого последние 32 битами соответствуют IPv4 адресу. Формат адреса будет иметь вид FE80::5EFE:192.168.56.45. Когда DA-сервер хочет отправить IPv6-пакет через IPv4-роутер он использует DNS, узнает IPv4-адрес получателя, используя эту информацию формируется специальный IPv6-пакет ISATAP-типа. Пакет упаковывается в IPv4 и пересылается получателю. Получив пакет, во время распаковки, извлекает информацию об исходном IPv6-пакете и отправляет его в дальнейшею обработку.

IPSec поверх IPv6

Directaccess основой лежит на использовании, в качестве мер защиты трафика, IPsec. Во время появления протокола IPv4, спецификации IPsec не существовало. Чтобы хоть как-то ее использовать связку этих протоколов, был придуман хитрый способ IPsec over IPv4. В версии протокола IPv6, поддержка заголовков IPsec присутствует из коробоки, хотя это не обязательное требование, но в нашем случае при использовании Directaccess является вполне логичным способом защиты трафика.

IPSec поддерживает два варианта защиты: Authentication header (AH) и Encapsulating Security Payload (ESP).

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

В ESP, помимо снабжения пакета цифровой подписью, данные так же будут зашифрованы.

Варианты защиты IPSec, могут комбинироваться друг с другом. В DA, в зависимости от комбинации, при развертывании существуют различные модели доступа:

  • Full Intranet Access (End-to-Edge) В первой модели трафик по IPSec подвергается шифрованию и передается от клиента к серверу DA. На стороне сервера происходит расшифровка данных, дальше они идут к месту назначения в не зашифрованном виде.End-to-edge protection
  • Selected Server Access (Modified End-to-Edge) Во второй трафик от клиента к серверу DA шифруется, но дальше во внутренней сети используется только вариант защиты AH. Такой подход позволяет обеспечить доступ только определенных клиентов к определенным серверам и приложениям в корпоративной сети.
  • End-to-End. В третьей данные шифруются на стороне клиента, а расшифровываются только на стороне сервера назначения. Сервер DA будет обеспечивать только маршрутизацию. Подобный подход обеспечивает самый лучший уровень безопасности.End-to-end protection

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

Таблица политики разрешения имен (Name Resolution Policy Table, NRPT)

Name Resolution Policy Table (NRPT) – это способ разрешения имен с применением таблицы NRPT и системы DNS. Когда DA-клиент находится в сети интернет, он должен понимать, какие имена являются внутренними, и, соответственно, должны разрешаться корпоративным DNS-сервером, а какие – внешними, разрешением которых должны заниматься DNS-серверы в Интернете.
Таблица NRPT позволяет задавать DNS-сервер не для сетевого интерфейса, а для некоторого пространства имен. Каждый раз, находясь за пределами корпоративной сети, при разрешении имени, например, srv1.adatum.com, DA-клиент сначала проверяет, есть ли для данного имени либо его части строчка в NRPT. Если есть, за разрешением этого имени клиент обращается к DNS-серверу, указанному в соответствующей строке NRPT для данного пространства имен. Если нет, то обращение происходит в DNS-серверу, указанному в настройках сетевого интерфейса, то есть к DNS провайдера.

Как Directaccess работает?

components

Развертывание DA предполагает множество компонентов:

  • Доменные службы Active Directory. Сервера AD используют ADDS для проверки подлинности учетных данных, и для централизованной настройки клиентов DA через групповые политики.
  • Сервер сетевого размещения (NLS Server). Это сервер расположенный во внутренней сети, на котором размещен веб сайт работающий по протоколу HTTPS. Служит для поддержки механизма обнаружения клиентами своего местоположения. Находятся ли они во внутренней сети компании либо во внешней сети интернет.
  • PKI. Хотя в редакции Windows server 2012 / 2012 R2 наличие инфраструктуры открытого ключа не является обязательной нормой, все же на мой взгляд, их наличие должно быть при развертывании DA. Как ранее я упоминал, если используются клиенты Windows 7, наличие этих служб является обязательным.
  • Клиенты DA. Это компьютер под управлением системы Windows 7, 8, 8.1 редакции Enterprise или Ultimate или Windows Server 2008 R2, 2012, 2012 R2. Он должен входить в домен Active Directory и использовать протоколы IPv6 и IPsec. Понятное дело, что компьютерах которые не входят в домен Active Directory или младше Windows 7 или Windows Server 2008 R2 не поддерживают DA.
  • Сервер DA, компьютер под управлением Windows Server 2012, 2012 R2 водящий в домен Active Directory и использующий протоколы IPv6 и IPsec для взаимодействия с клиентами через интернет.

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

internal_directaccess

Рассмотрим первый вариант, когда клиент находится в пределах сети компании.

Клиент DA берет DNS адреса серверов, которые настроены на сетевых интересах. С помощью их, он пытается разрешить имя NSL сервера. Если разрешение прошло успешно, он пытается к нему обратится. При успешном обращении клиент удаляет правило DirectAccess из NRPT таблицы. После этого компьютер обращается к контроллеру домена для авторизации, далее будет назначен доменный профиль сети. Клиент успешно определил что находится в пределах сети предприятия и не будет пытаться связаться с DA серверами для установления с ними туннелей.

external_directaccess

А теперь рассмотрим сценарий, когда клиент находится за пределами сети компании.

Клиент пытается разрешить имя NLS сервера используя публичные DNS сервера настроенные на интерфейсах, конечно же попытка будет не удачной. В это случае правило DirectAccess из NRPT таблицы не удаляется и сети устанавливается публичный профиль. Следующим шагом будет установление туннеля к DA серверу, какая транзитная технология будет в этом использоваться зависет от типа подключения клиента (смотри транзитные технологии) а так же метода развертывания DA сервера. На следующем шаге, начинает работу NRPT, все запросы которые входят во внутреннее пространство имен адресуются IPv6 адресу DNS сервера внутри компании. Клиент находит контроллер домена и проходит процедуру авторизации. После прохождения всех процедур подключений и проверок, клиент может обращаться к внутренний ресурсам.

Выводы:

В этом довольно подробном обзоре, я рассмотрел основы работы технологии DirectAccess. Напомню суть технологии – это постоянное подключение к внутренней инфраструктуре компании, при этом пользователи могут работать с локальными ресурсами так как бы они находились в стенах офиса. В будущих статьях я приступлю к рассмотрю 3-х сценариев развертывания Directaccess в Server 2012 R2.

Пожалуй, все:)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.