ЕГАИС и УТМ на своём сервере: порты, сертификаты и типичные затыки

MAATRIX

Для владельца точки, которая продаёт алкоголь, УТМ — не абстрактная программа из инструкции, а сервис, от которого напрямую зависит, пробьётся чек или нет. Как и любой сетевой сервис с криптографией внутри, он живёт по своим правилам: у него есть порт, который нужно открыть, ключ электронной подписи со сроком действия, и версия, которая может не подружиться с очередным обновлением операционной системы. Разберём инфраструктурную часть работы с УТМ на уровне, полезном системному администратору или айтишнику небольшого бизнеса — без выдумывания конкретных цифр там, где нужна действующая документация.

Как УТМ вписывается в инфраструктуру торговой точки

УТМ (универсальный транспортный модуль) — это локальный программный компонент, который устанавливается на сервер или рабочую станцию продавца и выступает посредником между кассовым/учётным ПО и центральным сервером ЕГАИС. Технически это отдельная служба, которая с одной стороны отдаёт локальный API для кассовой или товароучётной системы (1С, специализированные решения для розницы), а с другой — держит защищённое соединение с внешним сервером ЕГАИС.

Схематично цепочка выглядит так:

Касса / товароучётная система
        │  (локальный запрос к УТМ, обычно на localhost или во внутренней сети)
        ▼
   УТМ (служба на сервере)
        │  (защищённое соединение через интернет)
        ▼
   Сервер ЕГАИС (внешняя система)

Важный нюанс: сам УТМ не хранит товароучётные данные — он транспортный слой. Но если он недоступен, зависает или работает нестабильно, кассовое ПО физически не может завершить операции с алкогольной продукцией, потому что не получает от УТМ подтверждения. С инфраструктурной точки зрения это значит, что УТМ — критичный по доступности сервис, даже если сам по себе он «маленькая программа», не требующая больших ресурсов.

Отсюда практический вывод: сервер, где крутится УТМ, нужно рассматривать так же, как любой другой критичный сервис — со своим планом резервирования и мониторингом. Разбор похожей логики применительно к розничной точке в целом есть в статье про продуктовый магазин и его зависимость от ЕГАИС и «Честного знака» — там больше про бизнес-последствия простоя, здесь — про саму техническую начинку.

Сеть: канал связи, порты и что реально нужно открыть

УТМ обменивается данными с сервером ЕГАИС по протоколу, для которого используется определённый порт — его точное значение нужно всегда сверять в актуальной документации на утм.egais.ru или в инструкции к конкретной версии модуля, потому что оно может отличаться между версиями и со временем меняться. Не полагайтесь на цифры «из памяти» или из старых форумных постов — при настройке firewall берите значение из официального источника на момент установки.

С точки зрения архитектуры сети на практике нужно обеспечить три вещи:

• Исходящее соединение с сервером ЕГАИС. УТМ инициирует соединение наружу сам, поэтому на периметровом firewall обычно достаточно разрешить исходящий трафик на нужный порт и адреса, указанные в документации, а не открывать входящие порты для внешнего мира.
• Локальный доступ от кассы/учётной системы к УТМ. Если касса и УТМ находятся на разных машинах в одной локальной сети, нужно открыть локальный порт (тоже смотрите в документации к конкретной версии) между кассовым ПО и хостом УТМ — обычно это делается через внутреннюю сеть без выхода в интернет.
• Стабильный и достаточно быстрый канал в интернет. УТМ не требует широкого канала — трафик там некрупный, — но требователен к стабильности: частые обрывы, скачки задержки или смена внешнего IP-адреса посреди сессии способны прерывать обмен с сервером ЕГАИС в самый неподходящий момент.

Практическая рекомендация для проверки, что порт действительно открыт и слушается локально:

# посмотреть, на каких портах слушает служба УТМ
ss -tlnp | grep -i utm

