Полное руководство по UAG DirectAccess (часть 3) — NAT64/DNS64

• Полное руководство по UAG DirectAccess (часть 5) — требования к инфраструктуре (продолжение)

Введение

В части 1 этой серии статей, составляющих Полное руководство по UAG DirectAccess, мы рассказали об определении DirectAccess и предоставили подробное объяснение того, как работает DirectAccess. Во второй части мы подробно рассмотрели технологии перехода на IPv6, которые позволяют клиенту и серверу DirectAccess взаимодействовать друг с другом через интрасети IPv4 и Интернет IPv4. В этой статье мы также говорили о том, как клиент DirectAccess использует таблицу политик разрешения имен (NRPT), чтобы определить, какие имена должны разрешаться внутренними DNS-серверами, а какие — DNS-серверами Интернета.

Это подводит нас к текущей статье, которая является частью 3 серии. В этой статье мы поговорим о ключевой части технологии, которая позволяет вам развернуть DirectAccess уже сегодня и не беспокоиться об обновлении вашей сетевой инфраструктуры до IPv6 для поддержки связи IPv6, используемой клиентом DirectAccess. Это важно, потому что большинство сетей, с которыми вы сталкиваетесь сегодня, вероятно, представляют собой сочетание клиентов и серверов, поддерживающих только IPv4, и IPv6. Вероятно, в вашей сети больше ресурсов IPv4, чем ресурсов, поддерживающих IPv6. Учитывая, что это текущая сетевая среда для большинства компаний, UAG DirectAccess нуждается в способе разрешить доступ к ресурсам IPv4 в вашей сети, потому что без такой поддержки сегодня очень немногие производственные сети выиграют от развертывания DirectAccess.

Решение: NAT64/DNS64

UAG DirectAccess решает эту проблему, реализуя несколько технологий, недоступных в решении Windows DirectAccess. Это:

• NAT64 (произносится NAT от шести до четырех)

• DNS64 (произносится как DNS от шести до четырех)

Эти две технологии позволяют клиентам DirectAccess, которые всегда «говорят» IPv6 с сервером UAG DirectAccess, для подключения только к ресурсам IPv4 в интрасети.

Когда клиент DirectAccess отправляет запрос на ресурсы, используя имя с одной меткой или полное доменное имя (FQDN), он сначала обращается к таблице политик разрешения имен (NRPT). Если в NRPT есть совпадение и для имени нет правила исключения, то клиент DirectAccess отправляет запрос на разрешение имени на адрес IPv6 (6to4) сервера UAG DirectAccess. Если запрос относится к имени с одной меткой, то клиентский компонент DNS клиента DirectAccess добавит DNS-суффиксы, настроенные на сетевой карте или с помощью групповой политики.

Когда сервер UAG DirectAccess получает этот запрос, он отправляет запрос DNS-серверам, настроенным на его внутреннем интерфейсе, в том порядке, в котором DNS-серверы перечислены. Запрос DNS будет относиться как к записям узла IPv4 (A), так и к записи IPv6 Quad A (AAAA). Если DNS-сервер ответит серверу UAG DirectAccess записью Quad A, он вернет ее клиенту DirectAccess, и клиент DirectAccess подключится к IPv6-адресу, включенному в ответ Quad A, через туннели IPsec DirectAccess.

Однако, если DNS-сервер отвечает серверу UAG DirectAccess только с записью хоста IPv4 (A), у клиента DirectAccess в Интернете возникнут проблемы с этим, поскольку клиент DirectAccess может обмениваться данными только через IPv6. Чтобы решить эту проблему, компонент DNS64 сервера UAG DirectAccess сопоставит имя с адресом IPv6, а затем сообщит компоненту NAT64 сервера UAG DirectAccess о сопоставлении между адресом IPv6 и адресом IPv4.

Например, предположим, что клиенту DirectAccess в Интернете необходимо подключиться к SRV1.contoso.com. Он отправляет запрос имени на адрес IPv6 (6to4) сервера UAG DirectAccess через туннель IPsec. Сервер UAG DirectAccess отправляет запрос узла IPv4 (A) и узла IPv6 (Quad A) для SRV1.contoso.com на DNS-серверы, настроенные на его внутреннем интерфейсе. DNS-сервер возвращает только запись A с IP-адресом 10.0.0.66. Компонент DNS64 на сервере UAG DirectAccess сопоставляет 10.0.0.66 с адресом IPv6, например 2002::0066 (это только для примера, это не будет адрес, фактически сопоставленный с этим сервером). Компонент DNS64 сервера UAG DirectAccess сообщает компоненту NAT64, что он должен пересылать любые входящие запросы на 2002::0066 на IP-адрес 10.0.0.66. Состояние сеанса также отслеживается, поэтому ответы от 10.0.0.66 перенаправляются клиенту DirectAccess. Сервер UAG DirectAccess пересылает ответ на разрешение имени для SRV1.contoso.com с IP-адресом 2002::0066 клиенту DirectAccess в Интернете, и клиент DirectAccess отправляет запрос на подключение на этот адрес.

