Как объединить локальное оборудование и облачный сервер 1С в сеть

Чтобы связать офисное оборудование — сканеры штрихкода, кассы, ТСД, принтеры чеков — с арендованным облачным сервером 1С, между офисом и дата-центром поднимают VPN-туннель или расширяют локальную сеть до уровня L2. Устройства продолжают работать по тем же IP и в той же логике, а сама база и сервер 1С физически стоят в облаке.

почему возникает разрыв между офисным оборудованием и облачным сервером 1С

На складе в 9:00 кладовщик сканирует накладную на приёмке — и ТСД вместо строки товара выдаёт «сервер недоступен». Неделю назад базу 1С перенесли на арендованный сервер, connection string в клиенте поправили, всё вроде работало на офисных компьютерах. Но сканер и касса продолжают стучаться в старый локальный IP 192.168.x.x, потому что их никто не переключал — да и переключать там особо нечего: они физически сидят в другой сети, а облачный сервер её не видит и не пускает к себе без явного маршрута.

Та же история — с принтерами этикеток, эквайринг-терминалами, видеонаблюдением, IP-телефонией. Всё, что раньше «видело» сервер напрямую через локальную сеть, после переезда в облако упирается в границу между офисом и интернетом. Пока эту границу не убрали явно — VPN-каналом или проброшенным сегментом сети, — часть оборудования просто не работает.

Цена простоя считается быстро: приёмка стоит — грузчики и экспедитор ждут, касса не пробивает чек — а это уже вопрос 54-ФЗ и потенциального штрафа, менеджер не может провести отгрузку — клиент звонит и переносит забор груза. Час простоя склада на 15-20 человек обычно дороже, чем разовая настройка сети.

что обычно рвётся при переезде в облако

• ✓сканеры штрихкода и ТСД на Wi-Fi — держат прописанный вручную IP сервера, а не DNS-имя;
• ✓кассы и фискальные регистраторы — интеграция с 1С идёт через локальный COM-порт или локальный IP, без понятия о NAT;
• ✓принтеры этикеток и чеков — часто настроены как сетевые устройства с фиксированным маршрутом до 1С;
• ✓эквайринг-терминалы — завязаны на локальный шлюз, который после переезда 1С уже не видит нужный сервер;
• ✓IP-телефония и видеонаблюдение — используют ту же локальную сеть, что и 1С, и падают вместе с ней, хотя формально к базе не относятся.

Из этого списка видно: проблема не в 1С и не в самом сервере, а в том, что часть оборудования настроена на конкретный внутренний адрес и не умеет искать сервер иначе.

как исправить: способы объединить сеть офиса и облака

Рабочих вариантов немного, и выбор зависит от того, сколько у вас устройств и насколько принципиально сохранить их прежние IP-адреса.

VPN site-to-site

Офисный роутер или отдельный шлюз поднимает IPsec- или WireGuard-туннель до сервера в дата-центре. Трафик между офисом и облаком шифруется и маршрутизируется как между двумя сегментами одной сети. Подходит для большинства сценариев: 1С, терминал-сервер, файловые ресурсы.

L2VPN и расширение VLAN

Более глубокий вариант — офисная сеть буквально «дотягивается» до дата-центра на уровне L2, и устройства сохраняют те же IP-адреса и настройки, что и до переезда. Не нужно перенастраивать сканеры, кассы и ТСД вручную — они просто не замечают, что сервер физически в другом месте. Такой канал разумно поднимать на выделенном сервере — на выделенном сервере в аренду провайдер настраивает сеть полностью под вас, включая VLAN и статическую маршрутизацию.

терминальный доступ вместо расширения сети

Если оборудования немного, сеть можно не трогать вовсе: пользователи заходят на облачный сервер через терминальную сессию (RDP), а локальные устройства — сканер, принтер чеков, ридер карт — пробрасываются в сессию через USB-редирект. Это самый быстрый способ запуститься, но не универсальный: не всё оборудование одинаково стабильно работает через редирект.

как понять, какой вариант подходит

Если оборудования немного и часть сотрудников и так работает удалённо — начните с обычного VPN site-to-site, это дешевле и быстрее в настройке. Если на складе десяток ТСД, кассы и вся логика завязана на локальные IP-адреса — берите L2VPN, чтобы не перепрошивать каждое устройство вручную. Если офис маленький и оборудования почти нет — терминальный доступ решает вопрос за один день, без изменений в сети вообще.

что делать, если соединение обрывается снова и снова

Туннель поднялся, оборудование ожило, а через два дня — снова «сервер недоступен». Обычно за этим стоит одна из четырёх причин.

Прежде чем менять настройки, стоит зафиксировать симптом: посмотреть, обрывается канал по расписанию (например, каждую ночь при смене IP) или случайно, проверить логи VPN-шлюза на обеих сторонах, прогнать ping и traceroute до сервера в момент сбоя. Без этого чинить можно долго и не то — переустанавливать VPN-клиент, вместо того чтобы поправить один параметр MTU.

Первая — динамический IP на офисном роутере: провайдер меняет внешний адрес, VPN-туннель падает, пока кто-то вручную не поднимет его заново. Решение — статический IP от провайдера или DDNS с автоматическим переподключением.

