Публикация базы 1С на веб-сервере: IIS, Apache, HTTPS и типичные ошибки

Публикация базы 1С через веб-сервер нужна, когда пользователям требуется доступ к информационной базе через браузер, тонкий клиент по HTTP/HTTPS, мобильное приложение, HTTP-сервисы, веб-сервисы или интеграции с внешними системами.

На первый взгляд задача выглядит простой: выбрать базу в конфигураторе, нажать «Опубликовать», указать веб-сервер — и открыть ссылку в браузере. На практике публикация 1С затрагивает сразу несколько уровней инфраструктуры: платформу 1С, веб-сервер, права учетных записей, сетевые порты, SSL-сертификат, каталог публикации и параметры подключения к информационной базе.

Если один из этих элементов настроен неверно, веб-клиент может не открываться, HTTP-сервис не будет отвечать, браузер покажет ошибку HTTPS, а интеграция с сайтом или CRM перестанет передавать данные.

В этой статье разберем, как устроена публикация 1С на веб-сервере, когда использовать IIS или Apache, какие файлы создаются при публикации, зачем нужен default.vrd, как безопасно настроить HTTPS и что проверить при типичных ошибках.

Что значит «опубликовать базу 1С»

Публикация базы 1С — это настройка веб-сервера, через который внешние клиенты и сервисы могут обращаться к информационной базе по HTTP или HTTPS.

При публикации создается виртуальное приложение на веб-сервере, каталог публикации и файл описания default.vrd. Веб-сервер получает запрос от пользователя или внешней системы и передает его модулю расширения 1С, который уже взаимодействует с нужной информационной базой.

Упрощенно схема выглядит так:

Пользователь / браузер / интеграция
                    │
                    ▼
              HTTPS / порт 443
                    │
                    ▼
        Reverse proxy — при наличии
            например, Nginx
                    │
                    ▼
         Штатный веб-сервер 1С
              IIS или Apache
                    │
                    ▼
       Расширение веб-сервера 1С
                    │
                    ▼
             Кластер 1С
      agent / manager / worker processes
                    │
                    ▼
        SQL Server / PostgreSQL

Когда нужна публикация через веб-сервер

Публикация базы 1С нужна не только для веб-клиента. Через веб-сервер могут работать разные сценарии доступа и интеграции.

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

Веб-клиент и интеграционные сервисы требуют разных правил доступа

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

• какой способ аутентификации используется;
• какая учетная запись 1С выполняет запросы;
• какие методы и данные доступны этой учетной записи;
• нужно ли ограничение по IP или доступ только через VPN;
• как будут храниться пароли, токены и другие учетные данные;
• какие события должны попадать в журналы;
• нужен ли отдельный адрес публикации для интеграции.

IIS или Apache: когда нужен Nginx

Платформа 1С может использовать разные веб-серверы, но выбор обычно зависит от операционной системы, роли сервера и опыта администратора.

Для Windows-инфраструктуры чаще выбирают IIS, потому что он штатно входит в Windows Server и хорошо вписывается в типовую среду 1С. Для Linux-инфраструктуры чаще используют Apache. Nginx во многих проектах применяют как внешний reverse proxy: он принимает HTTPS-запросы, а дальше передает их на внутренний веб-сервер.

Не стоит выбирать веб-сервер только по принципу «какой быстрее». Для публикации 1С важнее поддерживаемая конфигурация, опыт сопровождения, безопасность, понятный план обновления и возможность быстро диагностировать ошибки.

Из чего состоит публикация 1С

При публикации информационной базы создается не просто ссылка для открытия 1С в браузере. Публикация состоит из нескольких связанных элементов: виртуального приложения веб-сервера, физического каталога, расширения платформы и файла default.vrd.

Если публикация перестала работать после обновления платформы, переноса сервера или изменения настроек IIS или Apache, проверять нужно каждый из этих элементов.

Виртуальное приложение и каталог

На веб-сервере создается виртуальное приложение или каталог с именем публикации, например /trade или /buh. Это имя становится частью адреса, по которому пользователи и внешние системы обращаются к информационной базе:

