Объединение двух офисов или предприятий — классическая задача для системного администратора. Однако на практике часто возникает серьезное препятствие: в обоих филиалах исторически используется одна и та же популярная подсеть (например, 192.168.1.0/24 или 192.168.0.0/24). Прямое объединение таких сетей через классический VPN-туннель невозможно, так как возникнет конфликт адресации, и устройства просто не смогут определить, находится ли целевой IP-адрес в локальном сегменте или за пределами маршрутизатора.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем различные варианты ее решения на сетевом уровне и рассмотрим наиболее элегантный архитектурный способ организации работы 1С в таких условиях без полной перенастройки инфраструктуры.
Рассмотрим стандартное поведение сетевого стека операционной системы. Когда компьютер А с адресом 192.168.1.50 пытается отправить пакет на сервер Б с адресом 192.168.1.10, операционная система первым делом накладывает маску подсети (например, 255.255.255.0) на целевой IP-адрес.
Поскольку адреса отправителя и получателя находятся в пределах одной и той же подсети 192.168.1.0/24, операционная система делает логический вывод: целевой хост находится в моей локальной физической сети. Вместо того чтобы отправить пакет на шлюз по умолчанию (роутер), компьютер А отправляет широковещательный ARP-запрос: «Кто имеет IP-адрес 192.168.1.10? Сообщите свой MAC-адрес». Разумеется, этот запрос никогда не уйдет во вторую сеть через VPN, и связь установить не удастся.
Для решения этой проблемы существует несколько подходов разной степени сложности и надежности. Проанализируем их пошагово.
Несмотря на то, что авторы темы на форуме изначально выразили нежелание менять адресацию из-за масштабов предприятий, это решение является единственным на 100% надежным в долгосрочной перспективе. Рано или поздно «костыли» с трансляцией адресов начнут мешать масштабированию сети, подключению удаленных пользователей или интеграции новых сервисов.
Разберем, как минимизировать простои при смене адресации на одном из предприятий:
172.16.25.0/24 или 10.100.1.0/24). Диапазон 192.168.1.x крайне не рекомендуется использовать в корпоративных средах из-за его повсеместного использования в домашних роутерах.Если изменить адресацию физически невозможно в краткие сроки, можно прибегнуть к технологии двустороннего отображения адресного пространства. В операционных системах Linux (iptables) и маршрутизаторах Mikrotik для этого используется механизм NETMAP.
Суть метода заключается в том, что для каждой из конфликтующих сетей выделяется виртуальная «сеть-синоним». Например:
192.168.1.0/24) будет представлена для Сети Б под виртуальным адресом 10.10.1.0/24.192.168.1.0/24) будет представлена для Сети А под виртуальным адресом 10.10.2.0/24.Когда компьютер из Сети А хочет обратиться к серверу 1С из Сети Б (реальный адрес которого 192.168.1.10), он должен отправлять пакеты на виртуальный адрес 10.10.2.10. Роутер на границе Сети А и Сети Б произведет двустороннюю трансляцию адресов источника и назначения.
Рассмотрим пример настройки правил iptables для реализации данной схемы (как предложено в сообщении №11):
# Трансляция входящих пакетов из туннеля (Destination NAT)
iptables -t nat -A PREROUTING -d 10.10.1.0/24 -i tun0 -j NETMAP --to 192.168.1.0/24
# Трансляция исходящих пакетов в туннель (Source NAT)
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o tun0 -j NETMAP --to 10.10.1.0/24
На маршрутизаторах Mikrotik аналогичная настройка выполняется в разделе /ip firewall nat через действие netmap:
/ip firewall nat
add chain=dstnat dst-address=10.10.1.0/24 action=netmap to-addresses=192.168.1.0/24
add chain=srcnat src-address=192.168.1.0/24 action=netmap to-addresses=10.10.1.0/24
Важное ограничение метода NETMAP: Маршрутизаторы будут подвергаться повышенной вычислительной нагрузке, так как им придется переписывать заголовки каждого проходящего пакета «на лету». Кроме того, это решение усложняет диагностику сети командами ping и traceroute.
Если пользователям второго предприятия требуется доступ исключительно к серверу 1С (или СУБД MS SQL / PostgreSQL), а полноценное объединение сетей не требуется, можно ограничиться точечным пробросом портов на шлюзе Сети Б.
Однако здесь мы сталкиваемся со спецификой работы платформы 1С:Предприятие 8. Кластер 1С использует динамическое распределение портов между рабочими процессами. По умолчанию используются следующие порты:
1540 — Агент сервера 1С:Предприятия.1541 — Главный менеджер кластера.1560-1591 — Диапазон портов рабочих процессов.Когда толстый клиент подключается к серверу, он сначала обращается к менеджеру кластера на порт 1541. Менеджер авторизует сессию и сообщает клиенту, к какому именно рабочему процессу (и на какой порт из диапазона 1560-1591) ему следует переподключиться. Более того, менеджер кластера передает клиенту IP-адрес или сетевое имя сервера в том виде, в каком сервер зарегистрирован внутри кластера.
Если сервер 1С в кластере зарегистрирован по локальному IP-адресу 192.168.1.10, то удаленный клиент из первой сети получит команду: «Подключись к рабочему процессу по адресу 192.168.1.10:1560». Клиент попытается установить соединение со своим локальным сегментом и получит ошибку.
Чтобы обойти это ограничение при использовании проброса портов или NETMAP, необходимо выполнить два условия:
srv-1c.enterprise.local.hosts или настройки корпоративного DNS-сервера.Для решения задачи, поставленной автором темы, существует максимально эффективное архитектурное решение, которое позволяет вообще избежать настройки сложных VPN-туннелей, NAT и манипуляций с маршрутизацией. Это публикация информационной базы 1С на веб-сервере.
Толстый клиент 1С (начиная с платформы 8.2) умеет полноценно работать с информационными базами через веб-сервер по протоколам HTTP и HTTPS. При этом вся логика работы толстого клиента сохраняется, но транспортным уровнем становится стандартный веб-трафик.
Рассмотрим по шагам процесс реализации этого решения:
Шаг 1. Подготовка веб-сервера.
На сервере, где установлен сервер 1С:Предприятия, необходимо развернуть веб-сервер. Для операционных систем Windows оптимальным выбором является встроенный Internet Information Services (IIS), для Linux — Apache HTTP Server. При установке IIS обязательно убедитесь, что включены компоненты совместимости с IIS 6 Metabase и модули расширения ISAPI.
Шаг 2. Публикация базы через Конфигуратор или утилиту webinst.
Запустите Конфигуратор 1С от имени администратора операционной системы. Перейдите в меню Администрирование — Публикация на веб-сервере. В открывшемся окне укажите имя публикации, выберите веб-сервер (например, IIS) и установите флажки для публикации тонкого и толстого клиента. Нажмите кнопку «Опубликовать».
Альтернативный вариант — использование консольной утилиты webinst, которая поставляется вместе с платформой. Пример команды для публикации:
webinst -apache24 -wsdir Base1C -dir "C:\inetpub\wwwroot\Base1C" -connstr "Srvr=\"srv-1c\";Ref=\"Base1C\";" -confPath "C:\Program Files\Apache24\conf\httpd.conf"
В результате публикации в целевом каталоге будет создан конфигурационный файл default.vrd. Рассмотрим пример его структуры для понимания принципа работы:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/Base1C"
ib="Srvr="srv-1c";Ref="Base1C";">
<ws>
<point name="WebServiceName" alias="ws1.1c" enable="true"/>
</ws>
<httpServices>
<service name="HTTPServiceName" rootUrl="api" enable="true"/>
</httpServices>
</point>
Шаг 3. Обеспечение безопасности (SSL/HTTPS).
Передача учетных данных и корпоративной информации в открытом виде по протоколу HTTP небезопасна. Необходимо настроить шифрование HTTPS. Для этого получите SSL-сертификат (можно использовать бесплатный Let's Encrypt или самоподписанный сертификат для внутренних нужд) и привяжите его к порту 443 вашего веб-сервера.
Шаг 4. Настройка доступа на роутере.
На маршрутизаторе Сети Б настройте проброс только одного порта — 443 (HTTPS) с внешнего интерфейса на локальный IP-адрес веб-сервера. Чтобы ограничить доступ посторонних лиц, в настройках брандмауэра роутера разрешите входящие подключения на этот порт только со статического внешнего IP-адреса Сети А.
Шаг 5. Подключение пользователей.
На компьютерах пользователей в Сети А запустите окно запуска 1С. Нажмите кнопку «Добавить», выберите вариант «Добавление в список существующей информационной базы». В окне настройки параметров укажите тип подключения: На веб-сервере. В поле адреса введите внешнюю ссылку:
https://ip-address-or-domain/Base1C
Где ip-address-or-domain — внешний белый IP-адрес роутера Сети Б (или соответствующее ему доменное имя).
Преимущества публикации на веб-сервере:
Для наглядности сравним все рассмотренные архитектурные подходы в таблице:
| Критерий сравнения | Смена адресации (DHCP) | Двойной NAT (NETMAP) | Проброс портов (DNAT) | Публикация на веб-сервере |
|---|---|---|---|---|
| Сложность внедрения | Высокая (требует разовых трудозатрат) | Средняя (требует гибких роутеров) | Низкая | Низкая / Средняя |
| Нагрузка на маршрутизатор | Отсутствует | Очень высокая | Низкая | Низкая |
| Совместимость с 1С | Идеальная | Могут быть проблемы с именами кластера | Требует настройки DNS/hosts для кластера | Идеальная (штатный режим работы) |
| Безопасность | Высокая (полное доверие внутри сети) | Средняя (требуется фильтрация трафика) | Низкая (порты СУБД/1С открыты наружу) | Высокая (шифрование SSL, ограничение по IP) |
| Масштабируемость | Отличная (навсегда решает проблему) | Плохая (каждая новая сеть усложнит схему) | Ограниченная | Отличная |
Проанализировав все возможные варианты интеграции, мы рекомендуем следующий план действий:
Если задача стоит «сделать быстро, чтобы заработало прямо сейчас» — настройте публикацию базы 1С на веб-сервере IIS/Apache с шифрованием SSL (Решение №4). Это избавит вас от сетевого хаоса, сбережет ресурсы роутеров и обеспечит стабильную работу пользователей толстого клиента без падения сессий.
Если в дальнейшем планируется глубокая интеграция ИТ-структур предприятий (общие файловые помойки, Active Directory, телефония, доменные службы) — запланируйте на выходные дни плановый переход одного из филиалов на другую подсеть (Решение №1). Попытки построить единую ИТ-инфраструктуру поверх "Twice NAT" в будущем приведут к огромным временным затратам на поиск и устранение трудновоспроизводимых сетевых ошибок.