Вторая — проблема с MTU: пакеты внутри VPN-туннеля крупнее, чем пропускает канал, и фрагментируются или теряются, особенно на медленных линиях. Решение — включить MSS clamping на шлюзе и понизить MTU туннеля вручную.

Третья — нет резервного канала: единственный провод в офисе лёг, весь бизнес встал, пока не приедет техник. Решение — второй канал, хотя бы LTE-роутер как подстраховку.

Четвёртая — сервер и правда не успевает отвечать, а не сеть виновата. Прежде чем чинить туннель заново, стоит разделить причины: прогнать тест Гилёва и посмотреть, в чём узкое место — в канале связи или в производительности самого сервера. Если тест показывает низкую скорость независимо от сети, дело в ресурсах сервера, а не в VPN.

как предотвратить проблемы с сетью между офисом и облаком

Сеть между офисом и облаком, как и любая инфраструктура, требует не разовой настройки, а сопровождения. Что стоит сделать заранее, а не по факту аварии:

• ✓зафиксировать схему сети в документе — какие устройства, какие IP, какой туннель, кто отвечает за поддержку;
• ✓настроить мониторинг канала с уведомлением на телефон или почту при обрыве, а не ждать звонка от кладовщика;
• ✓держать резервный канал связи отдельно от основного провода;
• ✓проверять параметры сети по системным требованиям 1С — платформа чувствительна к задержке канала, и для терминальной работы 1С заявляет конкретные рекомендации по времени отклика;
• ✓если через канал идут персональные данные сотрудников или контрагентов из базы 1С, канал должен быть зашифрован — это прямое требование законодательства о защите персональных данных, а не формальность для галочки;
• ✓раз в квартал проверять канал под нагрузкой — не только «пингуется», а держит ли реальный трафик всех устройств одновременно.

Отдельно стоит прописать в договоре с провайдером сервера, кто отвечает за сеть: если сопровождение сети размыто между вашим сисадмином и хостером, при сбое чинить будут дольше — каждый решит, что чинит другая сторона.

как объединение офиса и облака устроено у ukved.ru

Мы настраиваем сеть как часть аренды сервера, а не продаём её отдельной непонятной услугой. При переносе базы на аренду сервера 1С инженер поднимает VPN-канал или L2VPN между офисом и дата-центром, прописывает маршруты и проверяет каждое устройство — сканеры, кассы, терминал-сервер — до того, как склад или магазин перейдут на новую схему в бою.

как проходит подключение

Сначала инженер смотрит, какое оборудование есть в офисе и как оно сейчас настроено — обычно это удалённая сессия и полчаса вопросов. Дальше поднимается канал, прописываются маршруты, и всё оборудование по очереди проверяется в тестовом режиме, до переключения основной работы на новую схему. На подключение обычной торговой точки или небольшого офиса такой процесс занимает 1-2 дня, для склада с десятком ТСД — до недели, с учётом тестирования под нагрузкой.

Для небольшой команды на 3-10 пользователей чаще хватает виртуального сервера для 1С с обычным VPN site-to-site — от 3300 руб/мес за сам сервер. Для склада с десятком ТСД, где важна статика IP и полный контроль над сетевым стеком, решение уже описано выше. Настройка сервера 1С под конкретное оборудование и дальнейшее сопровождение идут по тарифу сисадмина, 3800 руб/час, и обычно укладывается в 2-4 часа разовой работы плюс периодические проверки.

❓ Частые вопросы

Обязательно ли делать VPN, если 1С уже работает в облаке через обычный интернет?

Нет, если подключаются только компьютеры через тонкий или веб-клиент 1С — им хватает обычного защищённого соединения. VPN или L2VPN нужны, когда к серверу должно достучаться локальное оборудование со старыми настройками: сканеры, кассы, ТСД, принтеры чеков.

Сколько стоит настроить сеть между офисом и облачным сервером?

Сама настройка VPN или L2VPN обычно укладывается в 2-4 часа работы сисадмина по тарифу 3800 руб/час, плюс аренда сервера от 3300 руб/мес. Итоговая цена зависит от количества устройств и выбранного способа подключения.

Можно ли подключить к облачному серверу оборудование без перенастройки IP-адресов?

Да, через L2VPN — сеть офиса расширяется до дата-центра, и устройства сохраняют прежние адреса и настройки. Это удобнее, чем перепрошивать каждый сканер или кассу вручную, но требует более сложной сетевой настройки на обеих сторонах.

Почему после настройки VPN канал всё равно иногда обрывается?

Частые причины — динамический IP на офисном роутере, проблема с MTU внутри туннеля или отсутствие резервного канала связи. Обычно решается статическим IP или DDNS, настройкой MSS clamping и вторым каналом на случай обрыва основного.

На каком сервере лучше поднимать L2VPN — виртуальном или выделенном?

Для 3-10 пользователей и стандартного VPN обычно хватает виртуального сервера. Для склада с десятком ТСД и статичными IP-адресами разумнее выделенный сервер — там провайдер настраивает сетевой стек полностью под ваши задачи.