Microsoft предложила несложный метод обойти некоторые ошибки загрузки и установки обновлений Windows

Microsoft сделала ряд важных анонсов для IT‑администраторов, включая версия исправления (hotfix) для SCCM (номер KB38982839) и добавление новой функции для устранения неполадок, появления которой давно ожидали пользователи. Кроме того, техгигант опубликовал руководство по технологии Delivery Optimization (“Оптимизация доставки”), позволяющей существенно экономить интернет‑трафик при загрузке обновлений Windows.

Вслед за этим организация напомнила о необходимости применения ряда полезных сетевых настроек. Microsoft рекомендует администраторам ознакомиться с инструкциями по настройке брандмауэров и прокси‑серверов для обеспечения бесперебойной работы службы обновлений Windows. По данным компании, некоторые проблемы с подключением к службе обновлений могут быть вызваны особенностями реализации сетевой безопасности: используемые брандмауэры или прокси‑серверы могут препятствовать установлению соединений, необходимых для работы службы.

Это имеет критическое значение, поскольку служба обновлений Windows не доверяет автоматически любому серверу, ответившему на запрос. Она использует протокол TLS и проверяет, связан ли сертификат сервера с определённым доверенным корневым центром сертификации (trust anchor), признанным службой обновлений Windows. Если тест не проходит успешно, Windows разрывает соединение, отказываясь взаимодействовать с сервером, подлинность которого не удалось подтвердить.

В Microsoft поясняют, что такой подход обеспечивает следующие преимущества при обмене данными между устройством и веб‑сервером:

• безопасность соединения от перехвата данных (прослушивания) за счёт шифрования информации, передаваемой между устройством и сервером;

• функция обнаружения изменений, внесённых в данные при передаче по сети, за счёт механизмам проверки целостности, доступным на устройстве;

• доверие к соединению: устройство проверяет TLS‑сертификат подлинности, предоставляемый сервером для подтверждения своей идентификации.

Проблемы могут возникать в организациях, использующих брандмауэры или прокси‑серверы с функцией инспекции TLS‑трафика. Такие системы могут перехватывать соединение и генерировать собственный сертификат, который служба обновлений Windows может отклонить, так как он не был выдан непосредственно самой службой. Этот механизм безопасности призван защитить процедура обновления Windows от атак типа «человек посередине» (man‑in‑the‑middle), тем не менее при неправильной настройке сети он может блокировать легитимные соединения для загрузки обновлений.

В ряде случаев проблемы могут вызывать и VPN‑сервисы. Microsoft отмечает, что некоторые VPN‑провайдеры могут блокировать DNS‑запросы или доступ к службам обновлений Windows, из‑за чего устройства теряют возможность корректного подключения. Следовательно администраторам, сталкивающимся со сбоями при обновлении через VPN, рекомендуется обращаться за разъяснениями к своему VPN‑провайдеру. Чтобы лучше понять суть проблемы, Microsoft рекомендует изучить блог аудита Центра обновления Windows (его можно сформировать с помощью команды PowerShell Get-WindowsUpdateLog) и найти в нем определённые коды ошибок.

Например, сбой 0×8024402c указывает на то, что не удалось разрешить DNS‑имя сервера Центра обновления Windows; это может произойти, если сеть организации блокирует преобразование FQDN (полного доменного имени) в IP‑адрес. В то же время сбой 0×80240438 свидетельствует о том, что FQDN успешно разрешили, но установить соединение с конечной точкой не удалось, что прямо указывает на блокировку подключения брандмауэром или прокси‑сервером.

Равным образом встречаются ошибки 0×80245006 и 0×80240437, которые могут указывать на проблемы с проверкой TLS‑сертификата сервера Центра обновления Windows. По данным Microsoft, такие ошибки возникают, когда брандмауэр или прокси‑сервер выполняет проверку (инспекцию) TLS‑трафика и практически подменяет сертификат, который ожидает увидеть Windows.

К счастью, подход может быть довольно простым: Microsoft рекомендует настроить брандмауэры и прокси‑серверы так, чтобы они пропускали подключения к Центру обновления Windows без перехвата TLS‑трафика, для чего необходимо создать соответствующие исключения для нужных DNS‑имен хостов.

Здесь на помощь приходят FQDN (полные доменные имена): администраторам необходимо добавить в список доверенных соответствующие DNS‑хосты и поддомены, связанные с рекомендованными шаблонами FQDN (использующими подстановочный знак «*»). В качестве примера организация приводит второй:

«[...]вот рекомендуемое DNS‑имя хоста: *.update.microsoft.com [...] Оно охватывает все перечисленные ниже хосты и поддомены:»

update.microsoft.com

sls.update.microsoft.com

tas02.sls.update.microsoft.com“.”

Однако организация добавляет, что использование подстановочного знака (wildcard) подразумевает рекурсивный охват: администраторам не следует ограничиваться разрешением лишь одного имени хоста в расчёте на то, что все необходимые конечные точки Центра обновления Windows будут работать. Помимо этого, Microsoft отмечает, что имена хостов и DNS‑поддоменов со временем могут меняться, следовательно важно придерживаться рекомендованной конфигурации конечных точек, а не жёстко прописывать (хардкодить) отдельные адреса.

Существует одно важное удаление для организаций, использующих службу Windows Server Update Services (WSUS). В такой конфигурации устройства под управлением Windows подключаются к серверу WSUS, администрируемому IT‑службой, а не напрямую к службе Windows Update, следовательно для этих подключений не требуются описанные выше исключения для полных доменных имен (FQDN) службы Windows Update.