В среде Windows Server 2008 R2 установка и настройка DirectAccess сопряжены с немалыми трудностями. Администратор должен осуществить весьма сложный процесс настройки, в том числе обеспечить выполнение требований к инфраструктуре открытых ключей public key infrastructure (PKI), получить сертификаты для серверов, настроить сервер сетевых расположений, позаботиться о том, чтобы целевые системы поддерживали протокол IPv6 и задействовать шлюз Forefront Unified Access Gateway (UAG). Теперь ситуация радикально изменилась. В среде Windows Server 2012 установка и настройка средств DirectAccess не составляют проблемы — если вы пользуетесь клиентами Windows 8. Перед тем как приступать к описанию радикально усовершенствованного процесса установки, я сделаю шаг назад и расскажу вам о том, что же это такое — DirectAccess — и каким образом данное решение может помочь организации.

Что такое DirectAccess?

Когда я начинал свою трудовую деятельность на посту системного администратора VAX/VMS, мой рабочий день продолжался с 8 утра до 5 пополудни. Все это время я занимался рабочими системами (включая систему обработки электронной почты), и мне никогда не приходилось иметь дело с вычислительными системами за пределами офиса. Сегодня идея работы в офисе с 8 до 5 отмерла, а воображаемая линия, отделяющая работу от личной жизни, стала более размытой. Как ИТ-администраторам, так и конечным пользователям требуется возможность обращаться к системам и данным корпорации в любое время суток, и потому они должны постоянно располагать средствами сетевого соединения.

Традиционно существует два подхода к управлению доступом к корпоративным системам из-за периметра корпоративной сети.

Доступ по веб-протоколам, таким, как HTTP Secure (HTTPS). Такой доступ применяется при обращении к почтовым ящикам Microsoft Exchange с помощью ActiveSync, при обращении к сайтам SharePoint, которые публикуются в среде Web с соблюдением мер защиты, и даже при использовании дистанционного подключения настольных систем с помощью шлюза удаленных рабочих столов Remote Desktop Gateway, который инкапсулирует RDP-трафик в HTTPS.

VPN -туннели в среде Internet, соединяющие ту или иную систему с корпоративной сетью. При использовании этого метода пользователи вручную инициируют соединение с корпоративной сетью.

Применение протокола HTTPS — превосходное решение в тех случаях, когда оно доступно. Его достоинство в большинстве случаев состоит в том, что протокол «просто работает» и выполняется на множестве устройств. Однако HTTPS неприменим при использовании многих типов служб, таких, как бизнес-приложения. Кроме того, в ряде случаев организации не склонны задействовать этот протокол, даже когда он обеспечивает решение проблемы. В таких случаях можно воспользоваться традиционным «VPN-подходом». Но и он имеет свои недостатки.

Во-первых, пользователи должны вручную инициировать соединение, а это порой сопряжено с трудностями.

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

Чтобы вооружить потребителей еще одним средством управления доступом, Microsoft включила в продукты Windows Server 2008 R2 и Windows 7 компонент DirectAccess (версии Enterprise и Ultimate). DirectAccess обеспечивает соединение клиента с корпоративной сетью, функционирующее постоянно и не требующее вмешательства со стороны пользователя. Когда пользователи обращаются к тому или иному ресурсу Internet, применяется их обычное соединение со Интернет. Когда же пользователям требуется связь с корпоративным ресурсом, применяется туннель DirectAccess, обеспечивающий для них транспарентный доступ к нужному корпоративному ресурсу из любой точки. Чтобы определить, относится ли целевой ресурс к категории корпоративных ресурсов, DirectAccess сопоставляет DNS-суффикс целевого ресурса с содержимым таблицы политик разрешения имен Name Resolution Policy Table. Эта таблица включает правила, идентифицирующие DNS-суффиксы ресурсов, которые могут быть доступны лишь при установлении соединения через корпоративную распределенную сеть.

Так же, как и VPN, DirectAccess создает туннель между компьютером и корпоративной средой, однако между этими технологиями существует важное различие. Незаметно для стороннего наблюдателя DirectAccess фактически создает два туннеля. Первый из них — инфраструктурный туннель; он возникает в момент включения системы. Этот туннель дает возможность ключевым системам ИТ-инфраструктуры взаимодействовать с данным компьютером и осуществлять функции управления. После регистрации пользователя создается второй туннель. Этот внутрисетевой туннель дает пользователю возможность обращаться к системам корпоративной сети. Каких-то действий со стороны оператора при этом не требуется, поэтому пользователь может обращаться к корпоративным ресурсам, не испытывая каких-либо затруднений. Отметим, что для управления системой можно задействовать только инфраструктурный туннель без подключения внутрисетевого канала связи, ибо при работе с последним пользователь не имел бы возможности обращаться к корпоративным ресурсам.

