В первой части, посвященной 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-пакет, из заголовка которого видно, что пакет действительно предназначен данному хосту и может быть подвергнут дальнейшей обработке.

NAT-PT

Последний вариант, который нужно отметить, вариант, когда сервер назначения в принципе не умеет работать с 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 over IPv6

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.

DirectAccess в Windows 7. Часть 2