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

Введение

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

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

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

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

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

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

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

Клиенты DirectAccess используют серверы сетевых расположений (NLS), чтобы определить, находятся ли они в корпоративной сети или вне ее. Когда вы запускаете мастер UAG DirectAccess, он попросит вас указать имя NLS. NLS — это общий веб-сайт SSL, который можно установить на любой веб-сервер; вам не нужно использовать веб-сервер IIS. Единственное требование состоит в том, что клиент DirectAccess в интрасети должен подключиться к веб-сайту NLS и получить ответ HTTP 200. При получении этого ответа HTTP 200 клиентский компьютер DirectAccess отключит таблицу политик разрешения имен (NRPT) и будет использовать DNS-сервер, назначенный его сетевому адаптеру, для разрешения имен в корпоративной сети.

Для NLS важно быть высокодоступным. Если клиент DirectAccess находится в корпоративной сети, но не может подключиться к NLS, он будет считать, что находится в Интернете, и оставит NRPT включенным. Это может представлять большую проблему, поскольку клиент DirectAccess попытается использовать IPv6-адрес сервера DirectAccess для разрешения имен хостов. Это может быть или не быть возможным, в зависимости от конфигурации вашей сети. Это также зависит от того, может ли служба Network Location Awareness (NLA) определить, находится ли клиент DirectAccess в корпоративной сети. Если NLA не может определить, что клиент DirectAccess находится в корпоративной сети, а NRPT остается включенным, и если существует путь между клиентом DirectAccess, расположенным в корпоративной сети, и внешним интерфейсом сервера UAG DirectAccess, возможно, что DirectAccess клиент, расположенный в корпоративной сети, сможет подключаться к ресурсам корпоративной сети, возвращаясь в сеть через сервер UAG DirectAccess. Как вы можете себе представить, если у вас есть большое количество внутренних клиентов, которые делают это, это может сильно затормозить вашу интернет-связь.

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

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

Веб-серверы, на которых размещается список отзыва сертификатов для сертификатов, используемых NLS и прослушивателем IP-HTTPS, также должны быть высокодоступными. Если клиент DirectAccess, расположенный в корпоративной сети, не может подключиться к расположению списка отзыва сертификатов, указанному в сертификате NLS, попытка подключения завершится неудачно, и клиент DirectAccess будет думать, что он находится в корпоративной сети, и не отключит свой NRPT. Если клиент DirectAccess в Интернете пытается подключиться к прослушивателю IP-HTTPS на внешнем интерфейсе сервера UAG DirectAccess и ему не удается подключиться к расположению CRL, указанному в сертификате IP-HTTPS, то IP-HTTPS подключение не удастся.

Самым простым решением для сертификата IP-HTTPS является использование коммерческого центра сертификации. У коммерческой организации уже должна быть надежная инфраструктура, обеспечивающая высокую доступность CRL. Вы можете использовать аналогичную стратегию с вашими NLS-сертификатами, но, поскольку они являются внутренними серверами, вы, скорее всего, будете использовать свою частную PKI. В этом случае вам необходимо убедиться, что ваша внутренняя инфраструктура CRL также высокодоступна. Для этого можно использовать любое количество методов, например с помощью NLB или внешнего балансировщика нагрузки. Однако обратите внимание, что не рекомендуется использовать циклический перебор DNS, потому что клиент DNS не проходит весь список, если он может разрешить имя; он просто подключается к первому серверу в списке и не переходит к следующей записи, если попытка подключения не удалась.

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

UAG DirectAccess свободно использует брандмауэр Windows в режиме повышенной безопасности. Чтобы DirectAccess работал, брандмауэр Windows должен быть включен как на сервере UAG DirectAccess, так и на клиентах DirectAccess. Причина этого в том, что существуют правила брандмауэра и правила безопасности подключения, настроенные на сервере UAG DirectAccess и клиентах DirectAccess, которые включают всю модель подключения и аутентификации DirectAccess.

Правила безопасности подключения используются для создания туннелей IPsec DirectAccess между клиентом DirectAccess и сервером UAG DirectAccess. Правила также включают разрешенные IP-адреса источника и получателя, а также тип аутентификации и шифрования, применяемые к туннелям. Кроме того, существует ряд правил брандмауэра, которые используются для контроля и управления типом трафика, разрешенного через эти туннели, а также для указания того, какой трафик исключается из согласований IPsec.

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