# проверить исходящее соединение до сервера ЕГАИС (адрес и порт — из актуальной документации)
nc -zv <адрес-сервера-егаис-из-документации> <порт-из-документации>

Если у вас единственный провайдер и единственный кабель в серверную, стоит спросить себя: что произойдёт, если провайдер уйдёт в аварию на четыре часа в субботу вечером. Резервный канал (второй провайдер или SIM с автопереключением) — не экзотика, а рядовая мера для точки, где простой в продаже алкоголя ощутимо бьёт по кассе. Про общую логику стабильности канала на серверах в России есть отдельный разбор в статье скорость и аптайм серверов в России.

Ключ электронной подписи и защищённый носитель

УТМ работает не просто как транспорт — каждая передаваемая транзакция подписывается электронной подписью, привязанной к организации. Ключ этой подписи по требованиям хранится не на диске сервера в виде файла, а на защищённом аппаратном носителе (токене), который физически подключается к серверу или рабочей станции через USB. Это принципиальный момент, отличающий инфраструктуру УТМ от обычного веб-сервиса: криптографическая операция привязана к железному устройству, а не только к программному сертификату.

С инфраструктурной стороны это порождает несколько следствий:

• Физическая доступность порта USB. На выделенном физическом сервере или мини-ПК в подсобке вопросов нет — токен воткнут напрямую. При переносе УТМ на арендованный VPS встаёт вопрос проброса USB-устройства к виртуальной машине (USB-passthrough, USB-over-IP или аналог) — решаемо, но требует отдельной настройки и не всегда поддерживается провайдером «из коробки». Уточняйте это у хостера до переноса.
• Криптопровайдер на сервере. Для работы с ключом на носителе обычно требуется установленное СКЗИ (например, КриптоПро CSP или аналогичное решение, поддерживаемое конкретной версией УТМ) — отдельный компонент со своей лицензией и требованиями к ОС.
• Срок действия ключа. У него есть срок действия, и истечение — предсказуемое событие, которое стоит отслеживать заранее, а не узнавать о нём постфактум от кассира.

Про то, как в принципе устроена электронная подпись и что в ней относится к технике, а что — к юридической стороне, есть отдельный обзорный материал: электронная подпись на своём сервере. Он не заменяет консультацию с оператором ЕГАИС или ФСРАР по конкретике требований к вашему носителю, но помогает понять общую логику.

Затык №1: истёк сертификат или лицензия на носителе ключа

Самый частый и при этом самый обидный сбой — истечение срока действия ключа или связанной с ним лицензии на носителе. Обидный, потому что это не случайность, а событие с известной заранее датой, которое просто забыли отследить. Типичная картина: всё работало месяцами, а в понедельник утром УТМ перестаёт принимать документы, и разбираться приходится уже в разгар рабочего дня.

Что стоит сделать на уровне инфраструктуры:

• Завести напоминание о сроке действия ключа заранее — не за день до истечения, а за несколько недель, чтобы хватило времени на продление через оператора электронной подписи без спешки.
• Хранить информацию о том, кто отвечает за продление — небольшие компании нередко теряют это знание при смене айтишника или бухгалтера, и подпись «протухает», потому что никто не считал это своей зоной ответственности.
• Проверять системное время на сервере. Неочевидная причина проблем с сертификатами — рассинхронизация часов: сервер может посчитать действующий сертификат просроченным или ещё не вступившим в силу, хотя формально он в порядке. Дешёвая профилактика:

# проверить текущее состояние синхронизации времени
timedatectl status

# если синхронизация отключена — включить NTP
timedatectl set-ntp true

Такая же логика — «сертификат истекает предсказуемо, но узнают об этом в последний момент» — регулярно встречается и вне контекста ЕГАИС, например с TLS-сертификатами на веб-серверах. Общие принципы, почему это происходит и как выстроить процесс, чтобы не зависеть от чьей-то памяти, разобраны в статье про мониторинг и алерты при падении сайта или сервиса — механика мониторинга сроков действия там применима и к ключу УТМ.

