DirectAccess предназначается для замены доказавших свою надежность виртуальных частных сетей (VPN) безопасным постоянным соединением, которое не требует (или почти не требует) никаких действий пользователя. DirectAccess действительно является одним из главных достижений принятой в Microsoft стратегии разработки “better together” (“лучше вместе”), предусматривающей одновременный выпуск новой клиентской ОС Windows 7 и новой серверной ОС Windows 2008 Server R2, что позволит предоставить в распоряжение клиентов, которые начнут использовать обе ОС одновременно, больше функций и открыть перед ними дополнительные возможности.
В рамках проводимой Microsoft кампании за экономию средств под лозунгом New Efficiency (она была объявлена в сентябре на проходившем в Сан-Франциско мероприятии) DirectAccess рассматривается как одно из главных достижений стратегии “better together”. Если виртуализация с помощью входящего в состав Windows 2008 Server R2 гипервизора Hyper-V призвана обеспечить сокращение затрат и эффективность операций в ЦОДах, то DirectAccess должен гарантировать эффективную работу ПК посредством постоянного подключения, упрощая удаленным пользователям доступ к данным и приложениям, а ИТ-подразделениям — текущее обслуживание и устранение неисправностей.
Microsoft называет DirectAccess в Windows 7 крупным достижением и новым поколением технологии сетевого доступа для удаленных пользователей в нынешних условиях, когда исчезает представление о периметре сети.
В ходе тестирования в лаборатории eWeek Labs использовались новейшее оборудование и ПО — Windows 2008 Enterprise Server R2 в качестве серверной ОС и Windows 7 Enterprise/Ultimate в качестве клиентской. DirectAccess работал так, как можно только мечтать, обеспечивая постоянную двустороннюю связь. Но осталось открытым множество вопросов, связанных с масштабируемостью, производительностью и управляемостью. Ответы на большинство из них зависят от качества еще одной технологии Microsoft, которая имеется пока только в виде бета-версии, — шлюза Forefront Unified Access Gateway (UAG). Хотя в DirectAccess используется много промышленных стандартов, эта технология должна быть тщательно изучена специалистами по безопасности, чтобы пользователи могли быть уверены в том, что она гарантирует конфиденциальность.
Тем не менее для многих DirectAccess может остаться несбыточной мечтой, по крайней мере в кратко- и среднесрочной перспективе. Речь, во-первых, о тех, у кого сетевая инфраструктура основана на серверах с Windows Server 2003. Во-вторых, о тех, кто из-за ограниченности ИТ-бюджета вынужден осуществлять перевод ПК на Windows 7 медленно и поэтапно и, соответственно, использовать прежние технологии удаленного доступа. В-третьих, о тех, кто не знаком с особенностями протокола IPv6. Наконец, о тех, кто ради сохранения масштабируемости или обратной совместимости своих систем не может либо не хочет заменять свои средства безопасности решениями Microsoft.
Действительно, сфера применения DirectAccess довольно ограниченна. ПК должны работать под управлением Windows 7 Enterprise или Ultimate, а серверы приложений — под Windows Server 2008 R2 либо Windows Server 2008 SP2 (до тех пор, пока в состав сети не включены элементы упоминавшегося шлюза).
Для обеспечения постоянного подключения DirectAccess использует протоколы IPSec и IPv6. При входе в сеть клиентская система с Windows 7 производит быструю проверку с целью определить, к какой сети она подключена — к защищенной или нет.
Если клиент обнаруживает удаленное подключение, то в следующий раз при появлении запроса об имени DNS он обратится к своей таблице имен (Name Resolution Policy Table, NRPT). Такая таблица впервые появляется в Windows 7. Она помогает подключить пространство имен защищенной сети к внутреннему DNS-серверу. Обращаясь к ней, клиент определяет, есть ли необходимость направить запрос на присвоение имени внутреннему серверу DNS. Если соответствующее имя в таблице не найдено, запрос посылается DNS-серверам, настроенным на работу в качестве сетевых адаптеров. При этом весь интернет-трафик идет в обход инфраструктуры DirectAccess.
Запросы, касающиеся незащищенной сети, по протоколу IPv6 направляются через Интернет серверу DirectAccess, который образует мост между Всемирной паутиной и защищенной сетью интранет. Поскольку многие из составляющих Интернет сетей пока не поддерживают IPv6, DirectAccess будет автоматически использовать технологии преобразования трафика, такие как 6to4 или Teredo, чтобы пропустить его по сетям, использующим протокол IPv4 и трансляцию адресов (NAT). Если клиенты отгорожены от Интернета прокси-сервером или брандмауэром, которые настроены на жесткую фильтрацию исходящего трафика, DirectAccess может создать туннель IP-HTTPS, упаковав уже зашифрованный трафик по протоколу IPSec в еще раз зашифрованный с помощью HTTPS трафик.
В случае, если у людей вроде меня защищенная сеть не вполне готова к применению IPv6, DirectAccess может использовать ISATAP для передачи трафика по внутренним сетям IPv4.
DirectAccess автоматически прибегает к шифрованию по протоколу IPSec при передаче трафика между ПК и установленным на границе сети сервером DirectAccess. При определенных условиях администраторы имеют возможность распространить шифрование на весь трафик между ПК и сервером приложений.
По умолчанию аутентификация производится на основе сведений о компьютерах, поскольку для идентификации тех ПК, что наделены правом использовать DirectAccess, администраторам необходимо создавать группы, безопасность которых гарантирована. Как и шифрование, аутентификация может ограничиваться внешним периметром или распространяться дальше вплоть до сервера приложений. Для выборочной аутентификации DirectAccess позволяет использовать смарт-карты. Правда, в такой конфигурации я его не тестировал.
Многим администраторам, все еще применяющим Windows Server 2003, для поддержки DirectAccess потребуется произвести значительную модернизацию оборудования вплоть до ключевых элементов сетевой инфраструктуры.
К использованию DirectAccess можно приступать, имея в сети одну систему под управлением Windows Server 2008 R2, которая будет служить сервером DirectAccess, пересылающим трафик между Интернетом и интранетом. Однако контроллер домена и сервер DNS должны работать под управлением Windows Server 2008 SP2 или Windows Server 2008 R2, поскольку для узлов IPv6 сервис DNS должен поддерживать записи AAAA.
Администраторам необходимо также иметь в домене сервер управления сертификатами, потому что на клиентских ПК с Windows 7, включенных в группу с гарантированной безопасностью и получивших право доступа к DirectAccess, должны быть установлены необходимые сертификаты. Кроме того, администраторам следует создать в защищенной сети легкодоступный сервер для локализации сетей (network location server), иначе говоря, использующий шифрование веб-сервер. Клиенты обращаются к нему, чтобы определить, к какой сети они подключаются — по эту или по ту сторону брандмауэра.
Порядок работы хостовых приложений с DirectAccess зависит помимо прочего от того, под управлением какой операционной системы они работают. Серверы приложений на компьютерах с Windows Server 2008 R2 или Windows Server 2008 поддерживают IPv6 с двухуровневой IP-архитектурой. К ним легко получить доступ посредством DirectAccess. А вот к серверам с архитектурой двойного стека, таким как Windows Server 2003, или к тем, что вообще не поддерживают IPv6, удаленные клиенты DirectAccess не могут получать прямой доступ.
Для поддержки унаследованных серверов приложений администраторам потребуется установить на границе сети еще одно устройство, поддерживающее NAT-PT, чтобы создать мост между клиентами DirectAccess, поддерживающими IPv6, и серверами приложений, поддерживающими IPv4. Следующая версия шлюза Microsoft, которая сейчас называется Forefront UAG 2010, будет выполнять функции NAT-PT. В настоящее время имеется только бета-версия Forefront UAG 2010, и Microsoft пока не объявляла, когда будет выпущен этот продукт.
Сотрудники Microsoft сообщили мне, что некоторые партнеры корпорации планируют разработать собственные решения NAT-PT. Хотя среди таких партнеров была названа компания F5, там отказались от комментариев.
Сетевым администраторам потребуется Forefront UAG 2010, если они не намерены ограничиваться одним сервером DirectAccess на границе сети. В настоящее время каждый сервер DirectAccess должен представлять собой отдельное устройство, которое настраивается и управляется независимо от других. Forefront UAG позволяет управлять несколькими серверами и перераспределять нагрузку между ними.
К сожалению, Microsoft пока предоставляет не много информации относительно выбора адекватного задачам оборудования для DirectAccess. По словам сотрудников корпорации, она все еще собирает данные у пользователей бета-версии, чтобы лучше понять, сколько потребуется серверов DirectAccess при определенной нагрузке. Однако они сообщили, что количество серверов будет варьироваться в широких пределах в зависимости от характера использования сети. Численность одновременно подключенных удаленных клиентов, объем передаваемых в обоих направлениях данных, используемый клиентами в каждом конкретном случае метод обхода сети (traversal method) — все эти факторы будут отражаться на производительности. Как сказали представители Microsoft, у сервера DirectAccess узким местом будет, скорее, не объем ОЗУ, а мощность процессора.
Что касается клиентов, то DirectAccess может устанавливаться только на компьютерах, работающих под управлением Windows 7 Enterprise или Ultimate. Далее, эти ПК должны быть включены в домен, поскольку сервис выдачи сертификатов и групповая политика играют важную роль в установлении удаленного соединения.
DirectAccess не будет работать ни с Windows 7 Professional (несмотря на то, что SKU имеет функции Domain Join), ни с другими версиями этой ОС для потребительского рынка.
Также не будет работать DirectAccess с компьютерами под управлением Windows Vista или Windows XP и с другими версиями Windows, вышедшими до XP. Администраторам придется поддерживать имеющиеся у них решения для обеспечения удаленного доступа к таких ПК или заменить свои технологии идентичными сервисами, которые предоставляет Forefront UAG 2010. Сотрудники Microsoft не исключают, что в устаревших клиентских ОС будет обеспечена поддержка DirectAccess. Но я предполагаю, что это коснется только версии Vista.
Администраторам также не приходится рассчитывать на то, что виртуальные клиенты на компьютерах с Windows 7 (созданные в режиме XP Mode или с помощью другого гипервизора) смогут использовать DirectAccess даже при трансляции сетевых адресов между хостом и виртуальной машиной. Это не имеет большого значения, если речь идет о совместном использовании файлов или дискового пространства, поскольку Windows 7 в качестве хостовой ОС может копировать на тот же компьютер файлы, которые будут использоваться в режиме XP Mode. Но тем, кто применяет XP Mode для доступа к унаследованным веб-приложениям, требующим, чтобы в защищенной сети использовался браузер IE 6, DirectAccess не обеспечит необходимого сетевого доступа. Для этого может потребоваться самостоятельное решение на базе VPN для самой виртуальной ОС.
Как заставить всё это работать
Я тестировал DirectAccess в виртуальной сети, организованной с помощью VSphere 4 компании VMware. Были созданы четыре виртуальных сервера на основе Windows Server 2008 R2 Enterprise и один 32-разрядный клиент на базе Windows 7 Ultimate. Аппаратурой служил сервер HP DL380 G6 с процессором Intel Nehalem и 12 Гб ОЗУ. Под каждую виртуальную машину выделялось 2 Гб оперативной памяти. Кроме того, к тестовой конфигурации я добавил второй клиент, работающий под управлением 32-разрядной Windows 7 Enterprise на ноутбуке Dell XPS M1330. Этот ноутбук был сконфигурирован для доступа к тестовому домену через Интернет и брандмауэр с функцией NAT.
Первый виртуальный сервер обеспечивал основные сервисы, выступая в роли контроллера домена, DHCP- и DNS-серверов и сервера сертификатов. Второй, на котором был установлен веб-сервер IIS 7.0, служил сервером приложений и локализации сетей. Третий предназначался для DirectAccess и выполнял функции моста между Интернетом и моей защищенной сетью. Четвертый я сконфигурировал в качестве DNS-сервера интернет-имен. Он не относится к числу обязательных элементов, но упрощает тестирование с использованием Интернета.
Политика DirectAccess задается непосредственно на сервере DirectAccess с помощью утилиты DAMgmt. В комплекте нет какого-либо административного пакета или набора инструментов, которые можно было бы установить на ПК, чтобы управлять с него DirectAccess. Так что администраторам необходимо будет регистрироваться на сервере напрямую или через удаленный доступ посредством Remote Desktop, чтобы обновить политику настроек DirectAccess или воспользоваться управляющей консолью.
Помощник DAMgmt прежде всего запускает диагностику, чтобы определить пригодность сервера для DirectAccess и убедиться в наличии хотя бы двух сетевых интерфейсов (соответственно для интранета и Интернета). Если система выдержит эту проверку, администраторы могут завершить процесс установки в четыре этапа. Необходимо создать группы защищенных компьютеров, которые будут использовать DirectAccess; определить сетевые интерфейсы и сертификаты на сервере DirectAccess; идентифицировать сервер локализации сетей и суффиксы DNS, обнаруженные в защищенной сети; решить, должны ли шифрование и сертификация поддерживаться только до внешней границы сети (т. е. до сервера DirectAccess) или до сервера приложений. После этого я получил возможность сохранить свои настройки DirectAccess и применить их.
В процессе конфигурирования DirectAccess я столкнулся с небольшой проблемой. По ошибке я задал на сервере DirectAccess один и тот же суффикс DNS для обоих сетевых адаптеров. Такая ошибка создает трудности с подключениями ISATAP. Вы лишаетесь возможности завершить проводимые в фоновом режиме проверки, которые производятся на сервере DirectAccess, когда он приводится в соответствие заданной политике. Из-за этой ошибки я не смог использовать свою политику. К сожалению, помощник предупредил меня только о возникновении “необъяснимой ошибки”. Так что мне пришлось искать, в чем она заключается, просматривая лог-файл, находящийся на сервере DirectAccess в папке C:\Windows\Tracing.
Применение политики DirectAccess автоматически создает в каталоге Active Directory объекты групповой политики с необходимыми настройками компьютеров. Затем эти настройки используются в политике домена по умолчанию. При этом фильтр безопасности применяется к защищенным группам, созданным на первом этапе работы с программой-помощником. Как только эти клиенты обновят свою групповую политику (это делается через определенные промежутки времени или вручную командой GPUpdate), DirectAccess будет готов к работе.
Запустив DirectAccess, я обнаружил, что оба моих клиента (один был подключен к Интернету напрямую по протоколу IPv4, а другой защищен брандмауэром с функцией NAT) могут получить удаленный доступ к веб-сайтам и коллективно используемым файлам, размещенным в защищенной сети. Причем для установления соединения от пользователя не требовалось никаких действий. Я смог также благополучно передать удаленным клиентам свои настройки групповой политики (мапированный диск) и политику, которая удаляла с предназначенного для регистрации экрана последнего зарегистрировавшегося пользователя.
При настройке клиентов мне потребовалось создать с помощью групповой политики исключения из политик брандмауэра, чтобы разрешить входящий и исходящий трафик по протоколам ICMPv4 и ICMPv6 Echo. Организациям, использующим брандмауэры сторонних производителей для защиты конечных точек, при тестировании DirectAccess также следует разрешить этот трафик.
С помощью того же инструмента DAMgmt администраторы могут вести мониторинг работы DirectAccess. При этом они будут в реальном времени видеть состояние и действия всех значимых компонентов DirectAccess — Teredo, 6to4, IPHTTPS, ISATAP, DNS и IPSec — со ссылками на соответствующий датчик производительности (Performance Monitor) для каждого из них.
