← На главную

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

Анализ проблемы: как работает сетевой протокол кластера 1С

Чтобы понять причину ошибки, разберем двухэтапную архитектуру взаимодействия клиента и кластера серверов 1С:

1. Первичное обращение к менеджеру кластера: При старте клиент подключается к менеджеру кластера серверов (процесс rmngr), который по умолчанию работает на TCP-порту 1541 (агент сервера работает на порту 1540).
2. Назначение рабочего процесса: Менеджер кластера принимает запрос, определяет рабочий процесс (процесс rphost) и передает клиенту прямо внутри прикладного протокола сетевые реквизиты для дальнейшей работы — IP-адрес (или сетевое имя) сервера и конкретный динамический порт из диапазона 1560–1591.

Выясним причину сбоя при использовании обычного NAT (DNAT на роутере):

Если на сетевом маршрутизаторе настроить проброс внешнего порта (например, 50035) на порт 1541 внутреннего IP-адреса (например, 192.168.30.29), произойдет следующее:

1. Клиент успешно устанавливает первое TCP-соединение с менеджером кластера по внешнему IP.
2. Менеджер кластера 1С считывает собственный системный сетевой адрес (192.168.30.29) и номер выделенного рабочего процесса (например, 1560) и отправляет эти данные клиенту внутри прикладного пакета 1С.
3. Стандартный NAT на роутере подменяет IP-адреса только в сетевых заголовках (на сетевом уровне IP и транспортном уровне TCP), но не меняет содержимое прикладных данных 1С.
4. Получив от сервера ответ, клиент 1С пытается напрямую подключиться к полученному внутреннему IP-адресу 192.168.30.29 на порт 1560. Из внешней сети этот адрес недоступен, в результате чего клиент выдает ошибку тайм-аута подключения.

Решение 1. Организация VPN-соединения (Рекомендуемый способ)

Подключение через виртуальную частную сеть (VPN) является наиболее надежным, безопасным и простым в обслуживании решением. При использовании VPN удаленный компьютер клиента становится полноправным участником локальной сети (или изолированного сегмента сети с доступом к серверу 1С).

Преимущества использования VPN:

1. Клиент обращается к серверу 1С напрямую по его внутреннему IP-адресу или внутреннему DNS-имени, минуя проблемы с пробросом портов.
2. Работает весь спектр режимов платформы: Конфигуратор, тонкий клиент, толстый клиент, а также отладка.
3. Сетевой трафик полностью шифруется, что исключает перехват данных 1С при передаче через публичный интернет.
4. Нет необходимости открывать порты кластера 1С (1540-1591) в открытый интернет, что защищает инфраструктуру от внешних атак.

Решение 2. Настройка прямого NAT-подключения с использованием FQDN (Split-Brain DNS)

Если необходимо организовать прямое подключение тонкого клиента или Конфигуратора без VPN, стандартный проброс одного порта не сработает. Потребуется применить схему с использованием единого полного доменного имени (FQDN) и пробросом всего диапазона портов «порт-в-порт».

Разберем по шагам порядок настройки этой схемы:

1. Назначение доменного имени серверу: Присвоим серверу 1С сетевое имя в формате FQDN (например, 1c.company.com) на уровне операционной системы.
2. Настройка внешнего DNS: В публичной доменной зоне создадим A-запись, указывающую, что имя 1c.company.com ведет на внешний публичный («белый») IP-адрес вашего роутера.
3. Настройка локального DNS (Split-Brain DNS): Внутренний DNS-сервер компании (или файл /etc/hosts на самом сервере 1С) должен резолвить имя 1c.company.com во внутренний IP-адрес (192.168.30.29).
4. Проброс полного диапазона портов 1-в-1: На маршрутизаторе необходимо пробросить весь служебный диапазон портов без изменения их номеров:
   • 1540 TCP — агент серверов 1С;
   • 1541 TCP — менеджер кластера серверов;
   • 1560–1591 TCP — диапазон рабочих процессов (rphost).
5. Настройка клиентов: В строке подключения базы у удаленных пользователей указываем имя сервера 1c.company.com.

При такой схеме менеджер кластера будет возвращать клиенту имя 1c.company.com. Из внешней сети удаленный клиент успешно отрезолвит это имя во внешний IP-адрес роутера и подключится к выделенному рабочему процессу по открытому порту из диапазона 1560–1591.

Решение 3. Публикация базы данных на веб-сервере (Apache или IIS)

Для работы обычных пользователей в режиме тонкого клиента или через браузер оптимальным решением является публикация информационной базы на веб-сервере (Apache или Microsoft IIS).

В этом случае всё взаимодействие между клиентом и веб-сервером происходит по стандартным веб-протоколам HTTP/HTTPS (порты 80 и 443), а сам веб-сервер подключается к кластеру 1С внутри локальной сети.

Ограничения веб-сервера:

1. Невозможность работы в Конфигураторе: Запустить режим Конфигуратор через подключение по HTTP/HTTPS технически невозможно. Разработчикам и администраторам всё равно потребуется VPN или RDP/SSH доступ.
2. Оборудование: Торговое оборудование (торговые терминалы, кассовые аппараты, сканеры штрихкодов), требующее прямого драйверного подключения к локальным портам компьютера, может требовать дополнительной настройки при работе через веб-клиент.

Решение 4. Туннелирование портов через SSH (SSH Port Forwarding)

В операционных системах Linux (например, CentOS) для работы удаленных специалистов можно применить туннелирование TCP-портов через зашифрованное SSH-соединение.

Разберем пример создания локального туннеля для портов кластера 1С с помощью SSH-клиента на стороне удаленного пользователя:

ssh -L 1541:127.0.0.1:1541 -L 1560:127.0.0.1:1560 -N user@ext-ip.company.com

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

Сравнительный итог решений

Проанализировав варианты, выделим следующие рекомендации:

1. Для администраторов и разработчиков (работа в режиме Конфигуратора) следует использовать VPN или комбинацию FQDN + 1-in-1 NAT / SSH-туннель.
2. Для рядовых пользователей (работа в режиме тонкого клиента) лучше всего подходит публикация базы на веб-сервере (HTTP/HTTPS).