Перевод информационных баз 1С:Предприятия с файлового режима работы на клиент-серверный вариант (под управлением MS SQL Server, PostgreSQL или других СУБД) — стандартный этап масштабирования ИТ-системы любого предприятия. Однако в процессе миграции администраторы часто сталкиваются с неожиданной проблемой: в базах перестают функционировать различные онлайн-сервисы. Например, становится недоступным автоматическое заполнение реквизитов контрагентов по ИНН (сервис «1С:Контрагент»), не загружаются классификаторы (БИК, адресный классификатор ФИАС), не работает автоматическая проверка обновлений конфигурации, а программа выдает сообщения об отсутствии подключения к интернету.
При этом, если выгрузить эту же базу обратно в файловый вариант и запустить локально на том же самом сервере, все интернет-запросы начинают выполняться корректно. В этой статье мы подробно разберем, почему возникает такое различие в поведении программы, проанализируем основные причины сетевых блокировок и рассмотрим пошаговые методы исправления этой неполадки.
Для того чтобы эффективно решить проблему, нам необходимо детально проанализировать архитектуру выполнения сетевых запросов в различных режимах работы платформы 1С:
rphost.exe. Следовательно, запросы в глобальную сеть отправляются непосредственно с физического (или виртуального) сервера, на котором развернута служба «Агент сервера 1С:Предприятия». Сетевая активность происходит под правами и в окружении той системной учетной записи, от имени которой запущена данная служба в операционной системе.Как правило, служба сервера 1С по умолчанию устанавливается под специальной локальной учетной записью USR1CV8 (или Network Service, Local System). В крупных корпоративных сетях её часто перенастраивают на запуск от имени выделенного доменного пользователя. Если для этой учетной записи не настроен доступ в интернет, закрыты порты на брандмауэре или прописаны неверные сетевые параметры (например, устаревший прокси-сервер), серверные процессы 1С не смогут достучаться до серверов обновлений и онлайн-сервисов.
Давайте подробно рассмотрим наиболее эффективные методы решения этой проблемы.
Если в вашей корпоративной сети доступ в интернет регулируется через прокси-сервер, операционная система Windows обращается к настройкам прокси, заданным в системном профиле пользователя. Это классическая ситуация, описанная на форуме: служба сервера 1С была запущена от имени учетной записи, в профиле которой в браузере Internet Explorer был прописан устаревший адрес прокси-сервера.
Разберем по шагам, как исправить эту ситуацию, если служба 1С запущена от имени конкретного доменного или локального пользователя:
domain\srv_1c, нам необходимо зайти в систему именно под этим именем.services.msc, чтобы рабочие процессы перечитали конфигурацию окружения Windows.Важное примечание: Если служба сервера 1С запущена от имени встроенной системной учетной записи (например, Network Service или Local System), войти в систему интерактивно под этим пользователем невозможно. Настройка прокси через графический интерфейс IE для них крайне затруднена (требует редактирования реестра Windows в ветках соответствующих системных SID). В таких случаях мы рекомендуем использовать другие, более профессиональные методы настройки, описанные ниже.
Для того чтобы не зависеть от настроек профилей пользователей Windows и оперативно управлять параметрами подключения платформы 1С к интернету, разработчики предусмотрели специальный конфигурационный файл inetcfg.xml. Этот файл имеет наивысший приоритет для платформы 1С:Предприятие. Настройки, прописанные в нем, применяются ко всем процессам сервера (включая rphost.exe) независимо от того, под каким пользователем запущена служба.
Рассмотрим алгоритм настройки по шагам:
C:\Program Files\1cv8\conf\. Если на сервере установлена также 32-битная версия, аналогичный файл необходимо будет настроить в папке C:\Program Files (x86)\1cv8\conf\.inetcfg.xml. Если файла нет, создадим обычный текстовый документ и переименуем его, обязательно изменив расширение с .txt на .xml.
<config xmlns="http://v8.1c.ru/v8/inetcfg">
<proxy url="http://192.168.1.100:8080"
bypassOnLocal="true">
<bypassAddress>127.0.0.1</bypassAddress>
<bypassAddress>localhost</bypassAddress>
<bypassAddress>*.yourdomain.local</bypassAddress>
<user login="domain\your_user" password="your_password"/>
</proxy>
</config>
Разберем основные параметры этого файла:
url — указывает адрес и порт вашего корпоративного прокси-сервера.bypassOnLocal — принимает значение true или false. Определяет, нужно ли пускать запросы к локальным адресам в обход прокси-сервера.bypassAddress — список исключений (адресов, запросы к которым должны отправляться напрямую, минуя прокси). Сюда обязательно нужно внести адреса локальных веб-сервисов и баз данных.user — используется, если ваш прокси-сервер требует обязательной авторизации. Здесь указываются логин и пароль учетной записи, имеющей право выхода в интернет. Если авторизация на прокси прозрачная (NTLM/Kerberos), эту строку можно опустить.После сохранения файла inetcfg.xml перезапуск сервера 1С обычно не требуется, однако для гарантированного применения настроек новыми рабочими процессами рекомендуется выполнить перезапуск службы «Агент сервера 1С:Предприятия».
Если вы используете современные типовые конфигурации 1С, разработанные на базе Библиотеки Стандартных Подсистем (БСП), например, «1С:Бухгалтерия 3.0», «1С:ERP», «1С:Управление торговлей 11» и другие, у вас есть возможность задать сетевые настройки прокси-сервера непосредственно из пользовательского интерфейса программы.
Для этого выполним следующие действия:
rphost.exe.В тексте обращения автора упоминается использование операционной системы Windows Server 2008 R2. Это устаревшая ОС, поддержка которой со стороны корпорации Microsoft давно прекращена. На таких серверах администраторы регулярно сталкиваются со следующей проблемой: физический доступ к сайтам 1С есть (веб-страницы открываются), но при попытке программного обращения к веб-службам сервер выдает ошибку «Удаленный узел не прошел проверку» или «Ошибка SSL при работе с Интернет».
Выясним причину этой проблемы. Сервисы 1С (включая API проверки контрагентов, механизмы обновлений и платформу ИТС) используют защищенное соединение HTTPS, безопасность которого обеспечивается SSL/TLS сертификатами, выданными международным удостоверяющим центром GlobalSign. Поскольку на старых операционных системах отключены автоматические обновления корневых сертификатов, Windows Server 2008 R2 просто «не знает» о новых доверенных центрах сертификации и блокирует соединение с ними как потенциально небезопасное.
Разберем по шагам, как вручную установить актуальные корневые сертификаты на сервер:
GlobalSign Root R3) и промежуточные сертификаты (промежуточный сертификат центра, выдавшего подпись для сайтов 1С, например, gsgccr3dvtlsca2020.crt).Win + R, введем команду mmc и нажмем Enter.Root-R3.crt и завершим работу мастера импорта, согласившись с параметрами по умолчанию.Если ваша конфигурация 1С запущена в режиме совместимости с версией платформы 8.3.7 и ниже, либо сама платформа имеет устаревший релиз, поведение системы безопасности меняется. В этих режимах платформа 1С:Предприятие игнорирует системное хранилище сертификатов Windows и использует собственный встроенный список доверенных удостоверяющих центров.
Этот список хранится в специальном файле под названием cacert.pem, который располагается в каталоге установленной платформы 1С:
C:\Program Files\1cv8\8.3.X.X\bin\cacert.pem (где 8.3.X.X — номер релиза вашей платформы).
Если этот файл устарел, соединение с онлайн-сервисами будет разрываться на этапе SSL-рукопожатия (SSL Handshake). Чтобы исправить это:
cacert.zip.cacert.pem.cacert.pem в папке bin рабочего релиза платформы новым файлом. Рекомендуем предварительно сохранить резервную копию старого файла, переименовав его, например, в cacert.pem.bak.Начиная с версии платформы 8.3.10, механизмы безопасности 1С при установлении защищенного HTTPS-соединения строго проверяют статус отзыва SSL-сертификатов узла назначения. Даже если вы открыли полный доступ к целевым адресам 1С (например, к api.orgregister.1c.ru или login.1c.ru) на вашем корпоративном сетевом шлюзе или прокси-сервере, подключение все равно может завершаться ошибкой.
Это происходит потому, что серверу 1С для успешной проверки подлинности сертификатов дополнительно требуется доступ к внешним серверам проверки отзывов (по протоколам OCSP и CRL). Для сертификатов GlobalSign такими серверами являются:
ocsp.globalsign.comcrl.globalsign.comsecure.globalsign.comЕсли эти адреса заблокированы на брандмауэре вашей компании для учетной записи, под которой функционирует сервер 1С, проверка статуса отзыва завершится аварийно по таймауту, и платформа разорвет безопасное соединение с онлайн-сервисом. Рекомендуется проверить правила фильтрации трафика на пограничном оборудовании и внести указанные домены в список разрешенных сетевых направлений (белый список).
Даже если брандмауэр Windows (Windows Firewall) полностью отключен администратором (как в рассматриваемом случае на форуме), на сервере могут присутствовать сторонние компоненты защиты, способные блокировать исходящую сетевую активность рабочих процессов 1С:
Эти программы могут классифицировать интенсивную отправку HTTP-запросов со стороны процесса rphost.exe на внешние веб-ресурсы как подозрительную активность (например, как попытку утечки данных или работу вредоносного ПО) и молчавно блокировать исходящие сокеты. Для решения этой проблемы рекомендуется добавить исполняемые файлы сервера 1С (ragent.exe, rmngr.exe, rphost.exe) в список доверенных программ локального антивирусного ПО и исключить их сетевой трафик из контура глубокого сканирования (SSL-дешифрации).
Мы детально изучили проблему блокировки онлайн-сервисов 1С при переходе на клиент-серверный вариант работы и разобрали весь спектр технических решений. Как показала практика, корень проблемы практически всегда лежит в плоскости разграничения прав доступа и сетевых настроек учетных записей операционной системы.
Для гарантированного устранения подобных неполадок рекомендуем придерживаться следующего чек-листа:
inetcfg.xml для жесткого и централизованного контроля сетевых параметров платформы 1С.