DirectAccess является новой технологией удаленного доступа от Microsoft, позволяющей всегда быть подключенным к сети компании независимо от места нахождения. К тому же, DirectAccess позволяет ИТ персоналу предприятия всегда быть подключенным к управляемым ими активам, чтобы иметь постоянную возможность управления этими активами, содержать их в актуальном состоянии, обеспечивать их соответствие и всегда держать их под контролем сотрудников ИТ отдела предприятия. DirectAccess обеспечивается сочетанием Windows 7 и Windows Server 2008 R2, и становится еще мощнее, если добавить в эту конфигурацию продукт Unified Access Gateway (UAG) 2010. Хотя работа DirectAccess возможна без UAG, без данного продукта это решение не является жизнеспособным, готовым к работе на предприятиях решением.

Я использую DirectAccess уже достаточно длительное время и не знаю, чтобы я делала без него. Очень удобно иметь постоянное подключение. Мне не нужно думать о запуске VPN подключений, не нужно беспокоиться о том, будет ли работать мое VPN подключение, и не нужно иметь дела с ужасными веб-приложениями, которые доступны через SSL VPN шлюз. Благодаря DirectAccess я могу использовать свои всевозможные приложения для настольных компьютеров на своем клиенте для выполнения качественной работы без необходимости задумываться о подключении. Я просто всегда подключена. С точки зрения пользователя – это мечта, ставшая реальностью.

Однако, администраторам, возможно, придется диагностировать DirectAccess подключения от случая к случаю. Хотя DirectAccess подключения весьма надежны, в мире нет ничего идеального, и могут возникать ситуации, когда клиенты не могут подключиться, в результате чего вам придется определять причины проблемы. Именно это мы и будем обсуждать в этой статье: некоторые основные шаги, которые можно предпринять для диагностики подключений DirectAccess клиентов.

Основываясь на документации Microsoft и своем собственном опыте проб и ошибок, предлагаю вам свой план из семи шагов по диагностике подключения DirectAccess клиентов:

• Проверить, что клиенты DirectAccess получили свои параметры групповой политики
• Проверить, что клиент знает, что он находится не в интрасети
• Проверить NRPT параметры на DirectAccess клиенте
• Проверить IPv6 адрес на DirectAccess клиенте
• Убедиться в наличии проверки подлинности для DirectAccess туннелей
• Проверить работоспособность подключения к DNS и контроллерам домена

А теперь давайте рассмотрим каждый шаг более подробно.

Проверка параметров групповой политики

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

Можно ввести wf.msc в строку поиска на машине Windows 7, чтобы открыть консоль брандмауэра Windows Firewall with Advanced Security. В левой панели консоли нажмите на разделе Правила безопасности подключения (Connection Security Rules).

Если вы видите три правила, показанных на рисунке 1: UAG DirectAccess Client ' Clients Access Enabling Tunnel ' All, UAG DirectAccess Clients ' Clients Corp Tunnel и UAG DirectAccess Clients ' Example NLA, то можете быть уверены, что групповая политика применена.

Проверка того, что клиент знает, что он находится не в интрасети

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

Можно быстро определить, знает ли клиент DirectAccess о том, находится ли он в или за пределами корпоративной сети, с помощью следующей команды:

netshdns show state

Эта команда должна вернуть результат, похожий на рисунок 2 ниже.

Как показано на рисунке, расположение машины обозначено как Вне корпоративной сети (Outside corporate network). Если бы машина сообщила о том, что она находится в пределах корпоративной сети, когда на самом деле это не так, то вам пришлось бы искать причину такого сообщения. А если машина, находясь в корпоративной сети, сообщает о том, что она находится за ее пределами, также придется искать причину этого. Во втором случае неисправность, скорее всего, в проблеме подключения к серверу сетевых расположений (Network Location Server - NLS).

Проверка параметров таблицы политики разрешения имен на клиенте DirectAccess

Таблица политики разрешения имен (Name Resolution Policy Table - NRPT) используется клиентом DirectAccess для определения того, какой DNS сервер должен использоваться для разрешения имени. Когда DirectAccess клиент находится во внутренней сети, NRPT отключена, и единственным DNS сервером, используемым клиентом, является DNS сервер, настроенный на его сетевой карте. Однако когда DirectAccess клиент находится за пределами корпоративной сети, NRPT включается и используется для определения того, какой DNS сервер будет использоваться для разрешения имен в зависимости от имени, которое нужно разрешить.

Параметры таблицы NRPT можно посмотреть с помощью следующей команды:

netsh namespace show effectivepolicy

