DirectAccess в Windows 7. Часть1
В своем предыдущем посте я упоминал о двух, с моей точки зрения, наиболее интересных нововведений Windows 7 – BranchCache и DirectAccess. Технология BranchCache была рассмотрена в прошлый раз. Настала очередь DirectAccess. Однако по ходу дела стало понятно, что материал выходит за рамки одного поста. Поэтому для начала я сосредоточусь на рассмотрении особенностей DirectAccess и некоторых вопросах использования IPv6.
Что такое DirectAccess
DirectAccess – технология удаленного доступа к ресурсам корпоративной сети. С потребительской точки зрения суть технологии можно выразить следующим образом: «Как только мой компьютер подключился к Интернету, так сразу я получил доступ и к ресурсам Интернета, и ко всей корпоративной сети». Выражаясь техническим языком, при подключении к Интернету пользовательский компьютер, сконфигурированный в качестве клиента DirectAccess (DA-клиента), автоматически устанавливает туннель до сервера DirectAccess (DA-сервера) и через него получает доступ ко всей корпоративной сети. Отличается ли это чем-то принципиально от традиционных VPN-решений? Давайте рассмотрим особенности DirectAccess и технологическую основу данного решения, после чего, думаю, каждый сам для себя сможет ответить на этот вопрос.
Первая очень важная особенность – от пользователя не требуются никакие дополнительные действия. Туннель между клиентом и сервером DirectAccess устанавливается автоматически, причем, как будет показано в дальнейшем, фактически создаются два туннеля: один для аутентификации компьютера, второй для аутентификации пользователя. И этот процесс для пользователя абсолютно прозрачен. Не нужно запускать какие-либо VPN-соединения, не нужно вводить учетные данные – логин и пароль, пин-код для смарт-карты и пр. Более того, если связь с Интернетом на какое-то время теряется, и при этом естественно разрывается туннель, а затем восстанавливается (например, нестабильный сигнал WiFi), то опять же автоматически без участия пользователя восстанавливается и туннель в корпоративную сеть.
Вторая особенность следует из первой, хотя, возможно, это и не очень очевидно. Все время, пока есть связь с Интернетом, и существует туннель, клиентский компьютер доступен для управления со стороны ИТ-служб компании. Иными словами, благодаря DirectAccess не только пользователь может постоянно работать с корпоративными ресурсами, была бы связь с внешним миром, но и другие сотрудники, в первую очередь айтишники, имеют доступ к компьютеру пользователя. Пользователь все время находится «под колпаком» у ИТ-служб, что, наверное, не очень устраивает его самого, но очень устраивает ИТ-персонал. 🙂 С практической точки зрения этот факт дает возможность осуществлять мониторинг клиентской машины – проверку антивирусных баз, последних обновлений, включенного firewall и пр. – даже если она находится за пределами корпоративной сети. С другой стороны, вручную разорвать DA-туннель не так просто, как в случае VPN-соединения, которое, как правило, визуально отображается в сетевых подключениях. То есть конечно можно, но нужно знать как.
Ну и наконец, по умолчанию DirectAccess обеспечивает разные маршруты к локальным, внешним и корпоративным ресурсам (см. рис. 1). Во многих реализациях при установке VPN-соединения меняется адрес шлюза по умолчанию, и весь трафик гонится на VPN-сервер, а уже оттуда в Интернет или корпоративную сеть. Это с одной стороны замедляет скорость работы с Интернет-ресурсами, с другой может создавать определенные проблемы с маршрутизацией в локальной сети. DirectAccess достаточно гибок в настройке, поэтому можно как настроить режим split tunnel (по умолчанию), так и заворачивать весь трафик на DA-сервер. 
Рис. 1
Давайте рассмотрим теперь технологические решения, лежащие в основе DirectAccess. Фактически их три:
1. Протокол IPv6 для связи DA-клиента с DA-сервером и компьютерами Интрасети.
2. Протокол IPSec поверх IPv6 для защищенной передачи данных по Интернет- / Интранет-сети.
3. Таблица политики разрешения имен (Name Resolution Policy Table, NRPT) для корректного разрешения внутренних (корпоративных) и внешних имен.
Последняя, к слову сказать, позволяет пользователю, находясь в Интернете, обращаться к внутренним ресурсам по коротким именам, например: \\corp-srv1\docs. Обсудим последовательно все три перечисленные компоненты.
DirectAccess требует наличия настроенного протокола IP версии 6, как минимум на DA-клиентах и DA-серверах. Не спешите сразу заканчивать чтение, это вовсе не означает, что DirectAccess неприменим в нынешних условиях практически безраздельного царствования IPv4 на просторах нашего, да и не только нашего Интернета.
Почему вообще была сделана ставка на IPv6? Этот протокол обладает массой преимуществ, главное из которых – отсутствие недостатков старого доброго IPv4. 🙂 Если серьезно, то применительно к нашей теме я бы отметил следующие особенности IPv6.
Первое – это огромное адресное пространство. Что это реально дает? Сейчас все или почти все компании используют один или несколько публичных IPv4-адресов в демилитаризованной зоне, в то время как компьютеры внутренней сети настроены на какой-либо из диапазонов частных адресов (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Вполне вероятно, что при подключении к Интернету через NAT удаленный компьютер получит адрес из такого же диапазона, что сделает применение режима split tunnel весьма затруднительным. Подобная же проблема может возникнуть при связывании через VPN двух удаленных офисов, использующих одинаковую частную IP-подсеть. Адресное пространство IPv6 позволяет присвоить любому хосту компании уникальный IPv6-адрес, причем уникальный не только в пределах корпоративной сети, но и всего Интернета. Как следствие необходимость в трансляции адресов отпадает, и можно вообще отказаться от использования NAT – речь будет идти только о маршрутизации пакетов.
Насколько безопасна работа без NAT? Понимаю, что вопрос более чем дискуссионный. И все же. Давайте вспомним, что в первую очередь NAT призван решить проблему нехватки публичных IPv4-адресов. Этой проблемы нет в IPv6. Второе следствие применения NAT – скрытие внутренней IP-адресации. Хосты в Интернете «видят» только IP-адреса на внешнем интерфейсе NAT-устройства. В случае отказа от NAT компания «засветит» реальные IPv6-адреса корпоративной сети. Является ли это угрозой безопасности? В общем случае да. Чем меньше злоумышленник знает о моей сети, тем меньше потенциальных бед может натворить. Однако с другой стороны, мы ведь говорим об удаленном доступе клиентов к корпоративным ресурсам. Firewall-ы никто не отменял, они по-прежнему пропускают только определенный трафик и наверняка снабжены системами обнаружения вторжений, предотвращения сканирования портов и пр. Кроме того, едва ли кто-нибудь будет организовывать туннель для удаленного доступа без шифрования. И вот тут надо вспомнить про IPSec over IPv6. DA-сервер принимает только IPSec-трафик. По умолчанию. Перенастроить всегда можно. А при установке IPSec-соединения происходит взаимная аутентификация сервера и клиента, сначала на уровне учетных записей компьютеров посредством цифровых сертификатов, затем на уровне учетной записи пользователя посредством заданного корпоративной политикой механизма (пароль, смарт-карта, отпечатки пальцев и пр.). Соответственно, знание конкретного IP-адреса внутреннего сервера едва ли сильно облегчит задачу проникновения во внутреннюю сеть.
И напротив, отказ от NAT приводит к еще одной полезной особенности использования IPv6 – возможности защищенных соединений точка-точка. Действительно, стандартным решением в случае NAT является схема (см. рис. 2), при которой шифрованный туннель устанавливается от, в данном случае, DA-клиента до DA-сервера. По внутренней сети трафик передается уже в открытом виде (красные стрелки), либо снова шифруется, но уже не клиентом, а DA-сервером. 
Рис.2
В случае глобальной маршрутизации IPv6 шифрованный канал может быть установлен между DA-клиентом и конечным сервером, а сервер DirectAccess лишь пропускает (маршрутизирует) такой трафик через себя (см. рис. 3). Это позволяет настраивать права доступа к серверам и на уровне компьютеров, и на уровне пользователей, дополнительно «закручивая гайки» безопасности. Сложность же в реализации подобной схемы при использовании трансляции адресов заключается в том, что каждый пакет IPSec имеет цифровую подпись, которая нарушается, когда NAT-устройство пытается модифицировать пакет. И хотя решение данной проблемы существует, не каждое NAT-устройство его поддерживает. 
Рис. 3
Ну и еще один немаловажный момент, связанный с NAT. Приложения. Можно легко столкнуться с программами, которые не работают или криво работают через NAT. В том числе, в силу некорректного разрешения внутренних и внешних имен. Отсутствие NAT позволяет разработчикам забыть о вопросах трансляции адресов и сосредоточиться на бизнес-логике приложения, а администраторам избавиться от дополнительных настроек и приложений, и firewall-ов.
Таким образом, на чаше весов оказываются «открытость» IP-адресации вашей сети и те преимущества «мира без NAT», которые я попытался обозначить. Выбор, как всегда, за вами.
В следующем посте я закончу рассмотрение технологического фундамента DirectAccess. Речь пойдет об использовании IPv6 в среде IPv4, вариантах применения IPSec over IPv6, особенностях реализации NRPT.
DirectAccess в Windows 7. Часть 2
В первой части, посвященной DirectAccess, я начал рассмотрение технологического фундамента данного решения. Напомню, этот фундамент составляют: IPv6, IPsec поверх IPv6, таблица политики разрешения имен (Name Resolution Policy Table, NRPT). Мы обсудили причины, по которым в качестве базового протокола DirectAccess использует именно IPv6. Означает ли это, что сейчас, в эпоху явного доминирования IPv4, в том числе, в российском Интернете, использование DirectAccess невозможно? Нет. Благодаря транзитным технологиям DirectAccess прекрасно чувствует себя в среде IPv4.
Транзитные технологии IPv6
При использовании DirectAccess информация по IPv6 передается от DA-клиента в Интернете через DA-сервер в зоне периметра к какому-либо серверу (или клиенту) в корпоративной сети. То есть предполагается, все три участника такого информационного канала поддерживают IPv6. Для DA-клиента и DA-сервера поддержка IPv6 является строго обязательной. Стало быть, транзитные технологии могут помочь в трех ситуациях:
— когда сегменты Интернет между DA-клиентом и DA-сервером не поддерживают IPv6;
— когда сегменты корпоративной сети между DA-сервером и сервером назначения, которому предназначен трафик, не поддерживают IPv6;
— когда сам сервер назначения не поддерживает IPv6.
Рассмотрим все три случая в перечисленном порядке.
Транзит между DA-клиентом и DA-сервером
Как только DA-клиент оказался в Интернете, он пытается установить IPsec over IPv6 туннель с DA-сервером. Каким образом выстраивается подобный туннель, напрямую зависит от того, какую конфигурацию IP клиент получает от Интернет-провайдера. В идеальном и, соответственно, наименее вероятном пока случае DA-клиент получает IPv6-адрес. То есть DA-клиенту посчастливилось оказаться в IPv6 Интернете, его пакеты просто маршрутизируются DA-серверу.
Более реальный вариант – DA-клиент получает от провайдера публичный IPv4-адрес. В этом случае на клиенте задействуется транзитная технология 6to4 (RFC 3056). Благодаря этой технологии на клиенте формируется IPv6-адрес вида 2002:WWXX:YYZZ::/48, начинающийся с 2002 (префикс 2002 как раз указывает на то, что имеет место транзитная технология 6to4) и содержащий в полях WWXX:YYZZ публичный IPv4-адрес (см. рис. 1): 
Рис. 1
Теперь сформированный таким образом IPv6-пакет упаковывается в IPv4-пакет и маршрутизируется через IPv4 Интернет.
Еще более реальный вариант – DA-клиент получает от провайдера частный IPv4-адрес, например, 192.168.200.111. В этом случае задействуется другая транзитная технология – Teredo (RFC 4380). Задача Teredo – обеспечить прохождение исходного IPv6-пакета не только через IPv4-среду, но и через NAT. В этой связи принцип работы Teredo несколько сложнее, чем 6to4, а структура формируемого IPv6-адреса имеет вид: 
Рис. 2
Все адреса Teredo начинаются с префикса 2001, а поля Obscured External Port и Obscured External Address содержат соответственно внешний UDP-порт и внешний IP-адрес, используемые NAT. Уточню лишь, что содержат не в явном виде, а как результат операции XOR с предопределенным числом. Сформированный пакет упаковывается в UDP-пакет, который, в свою очередь, упаковывается в IPv4-пакет. Теперь все готово для пересылки информации через NAT. Более подробно с транзитными технологиями 6to4 и Teredo, а также упомянутой в дальнейшем технологией ISATAP, можно познакомиться, например, здесь.
Есть еще один вполне возможный вариант, когда DA-клиент получает от провайдера некий IPv4-адрес, но при этом коммуникации с внешним миром разрешены только по 80 и 443 TCP-портам. В таком случае поможет протокол, который уже не является стандартом RFC и поддерживается только в Windows 7 и Windows Server 2008 R2. Протокол называется IP-HTTPS и, как следует из названия, обеспечивает передачу IPv6-пакетов с помощью HTTPS поверх IPv4. Подчеркну, данный протокол будет задействован только, если использование перечисленных выше транзитных технологий не увенчалось успехом.
Ну и наконец, если разрешен только 80-й порт, то, сюрприз-сюрприз, DirectAccess работать не будет, и доступ к корпоративным ресурсам снаружи будет невозможен. Кто бы мог подумать. 🙂
Транзит между DA-сервером и сервером назначения
Хорошо, IPv6-пакеты достигли DA-сервера. В соответствии со своими настройками DA-сервер перенаправляет IPv6-пакеты далее в корпоративную сеть серверу назначения, делая это с применением шифрования, либо без оного. И вот тут возникает вопрос, поддерживает ли сетевая среда вашей организации IPv6? Более конкретно, активное коммуникационное оборудование, в первую очередь маршрутизаторы, умеют ли работать с IPv6?
Рассмотрим ситуацию, когда сервер назначения поддерживает IPv6, а коммуникационное оборудование нет. Тогда на помощь приходит еще одна транзитная технология – ISATAP (Intra-Site Automatic Tunnel Addressing Protocol, RFC 4214). При использовании ISATAP подразумевается, что у хоста есть как минимум один IPv4-адрес, присвоенный любым принятым в организации способом. Иначе как хост вообще взаимодействует с другими машинами сети. Тогда IPv6-адрес хоста формируется автоматически, причем последние 32-бита его IPv6-адреса соответствуют его IPv4-адресу. Например, если два хоста из разных сегментов начинают взаимодействовать, их адреса могут выглядеть следующим образом (см. табл. 1):
IPv6 Source Address FE80::5EFE:10.40.1.29
IPv6 Destination Address FE80::5EFE:192.168.41.30
IPv4 Source Address 10.40.1.29
IPv4 Destination Address 192.168.41.30
Таблица 1
Поэтому когда DA-серверу необходимо отправить IPv6-пакет через IPv4-роутер, DA-сервер с помощью DNS узнает IPv4-адрес получателя, на основе этой информации формирует IPv6-пакет ISATAP-типа, упаковывает его в обычный IPv4-пакет и пересылает получателю. Последний в обратном порядке распаковывает информацию и получает исходный IPv6-пакет, из заголовка которого видно, что пакет действительно предназначен данному хосту и может быть подвергнут дальнейшей обработке.
Последний вариант, который нужно отметить, вариант, когда сервер назначения в принципе не умеет работать с IPv6. Кстати замечу, что если говорить о Windows, то поддержка IPv6 в операционных системах семейства реализована, начиная с Windows XP., Ну, а например, Windows 2000? А очень хочется и к таким машинам получать доступ извне с помощью DirectAccess. В этом случае необходимо устройство, поддерживающее спецификацию NAT-PT (RFC 2766). NAT-PT отвечает за трансляцию адресов IPv6 в адреса IPv4, тем самым позволяя в нашем случае DA-клиентам получать доступ к хостам, работающим только по IPv4. NAT-PT не поддерживается ни в Windows 7, ни в Windows Server 2008 R2. Однако поддержка этого механизма реализована в продукте Forefront Unified Access Gateway (UAG). Будучи установленным на Windows Server 2008 R2 и сконфигурированным в качестве DA-сервера, UAG предлагает некоторые расширенные возможности DirectAccess, включая NAT-PT. Рассмотрение UAG выходит за рамки данного обсуждения. Ну и кроме того, реализацию NAT-PT можно, найти в других продуктах, в том числе не Microsoft.
Подводя итоги транзитной темы, важно отметить, что от администратора и уж тем более от пользователя, специальной отдельной настройки всех этих технологий не требуется. Все что нужно для обеспечения транзита настраивается мастером при настройке DA-сервера. На DA-клиентах поддержка 6to4, Teredo, IP-HTTPS, ISATAP включается автоматически и применяется тогда, когда это необходимо.
IPsec является основой для защиты трафика между участниками DirectAccess-решения. Для протокола IP четвертой версии спецификация IPsec появилась значительно позже, нежели сам протокол IP. Это, в частности, привело к появлению различных реализаций IPsec over IPv4, порой не полностью совместимых друг с другом. IPsec для IPv6 проектировался одновременно с новым протоколом IP. Поддержка заголовков IPsec является обязательным требованием к реализации стека IPv6. Тем самым созданы предпосылки для максимальной совместимости решений от разных поставщиков. С другой стороны, это не означает, что при использовании IPv6 вы обязательно должны задействовать IPsec. Но в случае с DirectAccess, основанном на IPv6, применение IPsec является самым логичным способом защитить передаваемый трафик.
Как и для четвертой версии IPsec для IPv6 поддерживает два варианта защиты: Authentication header (AH) и Encapsulating Security Payload (ESP). В первом варианте каждый пакет, по сути, подписывается цифровой подписью, что обеспечивает аутентификацию данных, гарантию их целостности при пересылке. Однако данные пакета при этом передаются в открытом виде без шифрования. Во втором варианте плюс ко всему данные пакета еще и шифруются, что обеспечивает конфиденциальность передаваемой информации. Сочетания этих вариантов и определяют так называемую модель доступа при развертывании DirectAccess.
Первую модель называют Full Intranet Access (End-to-Edge). В этой модели зашифрованный трафик передается по IPsec от DA-клиента к DA-серверу. DA-сервер расшифровывает трафик и во внутреннюю сеть передает пакеты уже в открытом виде. На практике это означает, что достучавшись до DA-сервера, DA-клиент далее потенциально получает доступ ко всей внутренней сети. Чаще всего такая логика применяется в VPN-решениях.
В модели Selected Server Access (Modified End-to-Edge) трафик по-прежнему шифруется только до DA-сервера. А во внутренней сети используется только аутентификация (AH). Такой подход позволяет обеспечить доступ только определенных DA-клиентов к определенным серверам и приложениям в корпоративной сети (см. рис 3). 
Рис. 3
Надо иметь в виду, что в ОС до Vista IPsec over IPv6 не реализован полностью, поэтому на рисунке серверы, до которых может достучаться DA-клиент в рамках такой модели, помечены как Windows Server 2008 or later.
Наконец, в модели End-to-End (рис. 4) пакеты шифруются на DA-клиенте и расшифровываются уже на сервере назначения. DA-сервер просто прокидывает этот трафик через себя. 
Рис. 4
Подобный подход обеспечивает наибольший уровень защиты.
В конечном итоге, конкретные настройки IPsec задаются в групповых политиках, которые всегда можно изменить. Таким образом, манипулируя настройками IPsec, вы можете применять гибридные модели, наиболее подходящие в вашей конкретной ситуации. В этом дополнительная гибкость решения на основе DirectAccess.
Name Resolution Policy Table
Последним технологическим фундаментом DirectAccess является таблица Name Resolution Policy Table (NRPT), а точнее способ разрешения имен с применением этой таблицы и системы DNS. Когда DA-клиент находится в Интернете, он должен понимать, какие имена являются внутренними, и, соответственно, должны разрешаться корпоративным DNS-сервером, а какие – внешними, разрешением которых должны заниматься DNS-серверы в Интернете.
Так вот таблица NRPT позволяет задавать DNS-сервер не для сетевого интерфейса, а для некоторого пространства имен. Каждый раз, находясь за пределами корпоративной сети, при разрешении имени, например srv1.contoso.com, DA-клиент сначала проверяет, есть ли для данного имени либо его части строчка в NRPT. Если есть, за разрешением этого имени клиент обращается к DNS-серверу, указанному в соответствующей строке NRPT для данного пространства имен (см. рис. 5). Если нет, то обращение происходит в DNS-серверу, указанному в настройках сетевого интерфейса, то есть к DNS провайдера. 
Рис. 5
Кроме того, существуют так называемые exemption-политики. Имена, указанные в этих политиках всегда разрешаются только внешними интернетовскими серверами DNS.
Однако важно еще раз подчеркнуть, что такой «нестандартный» вариант разрешения имен с использованием NRPT применяется только, когда DA-клиент «понимает», что он в Интернете, снаружи. Если он во внутренней сетке, зачем городить такой огород. Стало быть, существует алгоритм определения местоположения DA-клиента. Об этом алгоритме, а также о требованиях к инфраструктуре и о настройках самого DA-сервера речь пойдет в третьем заключительном посте, посвященном DirectAccess.