https://1c.example.ru/trade

Виртуальному приложению соответствует физический каталог на диске. В нем размещаются служебные файлы публикации, включая default.vrd. Веб-сервер должен знать физический путь к этому каталогу, а его рабочая учетная запись должна иметь необходимые права чтения.

При проверке виртуального приложения важно убедиться, что:

• имя публикации соответствует адресу, который используют пользователи и интеграции;
• в IIS или Apache указан правильный физический каталог;
• каталог существует и доступен учетной записи веб-сервера;
• привязки домена и HTTPS настроены для нужного сайта;
• публикация не конфликтует с другим приложением или каталогом с таким же именем.

Расширение веб-сервера

IIS или Apache не взаимодействует с информационной базой напрямую. Запросы передаются специальному расширению веб-сервера, которое входит в состав платформы 1С. Оно читает параметры публикации и организует взаимодействие с файловой базой либо кластером серверов 1С.

Расширение должно соответствовать:

• используемому веб-серверу — IIS или Apache;
• операционной системе и ее разрядности;
• разрядности рабочего процесса или пула приложений;
• версии платформы, с которой работает информационная база.

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

Файл default.vrd

default.vrd — это файл описания публикации. Он сообщает расширению веб-сервера, с какой информационной базой нужно работать и какие возможности должны быть доступны через конкретную публикацию.

В нем могут быть указаны:

• строка подключения к информационной базе;
• параметры веб-клиента;
• публикуемые HTTP-сервисы;
• публикуемые веб-сервисы;
• параметры стандартного интерфейса OData;
• настройки аутентификации и другие параметры публикации.

Файл default.vrd должен читаться учетной записью, от имени которой работает веб-сервер или его пул приложений. При этом каталог публикации не следует открывать на запись широким группам пользователей.

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

Редактировать default.vrd вручную следует только при понимании его структуры и после создания резервной копии. Ошибка в XML или параметрах подключения может привести к недоступности веб-клиента, HTTP-сервисов, OData и внешних интеграций.

Подготовка перед публикацией

Перед публикацией базы 1С через веб-сервер нужно проверить не только саму информационную базу, но и окружение сервера.

Что проверить заранее

• установлен ли поддерживаемый веб-сервер;
• установлены ли нужные компоненты платформы 1С;
• совпадает ли версия веб-расширения с версией платформы;
• доступен ли сервер 1С с веб-сервера;
• открыты ли нужные сетевые порты;
• есть ли права на каталог публикации;
• понятно ли, под какой учетной записью работает веб-сервер;
• подготовлено ли стабильное DNS-имя, соответствующее сертификату и схеме доступа;
• есть ли SSL-сертификат для HTTPS;
• понятно ли, кто и как будет администрировать публикацию.

Если база клиент-серверная, веб-сервер должен иметь возможность подключиться к серверу 1С. Если база файловая, дополнительно возникают требования к доступу веб-сервера к каталогу файловой базы, но для рабочих серверных внедрений обычно предпочтительнее клиент-серверный вариант.

Публикация через конфигуратор

Один из распространенных способов — публикация из конфигуратора. Этот вариант удобен для первичной настройки и небольших инфраструктур.

Общий порядок

1. Откройте базу в конфигураторе.
2. Перейдите в раздел публикации на веб-сервере.
3. Выберите веб-сервер.
4. Укажите имя публикации.
5. Укажите физический каталог публикации.
6. Выберите, что нужно опубликовать: веб-клиент, HTTP-сервисы, веб-сервисы, OData.
7. Проверьте параметры подключения.
8. Выполните публикацию.
9. Проверьте открытие опубликованной базы в браузере.

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

Публикация через webinst

Для автоматизации и повторяемого развертывания можно использовать консольную утилиту webinst, входящую в состав платформы 1С. Набор параметров зависит от версии платформы, операционной системы, веб-сервера, варианта информационной базы и публикуемых возможностей.

Упрощенная структура команды может выглядеть так:

webinst -publish ^
  -wsdir "<имя_публикации>" ^
  -dir "<каталог_публикации>" ^
  -connstr "<строка_подключения>" ^
  <параметры_веб-сервера>