На рисунке 3 видно, что все имена в домене corp.contoso.com будут отправляться на DNS сервер по адресу 2002:836b:3::836b:3, а это 6to4 адрес на сервере UAG DirectAccess. Сервер UAG DirectAccess используется в качестве DNS сервера, так как UAG DirectAccess использует DNS64 в качестве DNS прокси для клиентов DirectAccess. Обратите внимание, что имя nls.corp.contoso.com не имеет адреса DNS сервера в списке, поскольку оно представляет собой исключение из серверов в corp.contoso.com собрании. Причина в том, что вам не нужно, чтобы клиент DirectAccess подключался к NLS, находясь за пределами корпоративной сети, поскольку клиент DirectAccess использует подключение к NLS для определения того, когда он находится в корпоративной сети!

Проверка IPv6 адресов на клиенте DirectAccess

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

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

• 6to4
• Teredo
• IP-HTTPS

Вы можете определить то, какая технология туннелирования IPv6 используется, запустив команду ipconfig /all.

На рисунке 4 выше видно, что Tunnel adapter 6TO4 Adapter используется для подключения к UAG DirectAccess серверу и что для него назначен IP адрес и основной шлюз. Основной шлюз – это 6to4 адрес UAG DirectAccess сервера.

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

Проверка аутентификации клиента DirectAccess

Когда клиент DirectAccess подключается к UAG DirectAccess серверу, он использует IPsec туннели для обеспечения подключения к корпоративной сети. Здесь используется два туннеля:

• Туннель инфраструктуры (Infrastructure Tunnel) ' это туннель, создаваемый до входа пользователя с помощью сертификата компьютера и учетной записи пользователя компьютера в Active Directory, а также с помощью проверки подлинности NTLMv2. Используется два способа проверки подлинности для создания первого туннеля, и клиент DirectAccess может получить доступ только к определенному количеству компьютеров через туннель инфраструктуры.
• Туннель интрасети (Intranet Tunnel) ' этот туннель создается после создания туннеля инфраструктуры, поскольку туннель инфраструктуры необходим для предоставления доступа к контроллерам домена для проверки подлинности Kerberos. Туннель интрасети использует проверку подлинности на основе сертификата компьютера и на основе учетной записи вошедшего пользователя (Kerberos) для создания второго туннеля. Туннель интрасети позволяет пользователю подключаться к остальной части сети.

Вопрос заключается в следующем: как узнать, какой способ проверки подлинности используется и что не/работает? Одним из способов сделать это является использование консоли брандмауэра Windows Firewall with Advanced Security. Разверните раздел Наблюдение (Monitoring), затем разверните раздел Сопоставления безопасности (Security Associations) и нажмите на разделе Основной режим (Main Mode). Здесь вы видите сопоставления безопасности в основном режиме для туннелей инфраструктуры и интрасети, как показано на рисунке 5. Обратите внимание, что в разделе Второй способ проверки подлинности (2nd Authentication Method) есть подключения, использующие NLTMv2 и Kerberos V5. NTLM используется для проверки подлинности туннеля инфраструктуры, а Kerberos используется туннелем интрасети.

Обычно у вас не должно возникать проблем с NTLM проверкой подлинности. Чаще проблемы возникают с проверкой подлинности Kerberos. Убедитесь, что учетная запись пользователя не отключена и что она использует текущий пароль, а не кэшированный пароль. Обратите внимание, что вы не увидите никаких подключений по туннелю интрасети Kerberos, пока не попытаетесь подключиться к ресурсу, который не входит в состав собрания серверов, определенных как серверы инфраструктуры. Эти соединения проходят через туннель инфраструктуры с NTLM проверкой подлинности.

Проверка подключения к DNS серверам и контроллерам домена

Как и в случае диагностики сценариев без DirectAccess, необходимо убедиться, что клиент DirectAccess может взаимодействовать с вашими контроллерами домена и DNS серверами.

Например, можно выполнить следующую команду:

nltest /dsgetdc:

и вы получите результат подобный тому, что показан на рисунке 6 ниже. Здесь показано, что клиент DirectAccess смог подключиться к контроллеру домена, а также предоставлена информация о IPv6 адресе контроллера домена. Следует отметить, что если контроллер домена не имеет IPv6 адрес, вы все равно увидите здесь IPv6 адрес, но это будет NAT64 адрес.

Вы легко можете проверить разрешение имен с помощью пинга, как показано на рисунке 7 ниже.

Если пинг запрос не выполняется по имени ресурса, попробуйте выполнить пинг запрос по его адресу IPv6. Если ресурс не поддерживает IPv6, вы можете выполнить пинг по его NAT64 адресу. Для информации о том, как рассчитать NAT64 адрес для узлов, поддерживающих только IPv4, можете использовать информация на блоге Тома здесь.

Заключение

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

Автор: Деб Шиндер (Deb Shinder)