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

← На главную

При организации взаимодействия между базами данных 1С, находящимися в разных офисах или подсетях, системные администраторы и разработчики часто сталкиваются со специфической проблемой. VPN-туннель успешно поднят, серверы прекрасно «пингуют» друг друга по IP-адресу, но при попытке программного подключения (например, через COM-соединение или при запуске тонкого/толстого клиента) возникает ошибка соединения. Стандартная строка подключения, отлично работавшая внутри одной локальной сети, в условиях распределенной сети отказывается функционировать.

В этой статье мы подробно разберем, почему так происходит, изучим внутреннюю архитектуру взаимодействия платформы «1С:Предприятие» с сетью, пошагово настроим корректное разрешение имен и разберемся с правилами брандмауэра для беспрепятственной работы системы.

Почему прямое подключение по IP-адресу не работает?

Рассмотрим стандартную ситуацию. У нас есть строка подключения, в которой мы напрямую указываем IP-адрес сервера 1С в удаленной подсети:


Параметры = "Srvr=""192.168.10.3"";Ref=""UPP"";Usr=""Администратор"";Pwd=""СложныйПароль"";";

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

Клиентское приложение (или COM-соединение из другой базы) отправляет первоначальный запрос на порт менеджера кластера (по умолчанию это порт 1541) по указанному нами IP-адресу 192.168.10.3.
Менеджер кластера принимает запрос, авторизует пользователя и определяет, какой рабочий процесс (rphost) в данный момент наименее загружен и может обслужить этого клиента.
Критический момент: Менеджер кластера возвращает клиенту не IP-адрес, а сетевое имя (hostname) сервера 1С и порт выделенного рабочего процесса. Например, он говорит клиенту: «Переключись на рабочий процесс по адресу SRV-1C-MAIN:1562».
Клиентское приложение пытается разрешить имя SRV-1C-MAIN через локальную службу DNS. Поскольку клиент находится в другой подсети (за пределами локального домена сервера 1С), его DNS-сервер ничего не знает об имени SRV-1C-MAIN. Соединение аварийно разрывается с ошибкой «Хост не найден».

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

Шаг 1. Настройка разрешения имен через файл hosts или DNS

Самый простой и быстрый способ сопоставить имя удаленного сервера с его IP-адресом без глобальной перенастройки DNS-серверов в организации — это использование локального файла hosts на компьютере, с которого инициируется подключение. Если же требуется массово обновить параметры подключения к базам на рабочих станциях доменных пользователей, можно применить скрипт для автоматической замены имени сервера в файлах ibases.v8i через GPO.

Разберем этот процесс по шагам:

На компьютере-клиенте запустите текстовый редактор Блокнот (Notepad) от имени Администратора.
Откройте файл, расположенный по пути: C:\Windows\System32\drivers\etc\hosts.
В самый конец файла добавьте строку сопоставления IP-адреса и точного сетевого имени сервера 1С. Имя сервера должно полностью совпадать с тем, которое прописано в свойствах операционной системы сервера и отображается в консоли администрирования кластера 1С.

Пример записи в файле hosts:


# Сопоставление для подключения к удаленному серверу 1С через VPN
192.168.10.3    SRV-1C-MAIN

После сохранения файла обязательно измените строку подключения в вашем коде 1С. Вместо IP-адреса теперь следует использовать именно сетевое имя сервера:


Параметры = "Srvr=""SRV-1C-MAIN"";Ref=""UPP"";Usr=""Администратор"";Pwd=""СложныйПароль"";";

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

Шаг 2. Диагностика и открытие сетевых портов

Вторая распространенная проблема — блокировка трафика брандмауэром Windows или межсетевым экраном на VPN-роутере. Начинающие администраторы часто открывают только порт 1541, считая его единственным необходимым для работы 1С. Но это не так.

Для полноценной работы кластера 1С требуется открыть целый диапазон портов:

Порт 1540: Агент сервера 1С (ragent). Используется для администрирования.
Порт 1541: Главный менеджер кластера (rmngr). Принимает первичные запросы на подключение.
Диапазон портов 1560–1591: Рабочие процессы (rphost). Именно по этим портам передаются основные данные после авторизации.