Настройка HTTPS и SSL-сертификата

Публиковать 1С через обычный HTTP в рабочей среде не рекомендуется. Даже если сервер используется только для веб-клиента, через соединение могут передаваться учетные данные и рабочая информация.

Для внешнего доступа лучше использовать HTTPS и действующий SSL-сертификат.

Что нужно для HTTPS

• стабильное DNS-имя сервиса, например 1c.example.ru;
• SSL-сертификат, в котором присутствует это имя;
• корректная DNS-запись во внутренней и внешней сети, если используется раздельный DNS;
• привязка сертификата в IIS, Apache или на reverse proxy;
• полная цепочка доверия;
• контроль срока действия и порядок перевыпуска сертификата.

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

Безопасность веб-публикации

Публикация базы 1С во внешнюю сеть увеличивает поверхность атаки. Поэтому веб-доступ нужно проектировать осторожно.

Рекомендуем

• разделять внешний reverse proxy и внутренний сервер приложений при повышенных требованиях к безопасности;
• не использовать административную учетную запись 1С для веб-клиента или интеграции;
• создавать отдельные публикации и учетные записи для внешних сервисов;
• ограничивать методы и данные, доступные через OData и HTTP-сервисы;
• настраивать лимиты размера запросов и тайм-ауты осознанно, а не отключать ограничения полностью;
• контролировать попытки перебора паролей и аномальное число запросов;
• удалять неиспользуемые и тестовые публикации;
• регулярно проверять срок действия сертификата и корректность его замены.

Если веб-сервер размещен на отдельном Linux VPS или используется внешний reverse proxy, полезно также продумать защиту самого сервера от перебора паролей, вредоносных файлов и автоматических атак.

Что не стоит делать

• публиковать административные интерфейсы без ограничений;
• оставлять доступ по HTTP без HTTPS;
• открывать серверные порты 1С и СУБД в интернет;
• использовать простые пароли пользователей;
• публиковать лишние HTTP-сервисы;
• оставлять тестовые публикации на рабочем сервере;
• давать веб-серверу избыточные права на каталоги и базу.

Для внешнего доступа лучше использовать отдельное доменное имя, HTTPS, ограничение по IP при возможности, VPN или reverse proxy, а также регулярный контроль журналов веб-сервера и 1С.

Типичные ошибки при публикации 1С

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

Диагностика публикации

Диагностику лучше выполнять последовательно: сначала проверить сеть и веб-сервер, затем публикацию 1С, после этого — права, логи и работу самой информационной базы.

Проверка сетевой доступности

Test-NetConnection example.ru -Port 443

Если используется внутренний сервер:

Test-NetConnection WEB01 -Port 443

Проверка доступности кластера 1С с веб-сервера

Если веб-сервер и кластер 1С находятся на разных узлах, недостаточно проверить только один порт. Нужно учитывать порты агента, менеджера кластера и диапазон, назначенный рабочим процессам.

Test-NetConnection SERVER1C -Port 1540
Test-NetConnection SERVER1C -Port 1541
Test-NetConnection SERVER1C -Port 1560

Проверка одного порта из диапазона не подтверждает доступность всех рабочих процессов. Фактический диапазон нужно сверить с настройками рабочего сервера кластера и правилами межсетевого экрана.

Что смотреть в журналах

• журналы IIS или Apache;
• журнал событий Windows;
• журнал регистрации 1С;
• технологический журнал 1С, если он включен;
• логи reverse proxy, если используется Nginx или другой прокси.

Что проверить в IIS

• запущен ли сайт и нужный пул приложений;
• под какой учетной записью работает пул;
• есть ли у нее право чтения каталога публикации и default.vrd;
• совпадает ли разрядность пула и установленного расширения 1С;
• какой физический путь назначен приложению;
• правильно ли настроены привязки HTTP/HTTPS;
• не осталась ли ссылка на каталог старой версии платформы;
• есть ли ошибки в журнале IIS и Event Viewer.

Get-Service W3SVC
Import-Module WebAdministration
Get-WebAppPoolState
Get-Website

