В практике системного администрирования часто встречается следующая архитектурная схема: сервер терминалов (назовем его term) выступает в роли своеобразного буфера безопасности. Он оснащен двумя сетевыми интерфейсами. Первая сетевая карта подключена к общей локальной сети компании (например, подсеть 192.168.1.0/24), а вторая соединена напрямую коротким патч-кордом или через отдельный коммутатор с изолированным сервером 1С:Предприятие (назовем его SERV, подсеть 192.168.0.0/24).
Пользователи успешно работают в терминальном режиме, запуская клиент 1С непосредственно на сервере term. Однако со временем возникает логичная задача: как организовать прямое подключение толстого или тонкого клиента с локального компьютера пользователя (например, с адресом 192.168.1.150) напрямую к серверу 1С SERV (192.168.0.2), минуя запуск удаленного рабочего стола?
Простая попытка пробросить порты 1540 и 1541 на сервере терминалов обычно ни к чему не приводит. В этой статье мы детально разберем внутренние механизмы работы платформы 1С:Предприятие, выясним причины неудач при стандартном пробросе и рассмотрим два рабочих и проверенных на практике способа решения этой задачи.
Чтобы понять суть проблемы, проанализируем, как именно происходит сеанс связи между клиентским приложением 1С и кластером серверов. Этот процесс состоит из нескольких последовательных шагов:
ragent, стандартный порт 1540) или напрямую к менеджеру кластера (rmngr, стандартный порт 1541) по IP-адресу или сетевому имени.rphost) будет обслуживать данное подключение.rphost динамически занимает порт из диапазона 1560-1591 (по умолчанию).SERV:1560).SERV в IP-адрес и подключиться к нему напрямую по порту 1560.Если на компьютере пользователя имя SERV не сопоставлено с доступным IP-адресом или если между вашей локальной рабочей станцией и сервером 1С отсутствует маршрутизация для пакетов, клиент выдаст ошибку сетевого доступа. Простой проброс двух портов на сервере терминалов не решает проблему динамических портов рабочих процессов и передачи имен хостов.
Ниже мы подробно разберем два альтернативных пути решения: создание полноценной маршрутизации между подсетями и организацию контролируемого транслирования портов (Port Forwarding) в связке с подменой имен.
---
Этот вариант является наиболее прозрачным и правильным с точки зрения сетевой архитектуры. Мы превратим наш сервер терминалов term в программный роутер, который будет пересылать пакеты между интерфейсами 192.168.1.10 и 192.168.0.1.
Шаг 1. Включение маршрутизации на сервере терминалов term
По умолчанию операционные системы семейства Windows Server не пересылают пакеты между разными сетевыми картами. Нам необходимо активировать функцию IP-маршрутизации (IP Routing). Сделать это можно двумя путями:
Для быстрой настройки воспользуемся изменением системного реестра. Откроем редактор реестра и перейдем по следующему пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Найдем параметр с именем IPEnableRouter (тип REG_DWORD) и изменим его значение с 0 на 1. Чтобы изменения вступили в силу, необходимо перезагрузить сервер терминалов.
Если вы предпочитаете использовать стандартные графические оснастки Windows Server, установите через диспетчер серверов роль Routing and Remote Access Services (RRAS) (Маршрутизация и удаленный доступ) и запустите ее в режиме локальной маршрутизации (LAN routing).
Шаг 2. Настройка статического маршрута на компьютере клиента
Теперь компьютер пользователя должен узнать, что подсеть 192.168.0.0/24 доступна через шлюз в виде сервера терминалов. Для этого на рабочей станции запустим командную строку с правами администратора и выполним команду добавления постоянного статического маршрута:
route -p add 192.168.0.0 mask 255.255.255.0 192.168.1.10
Параметр -p гарантирует, что созданный маршрут не исчезнет после перезагрузки операционной системы пользователя.
Шаг 3. Настройка обратного маршрута на сервере 1С (SERV)
Очень частая ошибка — забыть настроить обратный путь для сетевых пакетов. Сервер 1С, получив пакет от клиента 192.168.1.150, должен знать, куда отправлять ответ. Для этого у сервера 1С SERV (192.168.0.2) основным шлюзом (Default Gateway) в настройках сетевого адаптера должен быть указан IP-адрес сервера терминалов во второй подсети — 192.168.0.1.
Если по каким-то причинам менять основной шлюз на сервере 1С нельзя (например, там настроен другой выход в интернет), необходимо добавить статический маршрут в сеть клиента на самом сервере SERV:
route -p add 192.168.1.0 mask 255.255.255.0 192.168.0.1
Шаг 4. Настройка разрешения сетевых имен (DNS / Hosts)
Так как платформа 1С всегда ориентируется на буквенное имя сервера, нам необходимо научить компьютер клиента сопоставлять имя SERV с его реальным IP-адресом в изолированной сети (192.168.0.2). Для этого на компьютере клиента откроем файл hosts, расположенный по пути C:\Windows\System32\drivers\etc\hosts, и добавим в самый конец следующую строчку:
192.168.0.2 SERV
После этого проверим доступность сервера, выполнив команду ping SERV в командной строке клиента. Если пинг идет, можно запускать базу 1С, прописав в строке подключения адрес вида Srvr="SERV".
---
Если по соображениям безопасности или корпоративных регламентов вам категорически запрещено настраивать маршрутизацию пакетов между подсетями, мы можем применить технологию трансляции портов. В операционных системах Windows для этого предусмотрен встроенный механизм portproxy.
Сложность заключается в том, что по умолчанию кластер 1С использует под рабочие процессы более 30 портов (с 1560 по 1591). Пробрасывать их все вручную долго и неэффективно. Поэтому сначала оптимизируем настройки самого кластера 1С.
Шаг 1. Ограничение пула портов рабочих процессов 1С
Выполним предварительную настройку на стороне сервера 1С. Запустим консоль "Администрирование серверов 1С Предприятия":
SERV).1560-1591.1560-1562 (этого количества портов вполне достаточно для небольших и средних баз данных с малым количеством рабочих процессов).ragent) на сервере SERV.Шаг 2. Настройка трансляции портов на сервере терминалов term
Теперь на сервере терминалов term нам нужно перенаправить входящие запросы с внешней сетевой карты на внутренний сервер 1С. Запустим командную строку от имени администратора на сервере term и выполним серию команд:
netsh interface portproxy add v4tov4 listenport=1540 listenaddress=192.168.1.10 connectport=1540 connectaddress=192.168.0.2
netsh interface portproxy add v4tov4 listenport=1541 listenaddress=192.168.1.10 connectport=1541 connectaddress=192.168.0.2
netsh interface portproxy add v4tov4 listenport=1560 listenaddress=192.168.1.10 connectport=1560 connectaddress=192.168.0.2
netsh interface portproxy add v4tov4 listenport=1561 listenaddress=192.168.1.10 connectport=1561 connectaddress=192.168.0.2
netsh interface portproxy add v4tov4 listenport=1562 listenaddress=192.168.1.10 connectport=1562 connectaddress=192.168.0.2
Важное примечание: для корректной работы службы трансляции portproxy в Windows Server обязательно должна быть запущена служба "Вспомогательная служба IP" (iphlpsvc), а в настройках сетевых адаптеров должен быть активирован протокол IPv6 (даже если вы его не используете в своей локальной сети).
Шаг 3. Подмена адреса в файле hosts на стороне клиента
Здесь кроется ключевая хитрость данной схемы. Когда менеджер кластера передаст нашему локальному компьютеру имя SERV, клиентская машина должна отправить пакеты не напрямую в недоступную сеть 192.168.0.x, а на внешнюю сетевую карту сервера терминалов 192.168.1.10. Для этого откроем файл hosts на компьютере пользователя и свяжем имя сервера 1С с IP-адресом терминального сервера:
192.168.1.10 SERV
Давайте проанализируем, как теперь пойдет трафик:
SERV.hosts перенаправляет запрос на 192.168.1.10:1541.1541 и благодаря правилу portproxy пересылает его на реальный сервер 1С — 192.168.0.2:1541.SERV:1560. Файл hosts снова перенаправляет его на 192.168.1.10:1560.192.168.0.2:1560. Сводный мост построен, прямое подключение успешно установлено!---
Если после выполнения всех указанных настроек подключение все равно не устанавливается, рекомендуем выполнить последовательную проверку сетевых узлов:
Test-NetConnection -ComputerName SERV -Port 1541
Если значение TcpTestSucceeded возвращает True, значит, базовая сетевая доступность настроена правильно.
term и на сервере 1С SERV созданы разрешающие правила для входящих подключений по портам 1540, 1541, 1560-1591 для соответствующих сетевых профилей (Доменный/Частный). На время тестов брандмауэр можно временно отключить.hosts обязательно выполните команду сброса кэша сопоставления имен на клиентском компьютере:
ipconfig /flushdns
Мы детально рассмотрели два надежных сценария преодоления сетевого барьера между подсетями. Первый способ с маршрутизацией предпочтительнее для постоянного использования, так как не требует ручного вмешательства в настройки портов кластера при расширении инфраструктуры. Второй способ незаменим в условиях строгих политик безопасности, когда объединение подсетей запрещено на уровне регламентов компании.