Использование сетевых брандмауэров зависит от вас и вашей корпоративной политики. Сервер UAG DirectAccess разработан как пограничное устройство, что означает, что его можно безопасно разместить на границе корпоративной сети без использования перед ним другого брандмауэра (я говорю «другой» брандмауэр, потому что на UAG уже есть брандмауэр TMG). сервер). Однако из-за того, что сервер UAG DirectAccess является членом домена, а многие организации по тем или иным причинам требуют наличия брандмауэра перед членом домена (независимо от того, что на сервере UAG DirectAccess уже есть брандмауэр), вам нужно будет рассмотреть конфигурацию сетевого брандмауэра перед сервером UAG DirectAccess.

Сетевой брандмауэр перед сервером UAG DirectAccess должен быть настроен на:

• Разрешить входящий и исходящий IP-протокол 41 на внешние IP-адреса сервера UAG DirectAccess и с них.

• Разрешить входящий и исходящий UDP-порт 3544 для внешних IP-адресов сервера UAG DirectAccess.

• Разрешить входящий и исходящий TCP-порт 443 для внешних IP-адресов сервера UAG DirectAccess.

Что касается внутренних брандмауэров, то в них нет необходимости. Брандмауэр TMG находится на сервере UAG DirectAccess и поэтому действует как внешний и внутренний брандмауэр для сервера UAG DirectAccess. Однако, если в вашей политике указано, что за сервером UAG DirectAccess должен быть внутренний брандмауэр, вам следует настроить внутренний брандмауэр так, чтобы он разрешал весь трафик IPv4, входящий и исходящий через внутренний интерфейс сервера UAG DirectAccess. Кроме того, вам необходимо разрешить IP-протоколу 41 входить и выходить из внутреннего интерфейса сервера UAG DirectAccess для поддержки связи ISATAP в вашей сети.

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

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

В тех случаях, когда решение UAG DirectAccess не будет работать для определенного приложения, вам потребуется предоставить методы, которые позволят вашим пользователям использовать эти приложения. Лучшее решение зависит от характера клиент-серверного приложения. Например, клиент OCS не будет работать с решением NAT64/DNS64, поскольку используемый им протокол содержит адрес IPv4, который не может обработать транслятор протоколов NAT64/DNS64. Поэтому вам потребуется предоставить пользователям альтернативный метод доступа к серверу OCS из клиента Communicator. Один из способов сделать это — использовать прокси-сервер OCS, доступный в Интернете, и настроить NRPT таким образом, чтобы прокси-сервер OCS, доступный в Интернете, был недоступен через туннель UAG DirectAccess.

Однако не все приложения позволяют настроить доступный через Интернет прокси. В этом случае вам следует рассмотреть возможность предоставления доступа к VPN для этих пользователей. Возможность подключения VPN-клиента удаленного доступа также полезна для клиентов, не поддерживающих DirectAccess, таких как компьютеры с Windows XP и Vista. Если у вас уже есть VPN-решение, вы, безусловно, можете его использовать. Однако, если вы хотите консолидировать свое решение для доступа к VPN, вы можете рассмотреть возможность совместного размещения решения для подключения VPN-клиента удаленного доступа к решению UAG DirectAccess.

На самом деле это соответствует предпочтительному методу развертывания массивов UAG DirectAccess. UAG предлагает три ключевых сценария включения:

• Обратный веб-прокси и доступ к веб-порталу

• Прямой доступ

• Клиент удаленного доступа VPN

Если вы решите использовать все функции, включенные в UAG, вам следует рассмотреть возможность отделения массива обратного веб-прокси и доступа к веб-порталу от массива клиентов DirectAccess и удаленного доступа VPN. Вы можете разместить сервер UAG DirectAccess и сервер UAG SSTP на одном компьютере. Сервер SSTP будет поддерживать клиентов Vista SP1 и выше. Однако SSTP не поддерживается Windows XP, поэтому, если вы хотите предоставить удаленный доступ для клиентов Windows XP, вы можете потребовать от них использовать обратный веб-прокси или портальные приложения. Учитывая более высокую угрозу, которую сегодня Windows XP представляет для сетей, даже когда они полностью управляются, принудительное применение режима наименьших привилегий для клиентов Windows XP, заставляя их использовать веб-прокси или возможности портала, может быть лучшим решением в целом.

Резюме

В этой части 5 нашего полного руководства по UAG DirectAccess мы рассмотрели оставшиеся ключевые службы инфраструктуры, которые необходимо установить перед развертыванием серверов и массивов UAG DirectAccess. Эти службы инфраструктуры необходимы для обеспечения безопасности, разрешения имен и предоставления клиентам DirectAccess информации об их текущем расположении. Если все эти компоненты инфраструктуры отсутствуют, развертывание UAG DirectAccess не будет работать или будет работать непоследовательно и ненадежно. В следующем месяце мы продолжим нашу серию статей, рассмотрев некоторые аспекты безопасности для UAG DirectAccess. Тогда увидимся! – Деб.