Почему при печати чека в 1С через RDP пропадает интернет и отключается локальная сеть?

Системный администратор 1С v7.7 Торговля и дистрибуция
← На главную

При работе в терминальном сеансе (RDP) с фискальными регистраторами, в частности марки Штрих-М, администраторы часто сталкиваются с парадоксальной ситуацией: в момент пробития чека на клиентском компьютере полностью пропадает сетевое соединение. Это приводит к разрыву RDP-сессии, а в некоторых случаях "зависанию" порта на коммутаторе, что требует физической перезагрузки сетевого оборудования. Проблема кажется мистической, так как обычная передача данных и "тяжелые" отчеты работают стабильно, а сбой происходит именно при обращении к кассовому аппарату.

Проанализируем ситуацию: большинство современных ККТ подключаются к компьютеру через USB-кабель, но работают в режиме эмуляции COM-порта. При этом для передачи данных в ОФД (Оператор Фискальных Данных) параллельно создается виртуальное сетевое соединение по технологии RNDIS (Remote Network Driver Interface Specification). Именно здесь кроется корень проблемы.

Выясняем причину конфликта: Windows, RNDIS и сетевой стек

Разберем по шагам, что происходит в системе в момент печати. Когда 1С 7.7 или 8.3 отправляет команду на пробитие чека через драйвер, операционная система активирует обмен данными с устройством. Если ККТ настроена на работу через RNDIS, она получает внутренний IP-адрес (по умолчанию в устройствах Штрих-М это 192.168.137.111).

Конфликт возникает из-за того, что обновления безопасности Windows (начиная с определенных пакетов 2021-2022 годов) некорректно обрабатывают службу общего доступа к интернету (ICS) и маршрутизацию между физическим сетевым адаптером и виртуальным адаптером кассы. В момент обращения к кассе служба SharedAccess может вызвать сбой сетевого стека, что операционная система интерпретирует как критическую ошибку и "схлопывает" все сетевые интерфейсы для предотвращения зацикливания трафика. В системных логах это часто отображается как ошибка: "dhcp-распределитель отключил себя по ip-адресу, поскольку адрес лежит вне области".

Решение №1: Откат и блокировка проблемных обновлений Windows

Проанализируем наиболее эффективный метод, который помог большинству пользователей. Если проблема появилась внезапно после плановой перезагрузки или ночного обновления системы, необходимо локализовать и устранить конфликтное обновление.

  1. Перейдем в Панель управления — Программы и компоненты — Просмотр установленных обновлений.
  2. Найдем последние установленные пакеты безопасности (KB) и удалим их (особенно те, что влияют на сетевой стек и безопасность ядра).
  3. После удаления обновлений крайне важно предотвратить их повторную установку, иначе при следующей загрузке ОС проблема вернется.

Рассмотрим правильный алгоритм блокировки обновлений через службы:

Решение №2: Обновление драйверов ККТ до актуальных версий

Если откат обновлений ОС невозможен по соображениям безопасности, проанализируем вариант обновления самого драйвера ККТ. В старых версиях драйверов (например, 4.14) механизмы работы с RNDIS менее стабильны. Рассмотрим переход на версии 4.15 или 5.17.

Драйверы Штрих-М обладают хорошей обратной совместимостью. Процедура перехода выглядит следующим образом:

  1. Удалим старую версию драйвера через установку/удаление программ.
  2. Установим новую версию (например, 5.17).
  3. В настройках драйвера проверим параметры связи. Для работы через RDP рекомендуется увеличить параметр Timeout (Таймаут) до 1000 или 2000 мс. Это позволит нивелировать задержки проброса порта через сеть.

Посмотрим на пример инициализации объекта драйвера в коде 1С 7.7, чтобы убедиться в правильности подключения компоненты:


// Пример инициализации драйвера в 1С 7.7
Попытка
    ЗагрузитьВнешнююКомпоненту("AddIn.DrvFR");
    Драйвер = СоздатьОбъект("AddIn.DrvFR");
    Сообщить("Драйвер успешно загружен");
Исключение
    Предупреждение("Не удалось загрузить драйвер ККТ!");
КонецПопытки;

Решение №3: Тонкая настройка сетевого адаптера RNDIS

Часто конфликт можно решить путем ручного вмешательства в настройки виртуального адаптера, который создает касса. Проанализируем следующие действия на клиентском компьютере:

  1. Зайдем в "Центр управления сетями и общим доступом" — "Изменение параметров адаптера".
  2. Найдем подключение, которое появляется при включении кассы (обычно называется "Remote NDIS...").
  3. Зайдем в его Свойства и отключим протокол IPv6.
  4. В свойствах IPv4 установим статический IP-адрес вручную: 192.168.137.1, маска 255.255.255.0. Это исключит попытки DHCP-сервера Windows выдать некорректные адреса.

Также важно отключить функции энергосбережения для USB-портов. В Диспетчере устройств найдем все пункты "Корневой USB-концентратор" и в их свойствах на вкладке "Управление электропитанием" снимем галочку "Разрешить отключение этого устройства для экономии энергии". Это предотвратит кратковременные разрывы связи при инициализации печати, которые в RDP-сессии воспринимаются критично.

Решение №4: Настройка проброса портов в RDP-клиенте

Выясним, как правильно пробрасывать устройство. В настройках RDP-подключения (mstsc.exe) на вкладке "Локальные ресурсы" в разделе "Локальные устройства и ресурсы" нужно нажать "Подробнее". Убедимся, что выбраны Порты.

Если используется современный драйвер Штрих-М, в нем может быть активен встроенный sock-прокси сервер. Важно: на стороне сервера (терминального сервера) установку такого прокси производить категорически не рекомендуется, так как это может привести к конфликту портов между разными пользователями терминала. Работайте напрямую через проброшенный COM-порт.

Резюме: Основной причиной "отвала" сети является конфликт обновлений Windows со службой ICS при использовании RNDIS адаптера кассы. Самым быстрым решением является удаление последних обновлений ОС и фиксация IP-адреса виртуального адаптера. Для долгосрочной стабильности рекомендуется переход на интерфейс связи Ethernet (если модель ККТ позволяет) или обновление драйверов до версии 5.17 с увеличением таймаутов ожидания.

← На главную