Как видите, DNS64/NAT64 действует как транслятор протоколов IPv6/IPv4, так что клиент DirectAccess в Интернете может подключаться только к ресурсам IPv4 в интрасети. На практике это означает, что компоненты на стороне клиента, установленные на клиенте DirectAccess, должны поддерживать IPv6, но компоненты на стороне сервера не обязаны поддерживать IPv6. Это значительно увеличивает число сценариев, в которых клиенты DirectAccess могут подключаться к ресурсам интрасети.

Ограничения

К сожалению, как и у всех решений на основе NAT, у этого решения есть некоторые ограничения и недостатки. Основные ограничения:

• NAT64/DNS64 будут потреблять память и вычислительные ресурсы, что может отрицательно сказаться на производительности сервера UAG DirectAccess.

• NAT64/DNS64 работает только в сценарии «прямой NAT». Это означает, что вы не можете «переключить NAT» из интрасети на клиент DirectAccess со станции управления IPv4. В результате вы не сможете инициировать подключение со станции управления только IPv4 к клиенту DirectAccess. Однако клиент DirectAccess может подключаться к станции управления до тех пор, пока клиент DirectAccess инициирует подключение. Если ваше решение может использовать это существующее соединение, вы сможете снова подключиться к клиенту DirectAccess.

• NAT64/DNS64 не содержит «редакторов NAT». Редакторы NAT часто используются, чтобы позволить приложениям внедрять сетевую информацию в протоколы своих приложений. Например, протокол FTP встраивает информацию об IP-адресации в свой протокол, а клиент OCS встраивает адрес IPv4 в протокол своего приложения. Они не будут работать с NAT64/DNS64, потому что нет редактора NAT, чтобы заставить их работать правильно.

Это основные проблемы, с которыми вы можете столкнуться при использовании решения NAT64/DNS64 сервера UAG DirectAccess. Имейте в виду, что NAT64/DNS64 будет использоваться только в том случае, если сервер, на котором работает ваше серверное приложение, не поддерживает IPv6 или само приложение не поддерживает IPv6. Если и сервер, и приложение поддерживают IPv6, то NAT64/DNS64 не будет использоваться, а связь от клиента DirectAccess к целевому серверу будет осуществляться по адресу ISATAP, назначенному серверу в корпоративной сети.

Примечание:
Интересным фактом о UAG DirectAccess NAT64/DNS64 является то, что компонент NAT64 является частью приложения TMG, установленного на сервере UAG DirectAccess, тогда как компонент DNS64 является частью кода UAG.

Еще одна вещь, о которой вы должны знать, это то, что NAT64/DNS64 позволяет развернуть DirectAccess в вашей организации, не требуя Windows 2008 R2 где-либо, кроме серверов UAG DirectAccess. Вся ваша компания может использовать домены Windows Server 2003, а ресурсы могут размещаться на Windows 2000 Server, Windows Server 2003 или Windows Server 2008 или даже на операционных системах сторонних производителей, и клиенты DirectAccess по-прежнему смогут подключаться к этим ресурсам. Вот почему так важен NAT64/DNS64 — он позволяет развернуть DirectAccess уже сегодня, без усилий и затрат на модернизацию инфраструктуры. Если вы слышали, что вам нужна сеть IPv6, прежде чем вы сможете развернуть DirectAccess, теперь вы знаете, что это определенно неправда; ваша сеть может быть полностью IPv4 и по-прежнему пользоваться огромными преимуществами, которые вы получаете, развертывая UAG DirectAccess.

Резюме

В этой статье вы узнали о том, что клиент DirectAccess всегда использует IPv6 для связи с сервером DirectAccess. Поэтому нам нужен способ, позволяющий клиенту DirectAccess взаимодействовать с ресурсами в интрасети, которые еще не поддерживают IPv6. Вы узнали, что решением этой проблемы является служба UAG NAT64/DNS64. Эта служба может сопоставлять имена и адреса ресурсов только IPv4 с адресами IPv6, которые могут использоваться клиентом DirectAccess. Это позволяет клиенту DirectAccess инициировать подключения к ресурсам в интрасети. Однако у службы NAT64/DNS64 есть некоторые ограничения, например неспособность ресурсов интрасети инициировать подключения к клиентам DirectAccess. К счастью, поскольку в большинстве случаев соединения агентов управления инициируются на стороне клиента, особых проблем, вероятно, не возникнет.

Далее

В следующей части этой серии (часть 4) мы поговорим о ключевых компонентах инфраструктуры поддержки, которые необходимы для обеспечения работы развертывания UAG DirectAccess. Эти компоненты включают в себя:

• Доменные службы Active Directory и групповая политика

• Службы доменных имен (DNS)

• Инфраструктура открытых ключей (PKI) и службы сертификации Windows Active Directory

• Серверы сетевого расположения

• Серверы списка отозванных сертификатов (CRL)

• Брандмауэр Windows с повышенной безопасностью и сетевыми брандмауэрами

• VPN-серверы удаленного доступа

• Инфраструктура NAP и смарт-карт

Тогда увидимся! – Деб.

• Полное руководство по UAG DirectAccess (часть 4) — требования к инфраструктуре
• Полное руководство по UAG DirectAccess (часть 5) — требования к инфраструктуре (продолжение)