Как видите, технология DirectAccess чрезвычайно удобна для пользователей, но еще большие преимущества она дает сотрудникам ИТ-служб. При использовании этого решения все данные, передаваемые через Интернет, проходят проверку подлинности и шифруются с помощью протоколов Ipsec, что обеспечивает возможность «бесшовного» и в то же время надежно защищенного подключения компьютеров пользователей к корпоративной сети. Вдобавок, поскольку компьютеры пользователей подключаются к ключевым системам ИТ-инфраструктуры всякий раз, когда эти пользователи запускают их, управление последними осуществляется без каких-либо затруднений.

DirectAccess предусматривает применение протокола IPv6. Но хотя индустрия информационных технологий вне всякого сомнения движется к принятию этой версии IP, переход осуществляется чрезвычайно медленно, и во многих сетях, включая Интернет, применяется преимущественно версия IPv4. В итоге при подключении к Интернету средства DirectAccess используют реализованные в IPv6 технологии перехода с тем, чтобы устанавливать соединения между сервером DirectAccess и клиентами, применяющими версию IPv4. К числу часто используемых технологий перехода относятся Teredo и IP over HTTPS (IP-HTTPS); обе эти технологии дают возможность туннелировать пакеты IPv6 внутри пакетов IPv4. В принципе здесь можно задействовать и технологию перехода 6to4. Однако эта технология не работает, когда клиент располагается за устройством, осуществляющим трансляцию сетевых адресов Network Address Translation (NAT). Между тем, почти все клиенты с каналом в Интернете располагаются за NAT-устройствами того или иного типа, так что технология 6to4 редко применяется в реальных условиях эксплуатации.

Иными словами, DirectAccess — изумительная технология, но вероятность того, что вы сможете отправить в отставку свое решение на базе VPN, чрезвычайно мала. Поясню эту мысль на примере. В версии Server 2012 DirectAccess может взаимодействовать только с входящими в состав домена системами Windows 8 Enterprise и Windows 7 Enterprise. Для связи со всеми другими устройствами — скажем, с домашними системами, не входящими в состав домена, с системами Windows 8 и Windows 7, не работающми с редакцией Enterprise, с мобильными телефонами, с устройствами, функционирующими под управлением отличных от Windows операционных систем, — вам по-прежнему придется применять VPN. Моя рекомендация такова: когда вы можете использовать технологию DirectAccess, используйте ее. Во всех прочих случаях вам придется применять решение на базе VPN. Если вы затрудняетесь определить, чем VPN отличается от DirectAccess, предлагаю следующее услышанное мною где-то определение: VPN подключает пользователя к сети, а DirectAccess расширяет сеть так, что она включает в себя соответствующий компьютер и пользователя.

DirectAccess в среде Server 2012

Чтобы развернуть работоспособную систему DirectAccess в среде Server 2008 R2, вам несомненно понадобится шлюз удаленного доступа Forefront UAG. Он позволяет упростить процедуру настройки и обеспечивает взаимодействие с целевыми системами IPv4. Версия Server 2012 включает в себя все технологии продукта Forefront UAG, имеющие отношение к DirectAccess, такие, как DNS for IPv6 to IPv4 (DNS64) и Network Address Translation for IPv6 to IPv4 (NAT64). Таким образом, средства DirectAccess будут работать в сети Server 2012, причем для этого вам не придется устанавливать дополнительные продукты, такие, как Forefront UAG.

В системе Server 2012 впервые реализована новая обеспечивающая возможность сетевого соединения роль Remote Access. С помощью этой роли вы сможете управлять средствами DirectAccess и сетями VPN (в том числе сетями VPN «сайт — сайт») таким образом, как если бы они были объединены в одну службу.

Кроме того, в системе Server 2012 были реализованы средства поддержки нескольких узлов, а также средства учета пространственных отношений. Последнее означает, что вы можете разместить в различных географических пунктах несколько систем DirectAccess (это могут быть как отдельные серверы, так и массивы), и клиенты будут использовать сайт, расположенный от них на минимальном расстоянии (что определяется путем измерения времени отклика). Время отклика определяется путем зондирования с помощью HTTP, в ходе которого тестируются средства подключения ко всем устройствам DirectAccess, указанным в существующей политике. Если тот или иной сайт не проходит испытания, клиенты будут обращаться к другим сайтам DirectAccess. Средства отслеживания наличия нескольких сайтов представляют собой внутреннюю функцию Windows 8. Однако если у вас возникла необходимость оснащения этой функцией клиентов Windows 7, существует возможность в той или иной степени задействовать ее. Здесь имеются определенные ограничения.

