Мы часто сталкиваемся с ситуацией, когда доступ к интернет-сервисам 1С, таким как «1С-Отчетность», обновление программ и классификаторов, проверка контрагентов и другие функции «Интернет поддержка и сервисы», работает корректно при использовании толстого клиента в файловом режиме, но прекращается при доступе к той же базе через тонкий клиент и веб-сервер IIS. Давайте разберем эту проблему подробно и найдем эффективные решения.
Основная сложность заключается в том, что при работе через веб-сервер IIS запросы к внешним ресурсам 1С инициируются не клиентским приложением, а рабочим процессом IIS (w3wp.exe), который запущен на сервере, где установлен веб-сервер. В отличие от толстого клиента, который может использовать персональные настройки прокси-сервера каждого пользователя или системные настройки прокси клиентского компьютера, процесс w3wp.exe может игнорировать эти настройки, пытаясь подключиться к интернет-сервисам 1С напрямую, без использования прокси. Это приводит к блокировке доступа, если сервер IIS находится за шлюзом с прокси-сервером или NAT.
Давайте рассмотрим основную причину, по которой «Интернет поддержка и сервисы» могут переставать работать, и как это исправить. Очень часто проблема кроется в некорректной настройке исключений прокси-сервера непосредственно в параметрах информационной базы 1С:Предприятия.
Перейдем к настройкам прокси-сервера в 1С:Предприятии. Запустите 1С:Предприятие под пользователем с правами администратора.
В конфигурациях, таких как 1С:Бухгалтерия 3.0, найдите раздел «Администрирование». В этом разделе, как правило, присутствует пункт, посвященный настройкам прокси-сервера для сервера 1С:Предприятия (если используется клиент-серверный вариант) или для веб-публикации (для файлового варианта с IIS). Обычно он называется «Серверная настройка прокси сервера» или «Настройка прокси-сервера».
Откроем вкладку «Дополнительно». В окне настроек прокси-сервера обратите внимание на вкладку «Дополнительно». Именно здесь содержатся параметры, связанные с исключениями, которые могут влиять на поведение процесса w3wp.exe.
На этой вкладке мы увидим опцию «Не использовать прокси для локальных адресов» или аналогичную ей. Под этим пунктом, скорее всего, есть поле для ввода списка адресов, для которых прокси-сервер должен игнорироваться.
Выясним причину ошибки. Распространенной ошибкой является ситуация, когда в список адресов, для которых не нужно использовать прокси, был по ошибке включен IP-адрес самого прокси-сервера. То есть, процесс 1С (запущенный через IIS) получает указание: «Для доступа к этому прокси-серверу не используй прокси-сервер». Это приводит к своеобразной «рекурсии» или, проще говоря, к логическому тупику. Вместо того чтобы отправить запрос через указанный прокси, 1С пытается получить доступ к внешним ресурсам напрямую, минуя прокси, потому что ошибочно считает, что прокси-сервер сам является «локальным адресом», для которого нужно прямое соединение. В итоге, запросы блокируются шлюзом, поскольку прямого доступа нет.
Исправим настройку. Внимательно просмотрите список адресов в разделе «Не использовать прокси для локальных адресов». Если вы обнаружите там IP-адрес вашего прокси-сервера, удалите его из этого списка.
После удаления некорректного адреса сохраните изменения и перезапустите веб-сервер IIS (или соответствующий пул приложений), а также убедитесь, что настройки применены в 1С. В большинстве случаев это действие немедленно решает проблему, и «Интернет поддержка и сервисы» начинают функционировать корректно.
Почему это работает для IIS, но не мешает толстому клиенту?
При работе в файловом варианте с толстым клиентом каждый клиентский компьютер использует свои собственные настройки прокси-сервера, которые обычно берутся из системных настроек Windows или из персональных настроек пользователя в 1С. Эти настройки не зависят от «Серверной настройки прокси сервера» и, как правило, не содержат данной ошибки. Поэтому толстый клиент продолжает успешно работать.
При использовании тонкого клиента через веб-сервер IIS, запросы от 1С к внешним сервисам инициируются непосредственно на сервере IIS процессом w3wp.exe. Этот процесс опирается на «Серверную настройку прокси сервера» информационной базы 1С. Когда эта серверная настройка была некорректна (с ошибочным исключением адреса прокси), процесс w3wp.exe не мог правильно использовать прокси, что приводило к проблемам.
Если вышеописанное решение не сработало или требуется более гибкая настройка, существуют и другие методы конфигурации прокси для приложений, работающих под IIS. Рассмотрим их подробнее.
Мы можем явно указать параметры прокси-сервера для веб-приложения 1С, добавив специальный раздел в файл web.config, который находится в корневой папке опубликованной базы 1С на сервере IIS.
Откройте файл web.config. Найдите корневую папку вашей опубликованной базы 1С на сервере IIS. В этой папке должен находиться файл web.config. Откройте его в текстовом редакторе (например, Блокноте или Notepad++).
Добавьте секцию defaultProxy. Мы добавим секцию <system.net> с подразделом <defaultProxy>. Важно разместить этот раздел внутри основного тега <configuration> и, если присутствует, после раздела <configSections>.
Давайте рассмотрим примеры для двух основных сценариев: когда прокси-сервер не требует авторизации и когда она необходима.
Если ваш прокси-сервер позволяет проходить трафик без ввода логина и пароля, мы можем использовать следующую конфигурацию:
<configuration>
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy
proxyaddress="http://proxyserver:80"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
</configuration>
Разберем параметры:
<system.net>: Этот раздел конфигурации .NET Framework определяет сетевые параметры для приложений.<defaultProxy>: Внутри <system.net> этот элемент указывает на прокси-сервер по умолчанию для всех исходящих запросов.
useDefaultCredentials="true": Мы указываем, что следует использовать учетные данные пользователя, от имени которого запущен пул приложений IIS (обычно это ApplicationPoolIdentity или LocalSystem, если вы его меняли). В данном случае, если прокси не требует авторизации, это может быть не критично, но полезно для единообразия.<proxy>: Этот элемент описывает сам прокси-сервер.
proxyaddress="http://proxyserver:80": Здесь мы указываем полный адрес вашего прокси-сервера, включая протокол и порт. Замените proxyserver на IP-адрес или доменное имя вашего прокси, и 80 на соответствующий порт.bypassonlocal="true": Мы предписываем системе не использовать прокси-сервер для запросов к локальным (внутрикорпоративным) ресурсам. Это предотвращает ненужную маршрутизацию внутреннего трафика через внешний прокси.Если ваш прокси-сервер требует авторизации (логин/пароль), задача усложняется, так как процесс w3wp.exe может не иметь прямых учетных данных для прокси.
Подход 1: Авторизация сервера на прокси.
В этом варианте мы используем те же настройки в web.config, что и в Сценарии 1. Однако ключевое отличие заключается в том, что администраторы вашего прокси-сервера должны предоставить доступ для IP-адреса сервера IIS без необходимости авторизации для определенных веб-ссылок или полностью для всего интернет-трафика. Это означает, что для сервера IIS прокси будет работать в режиме без авторизации, основываясь на его IP-адресе. Этот метод является наиболее предпочтительным, так как избавляет от необходимости жестко прописывать учетные данные в файлах конфигурации.
<configuration>
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy
proxyaddress="http://proxyserver:80"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
</configuration>
В этом случае useDefaultCredentials="true" будет работать, если сервер IIS уже авторизован на прокси по IP.
Подход 2: Указание учетных данных в web.config (менее безопасно).
Хотя это возможно, крайне не рекомендуется указывать учетные данные в открытом виде в файле web.config из соображений безопасности. Если такой подход необходим как временное решение или в изолированной среде, можно использовать:
<configuration>
<system.net>
<defaultProxy>
<proxy
proxyaddress="http://proxyserver:80"
bypassonlocal="true"
usesystemdefault="False"
/>
<credentials>
<add credentialName="ProxyCredential"
password="ProxyPassword"
domain="ProxyDomain"
userName="ProxyUser"
/>
</credentials>
</defaultProxy>
</system.net>
</configuration>
Здесь ProxyUser, ProxyPassword, ProxyDomain должны быть заменены на реальные учетные данные для прокси-сервера. Мы настоятельно рекомендуем использовать Подход 1 или рассмотреть другие методы безопасного хранения учетных данных, если прямое указание в web.config неизбежно.
Файл inetcfg.xml — это еще один важный конфигурационный файл для 1С, который позволяет задавать глобальные настройки прокси-сервера для платформы. Хотя он больше влияет на клиентские приложения или фоновые процессы 1С (а в нашем случае, проблема с IIS связана с другим контекстом), знание о нем полезно.
Мы можем найти файл inetcfg.xml в каталоге CONF установленного ПО 1С:Предприятия (например, C:\Program Files\1cv8\8.3.18.1741\conf\inetcfg.xml).
В этом файле можно указать следующие параметры:
<Proxy>: Основной узел для настроек прокси.
<Protocol>: Протокол прокси (например, HTTP).<Port>: Порт прокси (например, 8080).<Host>: IP-адрес или доменное имя прокси-сервера.<Login>: Логин для авторизации на прокси.<Password>: Пароль для авторизации на прокси.<BypassOnAddresses>: Список адресов, для которых прокси не используется (аналог исключений).<BypassOnLocal>: Флаг (true/false), указывающий, следует ли обходить прокси для локальных адресов.Например:
<InetConfig>
<Proxy>
<Protocol>HTTP</Protocol>
<Host>192.168.1.1</Host>
<Port>8080</Port>
<Login>user</Login>
<Password>password</Password>
<BypassOnAddresses>
<Address>192.168.0.0/16</Address>
<Address>*.local</Address>
</BypassOnAddresses>
<BypassOnLocal>true</BypassOnLocal>
</Proxy>
</InetConfig>
Хотя в данном конкретном случае (проблема с w3wp.exe и IIS) изменение inetcfg.xml не помогло автору, мы должны знать, что этот файл является важным элементом в общей системе настройки прокси для 1С. Его настройки имеют высокий приоритет и могут переопределять системные параметры прокси операционной системы для некоторых компонентов 1С.
Мы также можем рассмотреть изменение удостоверения (Identity) пула приложений IIS, под которым работает веб-публикация 1С. Этот подход иногда помогает, поскольку меняет контекст безопасности, в котором выполняется процесс w3wp.exe, и может повлиять на то, как он наследует системные настройки прокси.
Откройте диспетчер служб IIS (IIS Manager).
Перейдите к «Пулам приложений» (Application Pools). Найдите пул приложений, который используется для вашей веб-публикации 1С.
Измените «Дополнительные параметры» (Advanced Settings). Щелкните правой кнопкой мыши по нужному пулу приложений и выберите «Дополнительные параметры…».
Найдите пункт «Удостоверение» (Identity). По умолчанию оно обычно установлено в ApplicationPoolIdentity. Мы можем попробовать изменить его на LocalSystem или на учетную запись домена, которая имеет доступ в интернет через прокси.
LocalSystem: Эта учетная запись имеет широкие привилегии на локальном компьютере и иногда позволяет процессу w3wp.exe использовать системные настройки прокси, которые могут быть настроены для сервера.web.config, можно создать специальную доменную учетную запись с доступом в интернет и указать ее в качестве удостоверения пула приложений.Перезапустите пул приложений или весь IIS. После изменения удостоверения обязательно перезапустите пул приложений или весь веб-сервер IIS, чтобы изменения вступили в силу.
Важно отметить, что в случае с Windows 7 и IIS 7.5 (как в исходной теме) изменение удостоверения не принесло результата. Однако на более новых версиях Windows (например, Windows 10, Windows Server 2016/2019) и IIS (версии 10) этот метод может быть эффективным. Это подчеркивает, что поведение IIS и его взаимодействие с системными настройками прокси могут зависеть от версии операционной системы и веб-сервера.
Мы должны понимать, что w3wp.exe является основным рабочим процессом IIS, который выполняет весь код веб-приложений. Когда 1С обращается к интернет-сервисам через веб-сервер, эти запросы исходят от имени этого процесса. Его способность использовать прокси-сервер зависит от нескольких факторов:
web.config: Явные настройки прокси для .NET приложений.Проблемы с сертификатами и проверкой удаленного узла также могут возникать, если w3wp.exe не имеет доступа к сайтам, предназначенным для валидации сертификатов, или если некорректно настроены параметры прокси. В таких случаях мы можем проверить журналы событий Windows, чтобы определить причину сбоя (например, имя модуля, вызвавшего ошибку).
В некоторых случаях, когда все программные методы настройки прокси на сервере IIS исчерпаны или не дают желаемого результата, мы можем прибегнуть к настройке сетевого оборудования (фаервола, шлюза) для обеспечения доступа.
Идентификация внешних ресурсов 1С. Для корректной работы сервисов 1С (таких как «1С-Отчетность», обновление платформы и конфигураций, загрузка классификаторов и курсов валют, проверка контрагентов) необходим доступ к определенным внешним IP-адресам и доменным именам. Существуют обновленные списки этих ресурсов, которые можно найти на официальных сайтах 1С или у партнеров.
Например, к ним могут относиться:
regservice.keydisk.rureport.keydisk.ruservice.fsrar.ruf4.fss.rudownloads.1c.ruonline.1c.rulogin.1c.ruapi.1c.ru и другие.Настройка правил NAT/фаервола. Если прокси-сервер продолжает быть препятствием, мы можем настроить правила NAT или фаервола на вашем шлюзе (например, на FreeBSD с ipfw, как у автора) таким образом, чтобы трафик от IP-адреса сервера IIS к перечисленным выше IP-адресам и портам сервисов 1С разрешался напрямую, минуя прокси. Это может быть трудоемким процессом, требующим тщательной проработки правил безопасности.
Например, мы можем создать правила, которые разрешают серверу IIS прямой доступ к этим внешним адресам через порты 80 (HTTP) и 443 (HTTPS). Однако, мы должны помнить, что это решение является своего рода «костылем», поскольку обходит проблему взаимодействия IIS с прокси, вместо того чтобы решить ее на уровне программного обеспечения.
При возникновении проблем с доступом к интернет-сервисам через IIS, мы рекомендуем следующий порядок действий:
web.config: Проверьте или добавьте соответствующую секцию <defaultProxy> в файл web.config для вашей публикации 1С на IIS, учитывая, требуется ли авторизация для прокси.inetcfg.xml: Убедитесь, что глобальные настройки прокси в inetcfg.xml не противоречат вашим намерениям, хотя для проблемы с w3wp.exe этот файл обычно менее критичен.LocalSystem (для тестирования) или на учетную запись с явным доступом к интернету через прокси.w3wp.exe и на каком этапе трафик блокируется.w3wp.exe или сетевыми подключениями.Решение проблем с прокси-серверами всегда требует комплексного подхода и понимания взаимодействия между различными компонентами: 1С:Предприятием, веб-сервером IIS, операционной системой и сетевой инфраструктурой. Следуя этим рекомендациям, мы значительно повысим шансы на успешное восстановление работы «Интернет поддержки и сервисы» в 1С при доступе через веб-сервер IIS.