• обновление windows через squid или в обход, PavelR, 07:47 , 09-Дек-11, (1)
  • обновление windows через squid или в обход, decrups, 12:34 , 09-Дек-11, (3)
• обновление windows через squid или в обход, zandyg, 07:51 , 09-Дек-11, (2)

> 1) Пишите по сообщению в день, может быть вам помогут, это,
> без сомнений, верный путь.
> 2) Желательно сообщения не менять, т.е. ничего не делать, тупо ждать ответов.
> 3) Как сделать «через сквид» подробно расписано в вашем же вопросе, но
> почему вы этим не пользуетесь — из вопроса не понятно, и
> это исключительно ваша проблема.
> 4) см. п. 1.

Спасибо за ответ.
Проняло.
Действительно все подробно расписано.
Заработало.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Устраняем ошибки Windows Update при работе через прокси-сервер Squid

Устраняем ошибки Windows Update при работе через прокси-сервер Squid

При работе с прокси-сервером Squid вы можете столкнуться с ситуацией, когда служба Windows Update или WSUS перестанут получать обновления. Ситуация действительно неприятная и проявляется она чаще всего уже «по факту», когда клиентские машины перестают получать обновления и нужно срочно принимать меры. Однако такое поведение службы обновления давно известно и отражено в документации. Сегодня мы разберем подробно причину возникновения ошибки и покажем возможные действия по ее устранению.

Внешнее проявление неисправности сводится к тому, что служба Windows Update не может загрузить обновления и сопровождается одним из кодов ошибки:

• 0x80244017
• 0x80244018
• 0x80244019
• 0x8024401B
• 0x80244021

Для ее возникновения требуется сочетание нескольких факторов: наличия в сети прокси-сервера с аутентификацией пользователей и службы WPAD. Неподготовленного администратора данная ошибка застает врасплох, однако существует статья KB896226, которая подробно проливает свет на проблему и способы ее решения:

Чтобы устранить эту проблему, убедитесь, что прокси-сервер или брандмауэр настроены для анонимного доступа к веб-сайту Центра обновления Windows.

Если коротко, то суть происходящих событий следующая: для доступа к серверам Центра обновлений система использует службу Windows HTTP (WinHTTP), которая в свою очередь поддерживает автоматическое получение настроек прокси через WPAD. Т.е. все запросы к серверам обновлений будут автоматически направлены на прокси, это не доставляет проблем до тех пор, пока прокси-сервер не начинает требовать аутентификации клиентов. Службы Windows Update не могут пройти аутентификацию и возникает проблема с получением обновлений.

Чтобы избавиться от этой ошибки следует выполнить рекомендации Microsoft и обеспечить анонимный доступ к серверам обновлений. Сделать это можно достаточно просто и несколькими способами. Рассмотрим их подробнее.

Squid

Система контроля доступа Squid дает в руки администратора мощный инструмент управления и этим следует пользоваться. Тем более что стоящая перед нами задача ничем не отличается от URL-фильтрации по спискам, о которой мы рассказывали ранее.

Создадим отдельный список для служб Windows Update:

и внесем в него следующие записи:

За его основу мы взяли список из KB896226 который актуализировали и дополнили исходя из собственного опыта и наработок коллег.

Теперь создадим элемент ACL для работы со списком:

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

После чего перезапустите прокси-сервер и проверьте доступ к серверам обновлений, он должен восстановиться.

Существует также еще один вариант — направить трафик к серверам обновлений минуя прокси-сервер. В этом нам поможет протокол WPAD, точнее специальные правила в PAC-файле. На наш взгляд этот метод менее предпочтителен, но вполне имеет право на существование.

Для его реализации добавьте в файл wpad.dat следующие инструкции:

Изменения вступают в силу сразу, перезапускать службы не требуется.

При использовании данного метода следует принять во внимание еще один момент — если вы принимали меры по запрету обхода прокси, например, при помощи iptables, то следует явно разрешить соединения к серверам обновлений. На текущий момент указанным серверам соответствуют следующие IP-адреса:

Собственно, поэтому не рекомендуем данный способ, так как поддерживать один список доменных имен для Squid проще, чем два, тем более что соответствие доменных имен IP-адресам может меняться. В любом случае теперь вы понимаете источник проблемы и можете самостоятельно выбрать наиболее предпочтительный способ ее решения.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Votum separatum — Yuri Voinov’s Blog

Особое мнение — блог Юрия Воинова

вторник, 27 октября 2015 г.

Squid: SSL Bump и Windows Update

Допустим, что вы — умная маша, сделали sniffing сессии WU, и увидели некоторые адреса авторизационных серверов до получения ошибки WindowsUpdate_80072F8F или чего-то подобного. Вы видите IP, скажем, 191.234.72.190. Делаете реверсивный запрос — обана! — и получаете примерно вот это:

Сделайте так. Напишите файл url.nobump:

Добавьте его в свой squid.conf в группу правил SSL Bump:

Все. Ошибка ушла навсегда. Вам больше не надо вылавливать сети MS, используя сниффер и tcpiputils.com.

Одно предупреждение напоследок: Часть обновлений Windows может не кэшироваться ввиду попадания CDN на адреса диапазонов данных серверов. Я вас предупредил.

UPDATE

Не совсем все. Как оказалось, WU в некоторых случаях все еще использует в стартовых соединениях HTTPS с сайферами, использующими RC4 и 3DES. Если вы сконфигурировали свой набор сайферов на прокси по рекомендациям Мозиллы, вы рискуете получить ошибку WindowsUpdate_80072F8F снова и сразу в момент начала процесса обновления. Чтобы избежать этого, вам необходимо модифицировать список используемых сайферов прокси сделующим образом:

Такой же набор надо выбрать и на стороне прокси, обращенной к клиенту:

Navigation

Search

How do I make Windows Updates cache?

Windows Update generally (but not always) uses HTTP Range-Offsets’ (AKA file partial ranges) to grab pieces of the Microsoft Update archive in parallel or using a random-access algorithm trying to reduce the web traffic. Some versions of Squid do not handle or store Ranges very well yet.

A mix of configuration options are required to force caching of range requests. Particularly when large objects are involved.

maximum_object_size. Default value is a bit small. It needs to be somewhere 100MB or higher to cope with the IE updates.

UPDATE: Windows 8.1 upgrade pack requires up to 5GB objects to be cached. It will however, cache nicely provided the size limit is set high enough.

range_offset_limit. Does the main work of converting range requests into cacheable requests. Use the same size limit as maximum_object_size to prevent conversion of requests for objects which will not cache anyway. With Squid-3.2 or later use the windowsupdate ACL list defined below to apply this offset limit only to windows updates.

quick_abort_min. May need to be altered to allow the full object to download when the client software disconnects. Some Squid releases let range_offset_limit override properly, some have weird behavior when combined.

Due to the slow-down problem below we recommend service packs be handled specially:

• Extend the maximum cached object size to the required size, then run a full download on a single machine, then run on a second machine to verify the cache is being used. Only after this verification succeeds open updating to all other machines through the proxy.

Preventing Early or Frequent Replacement

Once you have done the above to cache updates you encounter the problem that some software often forces a full object reload instead of revalidation. Which pushes the cached content out and fetches new objects very frequently.

An idea that was floating around suggested that you use a refresh_pattern regexp config to do your WU caching. I decided to test this idea out in my squid proxy, along with one or 2 other ideas (the other ideas failed hopelessly but the WU caching worked like a charm.)

The idea basically suggested this:

The original idea seemed to work in theory, yet in practicality it was pretty useless — the updates expired after 30 minutes, there were download inconsistencies, and a whole array of issues. So looking at the HTTP responses and documentation for refresh_pattern, there was an extra clause that could be added. This is how it changed:

Now all that this line tells us to do is cache all .cab, .exe, .msu, .msu, .msf, .asf, .psf, .wma. to .zip from microsoft.com, and the lifetime of the object in the cache is 4320 minutes (aka 3 days) to 43200 minutes (aka 30 days). Each of the downloaded objects are added to the cache, and then whenever a request arrives indicating the cache copy must not be used it gets converted to an if-modified-since check instead of a new copy reload request.

So adding it to the original Squid settings to do with refresh_pattern, we get:

This should limit the system from downloading windows updates a trillion times a minute. It’ll hand out the Windows updates, and will keep them stored in the squid cache.

I also recommend a 30 to 60GB cache_dir size allocation, which will let you download tonnes of windows updates and other stuff and then you won’t really have any major issues with cache storage or cache allocation or any other issues to do with the cache. . .

Why does it go so slowly through Squid?

The work-around used by many cache maintainers has been to set the above config and force Squid to fetch the whole object when a range request goes through.

Compounding the problem and ironically causing some slowdowns is the fact that some of the Microsoft servers may be telling your Squid not to store the archive file. This means that Squid will pull the entire archive every time it needs any small piece.

You will need to test your squid config with smaller values for the range_offset_limit bypass and see which provides the best results for you.

Another symptoms which occasionally appear when attempting to force caching of windows updates is service packs.

If the quick_abort_min, quick_abort_max, quick_abort_pct settings are set to abort a download incomplete and a client closes with almost but not quite enough of the service pack downloaded. That clients following requests will often timeout waiting for Squid to re-download the whole object from the start. Which naturally causes the problem to repeat on following restart attempts.

How do I stop Squid popping up the Authentication box for Windows Update?

Add the following to your squid.conf, assuming you have defined localnet to mean your local clients. It ‘MUST‘ be added near the top before any ACL that require authentication.

The above config is also useful for other automatic update sites such as Anti-Virus vendors, just add their domains to the acl.