Иногда, когда системы загружаются, они вообще не принимают входящий трафик, и мои правила IPSec не работают для исходящих - кажется, что сервер застрял в какой-то начальной конфигурации после загрузки. Это в первую очередь для 2008 r2 и Windows 7.
Некоторое время назад я читал, что в расширенном брандмауэре Windows есть какая-то конфигурация по умолчанию, которая блокирует весь входящий трафик и разрешает только определенный исходящий трафик - к контроллерам домена, DNS, DHCP, если моя память обслуживает, - но блокирует весь другой доступ до тех пор, пока загружаются и применяются «настоящие» правила. Похоже, в этом состоянии мои системы застревают после перезагрузки.
Как называется это состояние и как я могу диагностировать свою проблему? Я давно потерял из виду эти детали, и теперь чертовски много времени ищу их снова.
РЕДАКТИРОВАТЬ:
Я наконец нашел правильное название для этого поведения, фильтр времени загрузки брандмауэра Windows
РЕДАКТИРОВАТЬ:
Это стало еще более странным. Похоже, теперь я могу устанавливать входящие соединения из систем без поддержки IPSEC, но все запросы IPSEC не работают. Я включил ведение журнала auditpol и получаю следующее.
Additional Information:
Keying Module Name: IKEv1
Authentication Method: Unknown authentication
Role: Responder
Impersonation State: Not enabled
Main Mode Filter ID: 0
Failure Information:
Failure Point: Local computer
Failure Reason: No policy configured <<< Looks wrong.
State: No state
Initiator Cookie: cec5de8d625d2196
Responder Cookie: 0d40a3b58c477709
Мне удалось временно обойти эту проблему, определив локальную политику IPSEC - даже правило брандмауэра работает - но я не уверен, почему это так, и что я могу сделать, чтобы исправить это в долгосрочной перспективе.
Описанные ниже изменения реестра позволили полдюжине моих серверов, к которым он был применен, загружаться без проблем. Хотя я еще не уверен на 100%, что это решение - было примерно 50/50, если бы сервер подошел чисто, это, похоже, очень помогло. Полдюжины серверов с 3+ перезагрузками на каждом работают нормально.
Name: ChainUrlRetrievalTimeoutMilliseconds
Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
Type: REG_DWORD
Decreasing the amount of time to allow CRL retrieval can significantly improve performance when internet access is poor or non-existent. Setting the value to 200 (milliseconds) may be a reasonable timeout.
Name: ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds
Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
Type: REG_DWORD
Decreasing the amount of time to allow all CRL retrievals can significantly improve performance when internet access is poor or non-existent. Setting the value to 500 (milliseconds) may be a reasonable timeout.
Фон, почему я думаю, что это исправление
На нескольких серверах в нашей среде возникали проблемы при перезагрузке, когда появлялись службы. Эти службы в основном так или иначе были связаны с .NET. Все они придумали 7009 событий. Некоторые службы на наших проблемных серверах брандмауэра также показывают этот идентификатор события. Хотя 7009 никогда не подходил для брандмауэра или базовой службы фильтрации, тайм-аут во время процесса загрузки - тем более, что он иногда загружается чисто - казался вероятным виновником.
Эти настройки реестра взяты из блога Technet, Настройка серверов Exchange без доступа в Интернет.