Если все клиенты вашей сети функционируют под управлением системы Windows 8, для работы Server 2012 DirectAccess инфраструктура PKI не требуется. При использовании клиентов Windows 7 данная инфраструктура необходима для применения стандартов IPSec, но сегодня эти протоколы могут функционировать с помощью цифровых билетов Kerberos; предоставление последних возлагается на сервер-посредник Kerberos, устанавливаемый на контроллерах доменов (DC).

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

  • сертификат компьютера и учетную запись компьютера (представленные в протоколе NTLM) для создания инфраструктурного туннеля;
  • сертификат компьютера и учетную запись пользователя для создания внутрисетевого туннеля после регистрации пользователя средствами Kerberos.

Описанную процедуру можно определить как своего рода «полуторафакторную аутентификацию», поскольку сертификат привязан к системе и к пользовательскому паролю. Однако во многих организациях считается необходимым использовать двухфакторную аутентификацию, поэтому в сетях DirectAccess, где задействованы клиенты Windows 7, часто применяются смарт-карты. При работе с клиентами Windows 8 физические смарт-карты более не требуются (хотя их можно использовать, как и прежде), поскольку в распоряжении пользователя имеется новая функция Windows 8 «виртуальная смарт-карта», которая управляет реализованным в этой системе доверенным платформенным модулем (TPM). В результате процесс развертывания существенно упрощается, затраты снижаются, а уровень защиты данных повышается. Системы Server 2012 DirectAccess также позволяют применять одноразовые пароли.

Изменения со стороны DirectAccess

Разработчики Microsoft внесли в механизм функционирования DirectAccess в среде Server 2012 множество изменений, а потому во многом изменились и требования со стороны этого продукта. Ниже перечислены наиболее существенные изменения, касающиеся требований к IP-адресам, к службе Active Directory (AD), а также к серверам и клиентам.

Изменения требований к IP-адресам. В операционной среде Server 2008 R2 для функционирования службы DirectAccess требуется два смежных общедоступных адреса IPv4, поскольку определить тип NAT-устройства, за которым размещается клиент, сетевой протокол Teredo может лишь в том случае, если он располагает двумя IP-адресами. В системе Server 2012 сервер DirectAccess можно размещать за устройством NAT. Таким образом, если это NAT-устройство присутствует в демилитаризованной зоне (DMZ), соответствующий сервер DirectAccess можно развертывать с использованием частных IP-адресов. Это означает, что теперь мы можем при желании развертывать службу DirectAccess на домашних компьютерах.

Важно отметить, что хотя большинство систем DirectAccess размещаются за устройствами NAT, оптимальный вариант при работе в Интернете состоит в использовании протокола Teredo, который не поддерживает технологию NAT. Так что идеальное решение — задействовать два смежных общедоступных IP-адреса, но если это невозможно, вам придется воспользоваться IP-HTTPS. В большинстве случаев клиенты не имеют общедоступных IP-адресов, что исключает возможность применения переходного механизма 6to4. Но, как подсказывает мой опыт, даже когда такая возможность существует, скажем, в мобильных сетях, порой возникают проблемы.

Изменения требований к AD. В настоящее время один экземпляр службы DirectAccess может обслуживать сети, состоящие из нескольких лесов, — нужно только, чтобы между этими лесами существовали двусторонние отношения доверия. Хотя администратор должен по-прежнему готовить сценарии, предусматривающие обмен данными между лесами, все трудоемкие операции выполняются графическими средствами DirectAccess — при условии, что между лесом, где расположены серверы DirectAccess, и лесами, содержащими пользователей, поддерживаются двусторонние отношения доверия.

Изменения требований к серверам. Система Server 2012 полностью поддерживает вариант развертывания сервера Server Core для сервера DirectAccess. Любопытно, что сейчас Microsoft рекомендует размещать сервер DirectAccess в виртуальной машине (virtual machine, VM). Если этот сервер выполняется в виртуальной машине, по-прежнему существует возможность разгружать IPSec-трафик на сетевой адаптер (при условии, что последний позволяет осуществлять IPSec-разгрузку) и по-прежнему обеспечивается повышение производительности с помощью таких технологий, как масштабирование на стороне приема Receive Side Scaling.