Выясним, открыты ли порты на удаленном сервере. Для этого воспользуемся утилитой telnet из командной строки Windows на клиентском компьютере. Сначала выполним проверку порта менеджера:

telnet 192.168.10.3 1541

Если экран очистился или появился курсор — порт открыт. Если возникла ошибка подключения — порт заблокирован брандмауэром сервера или роутера.

Также обязательно проверьте доступность хотя бы нескольких портов из динамического диапазона рабочих процессов:


telnet 192.168.10.3 1560
telnet 192.168.10.3 1561

Если порты закрыты, необходимо зайти в настройки брандмауэра Windows (или аппаратного сетевого экрана вашей сети) на сервере и создать разрешающее правило для входящих подключений (Inbound Rules) для исполняемых файлов ragent.exe, rmngr.exe и rphost.exe, либо явно разрешить TCP-порты 1540-1541 и 1560-1591 для подсети, из которой происходит подключение.

Шаг 3. Устранение проблем с размером пакета (MTU) в VPN-каналах

Если вы прописали имена в hosts, открыли все порты, проверка через telnet проходит успешно, но при попытке получить данные из базы 1С система «зависает» или выдает ошибку о разрыве соединения — проблема кроется в сетевом параметре MTU (Maximum Transmission Unit).

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

В результате происходит фрагментация пакетов, которую многие современные роутеры блокируют в целях безопасности, либо пакеты просто отбрасываются. Мелкие пакеты утилиты ping при этом проходят без проблем.

Чтобы решить эту проблему, выполните следующие действия:

Настройте параметр MSS Clamping на вашем VPN-маршрутизаторе. Это заставит устройства автоматически уменьшать размер сегмента TCP-пакетов при прохождении через туннель.
Если доступа к роутеру нет, принудительно снизьте значение MTU на сетевых интерфейсах сервера и клиента до 1350 или 1400 байт. В Windows это можно сделать через командную строку от имени администратора:


netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Имя_Вашего_VPN_Подключения" mtu=1350 store=persistent

Особенности использования COM-соединения (V83.COMConnector)

Если подключение реализуется программно из кода одной базы к другой через COM-технологию:


Connector = Новый COMОбъект("V83.COMConnector");
Параметры = "Srvr=""SRV-1C-MAIN"";Ref=""UPP"";Usr=""Администратор"";Pwd=""Пароль"";";
Попытка
    БазаПриемник = Connector.Connect(Параметры);
Исключение
    Сообщить("Ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;

Помните, что COM-соединение работает поверх технологии Microsoft DCOM (RPC). Помимо портов самого кластера 1С, для работы DCOM требуются:

Порт 135 (RPC Endpoint Mapper).
Динамический диапазон портов RPC операционной системы Windows (по умолчанию в современных ОС это огромный диапазон 49152–65535).

Проброс такого количества портов через VPN крайне небезопасен. Если брандмауэр блокирует этот диапазон, COM-соединение работать не будет. В таком случае администраторы прибегают к ограничению динамического диапазона портов RPC через утилиту dcomcnfg (Службы компонентов) до нескольких конкретных портов и открывают только их.

Рекомендованная альтернатива: Переход на HTTP-сервисы

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

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

База-приемник публикуется на веб-сервере (IIS или Apache), который разворачивается непосредственно на стороне сервера 1С.
В базе-приемнике создается стандартный HTTP-сервис, который принимает запросы, выполняет необходимые действия и возвращает результат в формате JSON или XML.
База-источник отправляет обычные HTTP-запросы к веб-серверу.

Преимущества такого подхода очевидны:

Для работы требуется открыть всего один порт (стандартный 80 для HTTP или безопасный 443 для HTTPS).
Не нужно настраивать файлы hosts, открывать диапазоны портов кластера 1С (1560-1591) и мучаться с настройками DCOM.
HTTP-соединение гораздо более устойчиво к задержкам сети (ping) и временным обрывам связи. Оно работает в разы быстрее, так как передает сжатые структурированные данные, а не тяжелый служебный трафик платформы 1С.