Как правильно организовать удаленный доступ к 1С: напрямую через VPN или через публикацию базы на веб-сервере?

← На главную

Организация качественного, быстрого и безопасного удаленного доступа к информационным базам 1С — одна из ключевых задач системного администратора. Традиционно на практике конкурируют два основных подхода. Первый — организация виртуальной частной сети (VPN) между офисом и удаленными точками с последующим прямым подключением тонкого клиента 1С к кластеру серверов по протоколу TCP. Второй — публикация информационной базы на веб-сервере (Apache или IIS) и подключение пользователей по протоколам HTTP/HTTPS.

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

---

Архитектура 1. Прямое TCP-подключение через VPN (Тонкий клиент -> Кластер 1С)

Рассмотрим схему, которую изначально развернул автор темы. Имеется сервер на базе операционной системы Debian, на котором развернуты СУБД Postgres Pro и сервер приложений 1С:Предприятие. Между центральным сервером и роутерами удаленных точек (магазинов) поднят туннель OpenVPN. Удаленные пользователи запускают стандартный тонкий клиент 1С и подключаются напрямую к кластеру серверов 1С по портам из диапазона 1560–1591.

Проанализируем ключевые особенности этой схемы:

Простота сетевой концепции: Для тонкого клиента удаленный компьютер выглядит так, будто он находится в одной локальной сети с сервером 1С. Нет необходимости настраивать дополнительные службы на сервере, такие как Apache или IIS.
Безопасность «из коробки»: Все данные внутри VPN-туннеля шифруются. Порты сервера 1С закрыты от внешнего мира и доступны только авторизованным в VPN устройствам.
Чувствительность к качеству канала: Это один из главных минусов схемы. Прямое TCP-соединение между тонким клиентом и процессом rphost сервера 1С крайне критично к задержкам (RTT) и потере пакетов. Если на удаленной точке кратковременно пропадет связь (даже на долю секунды, что часто бывает на 4G-модемах или нестабильной оптике), TCP-сессия разорвется. Пользователь получит аварийное завершение работы программы с потерей несохраненных данных в открытых формах документов.
Накладные расходы VPN-шифрования: Протокол OpenVPN накладывает дополнительный оверхед (заголовки пакетов, затраты процессора на шифрование). Если на стороне удаленной точки установлен слабый домашний роутер, при передаче больших объемов данных из 1С его процессор может загружаться на 100%, что искусственно снижает пропускную способность канала.
Проблемы с фрагментацией пакетов (MTU): Из-за инкапсуляции пакетов внутри VPN-канала эффективный размер пакета (MSS/MTU) уменьшается. Если сетевые параметры настроены неверно, пакеты будут фрагментироваться на роутере. Для тяжелых XML и JSON-структур, которыми обменивается тонкий клиент с сервером, фрагментация пакетов оборачивается критическим падением скорости отрисовки форм интерфейса.

---

Архитектура 2. Публикация базы на веб-сервере (Тонкий клиент -> HTTP/HTTPS -> Веб-сервер -> Кластер 1С)

Теперь рассмотрим альтернативный подход, предложенный представителем франчайзи. В этой схеме между тонким клиентом и сервером приложений 1С появляется промежуточное звено — веб-сервер (в случае операционной системы Debian это, как правило, Apache). Тонкий клиент общается с веб-сервером по протоколу HTTP или зашифрованному HTTPS, а веб-сервер передает запросы серверу приложений через специальный проприетарный модуль расширения 1С (wsap24.so для Apache 2.4).

Разберем, какие преимущества и особенности несет в себе эта архитектура:

