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-WindowsUpdateLogs) и найти в нем определённые коды ошибок.
Например, ошибка 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.
Источник: habr.com