У нас есть Microsoft DirectAccess VPN, настроенная на Server 2008 R2 со сквозной безопасностью, и у нас проблемы с туннелем управления.
Клиент DirectAccess имеет DC / DNS и возможность подключения к интрасети, он может пинговать / rdp / и т. Д. На узлы интрасети. Однако соединения, исходящие от тех же узлов интрасети, могут достигать клиента только периодически. Иногда он работает нормально, иногда - нет.
При попытке установить входящее (из интрасети в клиент) соединение регистрируется сбой в основном режиме IPSec: событие 4653 с причиной сбоя «Политика не настроена».
Я думаю, что это может быть связано с состоянием туннеля доступа к интрасети (корпоративной) и перекрытием в настроенных подсетях для этих политик. Я не понял, что именно отличается в сценарии, где соединение работает, а где нет.
Признаками проблемы туннеля инфраструктуры DirectAccess является то, что вы можете выполнить эхо-запрос или RDP на IPv6-адрес контроллера домена в корпоративной сети, но вы не можете разрешить корпоративные DNS-имена, даже если NRPT действителен.
После нескольких лет работы с ним я обнаружил, что следующие две причины являются наиболее частыми причинами проблем с туннелем инфраструктуры, зависящими от компьютера, с DirectAccess.
1: Проблемы с сертификатом. Первые учетные данные, используемые для туннеля инфраструктуры, - это сертификат. Вы получите сообщение «Политика не настроена», если сертификат недействителен. Это может быть вызвано истекшим сроком действия сертификата, несоответствием имени субъекта, неправильным использованием сертификата (проверка подлинности сервера / проверка подлинности клиента через встроенный шаблон компьютера) или ваш опубликованный список отзыва для корневого или выдающего ЦС может быть устаревшим.
2: Проблемы с машинным аккаунтом. Вторые учетные данные, используемые для туннеля инфраструктуры, - это учетная запись компьютера. Я получил сообщение «Политика не настроена» на компьютерах, которые покинули домен и повторно присоединились к нему, или когда имя компьютера было повторно использовано. Когда это происходит, я не могу найти какие-либо проблемы с schannel (nltest) или где-либо еще в журнале событий, но учетная запись компьютера отказывается аутентифицироваться для DA. Это также регистрируется как событие сбоя основного режима IPSec на сервере DirectAccess.
Я не обнаружил никаких проблем с правилами согласования брандмауэра, которые вызывают проблемы с туннелем инфраструктуры (например, перекрывающейся подсети).