Ранее специалисты Microsoft рекомендовали размещать DirectAccess на физических системах из-за высоких рабочих нагрузок, связанных с шифрованием. В среде Server 2008 R2 при использовании протокола HTTPS служба DirectAccess выполняет двойное шифрование, поскольку шифрованию подвергается сначала IPSec-трафик, а затем и HTTPS-трафик. В среде Server 2012 DirectAccess может вместо двойного шифрования выполнять шифрование IP-HTTPS NULL, тем самым снижая уровень непроизводительных затрат на стороне клиента и сервера DirectAccess. В конечном счете это означает сокращение объема потребляемых ресурсов и увеличение числа пользователей, обслуживаемых одним сервером, — как мне сказали, число пользователей возрастает до четырех раз. В среде Server 2012 протокол IP-HTTPS обеспечивает почти такую же производительность, как протокол Teredo.

Изменения требований к клиентам. При использовании клиентов Windows 7 для организации службы DirectAccess в средах Server 2012 и Server 2008 R2 не обойтись без установки отдельного помощника DirectAccess Connectivity Assistant (DCA), который представлен на системной панели задач значком, отображающим состояние подключения DirectAccess. Когда же для организации службы DirectAccess в среде Server 2012 используются клиенты Windows 8, необходимости в установке помощника DCA нет, поскольку средства взаимодействия с DirectAccess интегрированы с прочими сетевыми функциями Windows 8. Состояние подключения DirectAccess отображается наряду с иными соединениями (скажем, беспроводными) с помощью средств пользовательского интерфейса, отвечающего за управление сетью. Кроме того, данный интерфейс использует функции DirectAccess, которые обычно применяются для выяснения причин неполадок. Интерфейс DirectAccess позволяет экспортировать журналы DirectAccess в файл, который затем можно направить в службу поддержки. Кроме того, он дает пользователям возможность переопределять заранее заданный сайт DirectAccess и указывать сайт, к которому они хотели бы подключиться.

Подготовка вне сайта полезна в тех случаях, когда возникает необходимость устанавливать клиенты, не имеющие физического подключения к корпоративной сети. При использовании клиентов Windows 8 возможна полномасштабная подготовка вне сайта, включая установку на базе технологии Windows-To-Go. Такая установка невозможна, если в работе службы DirectAccess в среде Server 2012 задействованы клиенты Windows 7. Для загрузки установочного файла DirectAccess по-прежнему необходимо подключаться к корпоративному сетевому ресурсу, но это может оказаться так же просто, как подключиться к защищенному веб-узлу. Отметим, что настройка DirectAccess из-за пределов компании возможна в среде Server 2008 R2, но это решение сопряжено с большими затратами времени на «обходной маневр», в частности, на создание временного соединения VPN.

Настройка и управление DirectAccess в среде Server 2012

Не будет преувеличением сказать, что развертывание сервера DirectAccess в среде Server 2012 выполняется легко и быстро. Ниже я привожу полное описание развертывания односерверной системы DirectAccess для организации небольшого или среднего масштаба. Операция строится в предположении, что существует некоторое внешнее имя DNS и что это имя указывает на корректный IP-адрес. Процедура развертывания состоит из следующих этапов.

1. Установите роль Remote Access с применяемыми по умолчанию параметрами, для чего нужно выполнить команду:

Install-WindowsFeature RemoteAccess -IncludeManagementTools

2. Откройте консоль Remote Access Management.

3. Щелкните на пункте Getting Started Wizard. В результате будет запущен мастер экспресс-установки. Имеется также вариант запуска мастера для установки в режиме эксперта.

4. На странице Configure Remote Access выберите пункт Deploy DirectAccess.

5. На странице Remote Access Server Setup вы увидите предлагаемые варианты топологии, которые строятся на возможностях имеющегося в вашем распоряжении сервера DirectAccess. Скажем, если сервер оснащен всего лишь одним сетевым адаптером, к нему можно применить только один вариант топологии. К возможным типам топологии относятся Edge (где используются два сетевых адаптера — один для Интернета, второй для частной сети), Back (где сервер DirectAccess располагается за устройством NAT, с подключением к DMZ и к частной сети) и Single (где используется один сетевой адаптер с одним сетевым подключением). После того как вы подберете соответствующий тип топологии, нужно будет указать общедоступный IP-адрес или разрешимое извне имя DNS, которое будет использоваться клиентами для подключения к серверу DirectAccess.

6. Когда на дисплее появится изображение страницы с перечислением настроек, нажмите кнопку ОК. Служба DirectAccess настроена и готова к работе.