Командлеты Get-WebAppPoolState и Get-Website доступны через модуль WebAdministration. Если модуль или командлеты отсутствуют, нужно проверить установку компонентов управления IIS.

Практический чек-лист

• Определено, зачем нужна публикация: веб-клиент, HTTP-сервисы, веб-сервисы, OData или интеграция.
• Выбран подходящий веб-сервер: IIS, Apache или связка с reverse proxy.
• Установлены нужные компоненты платформы 1С и веб-расширения.
• Проверено соответствие версии платформы информационной базы и расширения, подключенного в IIS или Apache.
• Создан каталог публикации.
• Проверены права учетной записи веб-сервера.
• Создан файл default.vrd, проверены его параметры, права чтения и защищенная резервная копия.
• Настроен HTTPS и установлен корректный SSL-сертификат.
• Во внешнем периметре открыт только необходимый HTTPS-доступ, обычно порт 443.
• Между веб-сервером, кластером 1С и СУБД разрешены только необходимые внутренние соединения с учетом фактических настроек кластера.
• Порты кластера 1С и СУБД не опубликованы напрямую в интернет.
• Проверена работа веб-клиента или HTTP-сервисов.
• Проверены журналы веб-сервера и 1С.
• Команды публикации и параметры сохранены для восстановления.

Заключение

Публикация базы 1С на веб-сервере — это не только создание ссылки для браузера. Это настройка взаимодействия между пользователем, веб-сервером, расширением 1С, сервером 1С и СУБД.

Чтобы публикация работала стабильно и безопасно, нужно понимать назначение каждого элемента: виртуального каталога, default.vrd, веб-расширения, HTTPS, прав учетной записи и сетевых портов. Особенно внимательно следует относиться к публикациям, которые доступны из интернета или используются внешними интеграциями.

Правильный подход — сначала определить сценарий доступа, затем подготовить веб-сервер, настроить публикацию, включить HTTPS, проверить права и только после этого передавать ссылку пользователям или внешним системам.

Что почитать дальше

Если вы настраиваете веб-доступ, серверную инфраструктуру или интеграции 1С, полезно также посмотреть связанные материалы:

• Сетевые порты сервера 1С — какие соединения нужны между клиентами, кластером, веб-сервером и СУБД.
• Серверная инфраструктура 1С — как спроектировать сервер 1С, СУБД, резервное копирование и мониторинг.
• Как обновить платформу 1С на сервере — что проверить в публикациях и расширениях после обновления.
• Сервер лицензирования 1С — диагностика ошибок получения лицензий в серверной среде.
• Как выбрать SSL-сертификат — уровни проверки, домены, Wildcard и организация перевыпуска.

Когда стоит обратиться к специалистам

Тестовую публикацию во внутренней сети можно настроить самостоятельно. Но внешний веб-доступ затрагивает сразу несколько компонентов: платформу 1С, IIS или Apache, DNS, сертификаты, reverse proxy, сетевые правила, учетные записи и безопасность опубликованных сервисов.

IPWAY помогает с поддержкой и сопровождением 1С, настройкой веб-публикаций, интеграций и серверной инфраструктуры. Для размещения базы в подготовленной среде также доступна аренда сервера с лицензиями 1С.

Кратко

• Штатная веб-публикация 1С выполняется через IIS или Apache; Nginx обычно используют как reverse proxy.
• При публикации создаются виртуальное приложение, каталог, расширение веб-сервера и файл default.vrd.
• Версия расширения веб-сервера должна соответствовать используемой платформе 1С.
• Для клиент-серверной базы нужно учитывать не только порты 1540 и 1541, но и диапазон рабочих процессов кластера.
• Во внешнем периметре пользователям нужен HTTPS, а порты кластера 1С и СУБД нельзя публиковать напрямую в интернет.
• HTTP-сервисы, веб-сервисы и OData следует публиковать с отдельными учетными записями и минимально необходимыми правами.
• После обновления платформы нужно проверить путь к расширению IIS/Apache и работоспособность публикации.
• Перед изменением настроек стоит сохранить default.vrd, параметры публикации и конфигурацию веб-сервера.