Устойчивость к нестабильным каналам связи: В отличие от прямого TCP-подключения, HTTP-протокол по своей природе является транзакционным (запрос-ответ). Если происходит кратковременный микроразрыв связи или потеря пакетов, тонкий клиент по HTTP не закрывается аварийно. Он просто переведет интерфейс в состояние ожидания ответа, повторит запрос и продолжит работу, как только связь восстановится. Это критически важно для удаленных магазинов и складов, работающих на резервных каналах.
Оптимальное сжатие данных: При прямом TCP-подключении используется стандартное сжатие 1С (алгоритм SDC). При публикации на веб-сервере мы получаем возможность гибко управлять сжатием трафика с помощью стандартных и проверенных веб-технологий, таких как модуль mod_deflate или mod_gzip в Apache. Сжатие статического контента (картинок, шрифтов, макетов) и динамических данных на уровне веб-сервера снижает объем передаваемого трафика, что ускоряет работу интерфейса на медленных каналах (например, 50 Мбит/с на удаленной точке).
Отсутствие оверхеда VPN: Если опубликовать базу по HTTPS (с использованием бесплатного SSL-сертификата Let's Encrypt) и настроить ограничение доступа по IP-адресам на уровне веб-сервера или обратного прокси (Nginx), то необходимость в поддержке VPN-туннелей для удаленных рабочих мест отпадает. Это снижает нагрузку на роутеры удаленных точек и избавляет от проблем с MTU.
Простота развертывания новых рабочих мест: Администратору не нужно устанавливать и настраивать VPN-клиенты на новые компьютеры сотрудников, следить за генерацией ключей и сертификатов безопасности. Достаточно прописать адрес публикации базы в настройках списка баз тонкого клиента.

---

Скрытые нюансы: Лицензирование программных и аппаратных ключей

Важнейший аспект, который упускают из виду многие системные администраторы при переходе с одной схемы на другую — это механизм раздачи лицензий 1С.

Посмотрим на разницу в получении лицензий при разных типах подключения:

При прямом подключении по TCP:
Тонкий клиент может получать клиентскую лицензию тремя способами:

Локально (с USB-ключа HASP, установленного непосредственно в компьютер пользователя);
Из сети (через менеджер лицензий HASP License Manager, запущенный в локальной или VPN-сети);
От сервера приложений 1С (сервер сам выдает лицензию из своего пула программных или многопользовательских USB-ключей).

При подключении через веб-сервер:
Здесь действуют строгие правила платформы 1С:

Если пользователь запускает базу через веб-клиент (в браузере), локальные USB-ключи пользователя и HASP LM в его локальной сети использовать невозможно. Лицензии в этом случае может раздавать только сервер 1С. Веб-сервер запрашивает лицензию у кластера, и тот выделяет ее на сеанс.
Если пользователь запускает базу через тонкий клиент, подключенный по HTTP/HTTPS, то клиент может использовать локальный USB-ключ (если он физически вставлен в компьютер пользователя), но не сможет получить лицензию через сетевой HASP LM, если тот находится за пределами видимости веб-сервера. Однако наиболее стабильным и рекомендуемым вариантом также является раздача лицензий сервером приложений 1С.

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

---

Взгляд в будущее: Мобильные клиенты, интеграция и API

Даже если сейчас в компании работает всего 20 пользователей и схема с VPN полностью справляется, необходимо учитывать стратегию развития ИТ-инфраструктуры. Публикация базы на веб-сервере открывает двери для современных технологий, которые физически невозможно реализовать при прямом TCP-подключении:

Мобильные приложения и мобильный клиент: Для конфигурации «1С:Управление нашей фирмой» (УНФ) существуют готовые мобильные приложения для смартфонов и планшетов. Мобильный клиент осуществляет обмен данными исключительно по протоколам HTTP/HTTPS через веб-сервер. Настраивать VPN на телефонах курьеров, менеджеров по продажам или директора — крайне неудобная и трудноподдерживаемая задача. Публикация базы позволяет легко подключить мобильные устройства к рабочей базе.
Интеграция с внешними системами (API): Любая интеграция 1С с интернет-магазином, CRM-системой (например, amoCRM или Bitrix24), Telegram-ботами, сервисами доставки или маркетплейсами реализуется через HTTP-сервисы и Web-сервисы. Работа этих механизмов невозможна без настроенного веб-сервера.

---

Сравнительная таблица архитектурных подходов

Для наглядности сопоставим оба варианта организации удаленного доступа по ключевым параметрам:

Параметр сравнения	Прямое TCP-подключение через VPN	Подключение по HTTP/HTTPS через веб-сервер
Устойчивость к обрывам связи	Низкая. Любой микроразрыв рвет сессию 1С с потерей данных сеанса.	Высокая. HTTP-протокол устойчив к временным потерям пакетов, сессия сохраняется.
Требования к сетевому каналу	Критичны задержки (ping) и фрагментация пакетов (MTU).	Менее критичны задержки благодаря эффективному кэшированию и сжатию Gzip.
Нагрузка на клиентские роутеры	Высокая (шифрование трафика внутри VPN-клиента роутера).	Отсутствует (шифрование ложится на процессор ПК по SSL/TLS).
Поддержка мобильных устройств	Сложная (требуется разворачивать VPN-клиенты на смартфонах).	Простая и нативная (подключение мобильного клиента напрямую к веб-серверу).
Интеграция с сайтами и сервисами	Невозможна напрямую (требуется веб-сервер).	Доступна из коробки через HTTP/Web-сервисы публикации.

---

Пошаговый алгоритм развертывания веб-сервера Apache на Debian для 1С

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

Шаг 1. Установка веб-сервера Apache

Прежде всего, обновим список пакетов и установим Apache2 в нашей системе:


sudo apt update
sudo apt install apache2 -y

Шаг 2. Проверка наличия модулей расширения 1С

Для успешной публикации базы убедитесь, что при установке сервера 1С на Debian был установлен пакет расширения веб-сервера. Нам понадобится файл модуля wsap24.so. Обычно он находится по пути:

/opt/1cv8/x86_64/8.3.XX.YYYY/wsap24.so (где 8.3.XX.YYYY — версия вашей платформы 1С).

Шаг 3. Публикация информационной базы

Для публикации базы используется утилита автоматической настройки webinst, поставляемая вместе с платформой 1С. Рассмотрим пример команды публикации базы с именем "unf", расположенной на сервере приложений:


sudo /opt/1cv8/x86_64/8.3.22.1709/webinst -apache24 -wsdir unf -dir /var/www/unf -conn "Srvr=localhost;Ref=unf;" -confpath /etc/apache2/apache2.conf

Разберем параметры этой утилиты:

-apache24 — указываем версию веб-сервера (Apache 2.4).
-wsdir unf — имя виртуального каталога, который будет использоваться в URL-адресе для подключения к базе (например, http://имя_сервера/unf).
-dir /var/www/unf — физический каталог на сервере, где будет создан конфигурационный файл публикации default.vrd.
-conn "Srvr=localhost;Ref=unf;" — строка соединения с базой на сервере 1С.
-confpath /etc/apache2/apache2.conf — путь к основному конфигурационному файлу Apache.

Шаг 4. Настройка прав доступа

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

sudo chown -R www-data:www-data /var/www/unf

Шаг 5. Перезапуск службы Apache

Применим изменения, перезапустив службу веб-сервера:

sudo systemctl restart apache2

Теперь удаленные пользователи могут подключаться к базе, указав в тонком клиенте тип подключения "Веб-сервер" и адрес: http://<IP_или_домен_сервера>/unf.

---

Резюме: кто же был прав в споре?

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

Для небольшой компании с 20 пользователями, стабильным VPN-туннелем и отсутствием мобильных сотрудников текущая схема автора темы работоспособна и безопасна. Принцип «работает — не трожь» здесь вполне оправдан, так как любое внедрение нового звена (веб-сервера) требует времени на администрирование, генерацию SSL-сертификатов и тонкую настройку.

Однако представитель франчайзи абсолютно прав, глядя на перспективу развития бизнеса. Как только компания начнет масштабироваться, подключать новые удаленные точки со слабым интернетом, внедрять мобильные приложения для курьеров и менеджеров или связывать УНФ с сайтом компании, переход на веб-сервер (Apache/Nginx/IIS) станет единственно верным, стабильным и архитектурно правильным решением. Рекомендуем администратору заранее подготовить тестовый контур публикации базы, чтобы при росте нагрузок осуществить переход плавно и безболезненно для пользователей.