Затык №2: недоступность канала связи

Второй по частоте класс проблем — не сбой самого УТМ, а обрыв или деградация канала, по которому он общается с сервером ЕГАИС. С точки зрения кассы это выглядит одинаково что при падении УТМ, что при падении интернета: продажа маркированного алкоголя не проходит. Но причины и способы починки разные, и первое, что нужно уметь — быстро отличить одно от другого.

Чек-лист диагностики при подозрении на проблему с каналом:

1. Проверить, что служба УТМ запущена и не упала (systemctl status для соответствующей службы — конкретное имя зависит от способа установки на вашей системе).
2. Проверить локальную доступность УТМ с машины кассы (обращение на локальный адрес и порт из её конфигурации).
3. Проверить исходящую связность с сервером ЕГАИС отдельно от связности УТМ — обычным ping или traceroute до внешнего адреса, чтобы понять, проблема в канале провайдера или дальше.
4. Проверить, не сменился ли внешний IP-адрес сервера — если он привязан к конкретному статическому адресу от провайдера, а тот сменился из-за перезагрузки роутера, это тоже способно рвать сессию.

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

Затык №3: конфликт версий УТМ и ОС при обновлении

Третий типичный затык — менее очевидный, но регулярно встречающийся у тех, кто держит УТМ на сервере годами без пересмотра: очередное плановое обновление УТМ (или, наоборот, автоматическое обновление самой ОС) внезапно ломает совместимость. Формально это не вина ни УТМ, ни системы — просто конкретная связка версий не была протестирована производителем модуля с этим релизом ОС, особенно если система обновляется автоматически и без контроля со стороны администратора.

Механика обычно одна из двух: либо автообновление пакетов, ядра или системных библиотек меняет поведение компонентов, от которых зависит криптопровайдер или сама служба УТМ, и модуль либо не стартует, либо не может обратиться к ключу на носителе; либо, наоборот, новая версия УТМ требует более свежих библиотек или другого криптопровайдера, которого на сервере ещё нет, — и служба отказывается подниматься.

Меры, снижающие риск:

• Отключить неконтролируемые автообновления ОС на сервере с УТМ и переводить систему на новые версии осознанно, в отдельном окне обслуживания.
• Перед обновлением УТМ проверять актуальные требования к ОС и криптопровайдеру в документации к новой версии — производитель модуля обычно публикует список поддерживаемых систем.
• Иметь возможность откатиться. Снимок состояния сервера (снапшот ВМ или бэкап конфигурации) перед плановым обновлением превращает «сломали прод в рабочий день» в «откатились за пять минут».
• Тестировать обновление не сразу на боевом сервере, если это возможно — хотя бы на копии конфигурации, прежде чем катить изменения туда, откуда идут продажи.

Избежать этого риска на сто процентов нельзя — производитель УТМ выпускает обновления по своему графику. Но контролируемое, а не случайное обновление резко снижает вероятность, что затык случится именно в пятницу вечером.

Мониторинг, резервирование и выбор площадки

Три разобранных затыка объединяет одно: все они предсказуемы и обнаруживаются заранее, если есть систематический присмотр за сервером, а не разовая настройка «поставили и забыли». Минимальный набор для сервера с УТМ:

Отдельный вопрос — где физически держать этот сервер. Локальная машина в подсобке уязвима к скачкам напряжения и случайным отключениям электричества; при росте бизнеса или сети из нескольких точек логичнее переносить связующую инфраструктуру на выделенный сервер или VPS в дата-центре — с резервным питанием и штатом, который следит за железом. Для локальной интеграции с российскими государственными системами разумно держать такой сервер в России или в регионе с низкой задержкой до неё, а также заранее уточнить у провайдера вопрос проброса USB-носителя ключа — это не универсальная опция «из коробки» у всех хостеров.

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