Наряду с настройкой сервера DirectAccess вам необходимо настроить клиенты. В процессе развертывания сервера DirectAccess программа автоматически создает объект групповой политики (GPO) DirectAccess Client Settings, содержащий настройки клиентов DirectAccess. Если вы хотите, чтобы клиент использовал службу DirectAccess, нужно присоединить его к соответствующему домену и применить упомянутый объект GPO. Задача может оказаться сложной, если клиент не подключен к корпоративной сети; в этом случае вам придется подключиться к домену в автономном режиме и применить соответствующую политику. При использовании клиента Windows 8 это можно сделать с помощью утилиты командной строки Djoin.exe.

Перед запуском данной утилиты нужно подготовить учетную запись соответствующего компьютера в AD и сохранить подготовленные данные в файле. Публикуемая ниже команда осуществляет подготовку учетной записи компьютера DAclientExample в домене savilltech.net, указывает, что необходимо применить объект групповой политики DirectAccess Client Settings, и сохраняет подготовленные сведения в файле clientda.txt:

Djoin.exe /provision
/domain savilltech.net
/machine DAclientExample
/policynames «DirectAccess Client Settings»
/savefile clientda.txt

На странице журнала приведенная выше команда разбита на несколько строк, однако в окне Cmd.exe следует вводить ее одной строкой. Сказанное относится и к следующей команде. После создания клиентом файла clientda.txt вы можете запустить публикуемую ниже команду с тем, чтобы запросить присоединение к домену в автономном режиме в следующий раз, когда будет запущен клиент:

djoin.exe /requestodj /loadfile clientda.txt
/windowspath %windir% /localos

Таким образом, при следующем запуске клиента он будет присоединен к домену savilltech.net, и к нему будет применен объект групповой политики DirectAccess Client Settings.

Надо сказать, что тем, кто использует компьютеры с Windows 7, придется совершить ряд дополнительных шагов. Однако я не стану описывать их здесь, ибо моя цель состоит в том, чтобы показать вам, насколько просто применить средства Server 2012 DirectAccess, когда вы работаете с Windows 8.

Процедуры установки серверов и клиентов DirectAccess, описанные в настоящей статье, применимы для несложных ситуаций. Вполне вероятно, что вы захотите внести в них некоторые изменения.

Так, возможно, вы захотите создать отдельную группу, содержащую учетные записи компьютеров, которые по вашему замыслу смогут взаимодействовать с DirectAccess (скажем, группу с именем DA_Clients). По умолчанию в этой роли выступает входящая в соответствующий домен группа Domain Computers; именно из этой группы средства DirectAccess будут развертываться на всех системах вашего домена.

Возможно, вы предпочтете вариант, предусматривающий применение объекта групповой политики DirectAccess Client Settings к некоторым заданным группам, а не к корню домена (последний вариант применяется по умолчанию, если перед запуском команд для установки службы DirectAccess вы зарегистрировались в качестве администратора домена). К счастью, по замыслу разработчиков объект групповой политики будет применяться к группе компьютеров, указанных в консоли Remote Access Management. Это означает, что DirectAccess будет контролироваться, если вместо группы Domain Computers вы укажете альтернативную группу компьютеров — даже если объект групповой политики «привязан» к корневому домену.

Такая индивидуализация возможна и желательна в большинстве случаев. Вы сможете с легкостью выполнить ее (а также изменить многие другие настройки) по завершении развертывания DirectAccess с помощью страницы Remote Access Setup, показанной на рисунке 1; эта страница является стартовой при настройке DirectAccess.

 

Страница Remote Access Setup
Рисунок. Страница Remote Access Setup

Страница Remote Access Setup поможет вам выполнить подстройку параметров, установленных в ходе первоначального развертывания, но кроме того, вы можете использовать эту страницу на протяжении всего жизненного цикла DirectAccess по мере изменения потребностей вашей компании. К примеру, с ее помощью вы можете добавлять серверы, изменять общедоступные имена, а также топологию. Кроме того, в вашем распоряжении имеется полный набор средств обеспечения выполнения автоматических заданий, таких, как применение объектов групповых политик и изменений настройки. Если бы вы работали с системой Server 2008 R2, вам пришлось бы встать в 2 часа ночи, чтобы успеть вручную применить GPO и изменения в настройке с помощью графического интерфейса пользователя.

Огромный шаг вперед

Как видите, в версии Server 2012 установку DirectAccess осуществить намного проще, чем в Server 2008 R2. Кроме того, заметно облегчается работа конечных пользователей, а также специалистов ИТ-подразделения, занимающихся управлением средствами DirectAccess; эти возможности намного превосходят то, чего вы могли бы добиться с помощью инициируемого вручную соединения с сетями VPN. Но помните: VPN еще понадобятся вам для управления системами, не оснащенными средствами для работы с DirectAccess. К счастью, среда Server 2012 оснащена замечательными средствами для взаимодействия с VPN.