← На главную

В современных корпоративных сетях безопасность играет ключевую роль. Часто все компьютеры организации работают исключительно через прокси-сервер, а прямой доступ в интернет для них заблокирован. В таких условиях подключение онлайн-кассы (ККТ) для отправки чеков оператору фискальных данных (ОФД) превращается в сложную задачу. Обычные настройки прокси-сервера в браузере или операционной системе не помогают, и чеки зависают в памяти ККТ.

В этой статье мы подробно разберем, почему возникает эта проблема на примере кассы Вики Принт 57 Ф (работающей с Дримкас ОФД), и рассмотрим несколько эффективных способов настройки сетевого окружения совместно с системными администраторами.

Почему онлайн-касса не работает через стандартный прокси?

Для начала проанализируем архитектуру работы ККТ. Кассовые аппараты семейства «Вики Принт» подключаются к компьютеру по интерфейсу USB или RS-232 и эмулируют виртуальный COM-порт (VCOM). Передачу данных в ОФД осуществляет специальная фоновая служба на ПК — ComProxy.exe или VikiDriver.exe. Эта служба забирает данные из порта кассы и отправляет их в сеть.

Основная сложность заключается в следующем:

1. Службы ККТ используют для передачи данных протокол raw TCP (прямое сокетное соединение) на специфические порты ОФД (например, порт 21101 для Дримкас ОФД или порты 7777, 7778 для других операторов).
2. Классический прокси-сервер (HTTP/HTTPS) предназначен для работы с веб-трафиком и по умолчанию блокирует любые нестандартные TCP-соединения.
3. Службы ККТ работают в контексте системных учетных записей Windows (часто под учетной записью Local System). Они не имеют доступа к настройкам прокси, которые администратор прописал для конкретного пользователя в системе.

Посмотрим на типичную ошибку при попытке продиагностировать соединение с помощью утилиты командной строки:

telnet ofd.dreamkas.ru 21101

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

Почему не помогает добавление доменного имени ОФД в исключения?

Часто системные администраторы рапортуют, что добавили адрес ОФД (например, ofd.dreamkas.ru) в список исключений прокси-сервера, но чеки все равно не уходят. Выясним причину этой проблемы.

Когда служба ККТ пытается инициировать соединение с доменом ofd.dreamkas.ru, операционная система компьютера должна сначала преобразовать это имя в IP-адрес через службу DNS. В сетях с жесткой фильтрацией трафика через прокси-сервер доступ к внешним DNS-серверам (UDP-порт 53) для рабочих станций обычно закрыт. Компьютер просто не может разрешить доменное имя в IP-адрес, из-за чего попытка соединения обрывается еще до того, как пакет дойдет до прокси-сервера.

Решение 1. Использование прямого внешнего IP-адреса ОФД в исключениях файрвола (Рекомендуемый способ)

Это наиболее простое и надежное решение, которое полностью исключает проблемы с DNS. Мы должны настроить отправку данных напрямую по IP-адресу в обход прокси-сервера (через NAT на сетевом шлюзе).

Разберем этот способ по шагам:

1. Определяем IP-адрес ОФД. Для этого на компьютере с прямым доступом в интернет выполним команду ping или nslookup: nslookup ofd.dreamkas.ru Получаем внешний IP-адрес сервера (для Дримкас ОФД это может быть адрес 185.241.176.4).
2. Прописываем IP-адрес в ККТ. Запускаем сервисную утилиту для работы с кассой (для Вики Принт это утилита Fito). Переходим в раздел настроек сети ОФД и вместо доменного имени ofd.dreamkas.ru указываем напрямую IP-адрес 185.241.176.4. Порт оставляем без изменений — 21101. Поскольку DNS-запросы больше не понадобятся, в поле DNS-сервера кассы можно прописать нули 0.0.0.0.
3. Настраиваем правила на сетевом шлюзе/файрволе. Просим системного администратора создать правило исключения (bypass/NAT) на пограничном маршрутизаторе. Правило должно разрешать компьютеру с кассой исходящие TCP-соединения на целевой IP-адрес 185.241.176.4 по порту 21101 напрямую в интернет, минуя прокси-сервер.

После применения этих настроек служба ККТ будет отправлять пакеты сразу на шлюз, который перенаправит их на сервер ОФД без участия прокси. Проверить это можно повторным запуском утилиты telnet уже по IP-адресу:

telnet 185.241.176.4 21101

Если экран очистился или появилось приглашение к вводу — соединение успешно установлено, и чеки начнут уходить в ОФД.

Решение 2. Проброс портов на прокси-сервере

Если служба безопасности категорически запрещает выпускать компьютер в интернет напрямую (даже на один конкретный IP-адрес), можно организовать проброс портов (Port Forwarding) силами самого прокси-сервера.

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

1. В настройках кассы через утилиту Fito в качестве сервера ОФД указывается локальный IP-адрес прокси-сервера (шлюза организации в локальной сети), а порт устанавливается стандартный для вашего ОФД (например, 21101).
2. На самом прокси-сервере создается трансляционное правило: все входящие пакеты, приходящие из локальной сети на порт 21101, автоматически пересылаются (пробрасываются) наружу на реальный адрес ОФД 185.241.176.4:21101.
3. Обратный трафик от ОФД возвращается по той же цепочке. Для кассы это выглядит так, будто она общается напрямую с сервером ОФД, хотя фактически роль посредника выполняет прокси.

Решение 3. Использование программ-проксификаторов (Proxifier, ProxyCap)

В случаях, когда у системных администраторов нет возможности менять глобальные правила маршрутизации, можно решить проблему локально на компьютере с ККТ при помощи специализированного софта.

Рассмотрим, как настроить работу через утилиту Proxifier:

1. Устанавливаем Proxifier на рабочий компьютер, где подключена касса.
2. В настройках программы (раздел Proxy Servers) указываем параметры вашего корпоративного прокси-сервера (IP-адрес, порт, при необходимости логин и пароль для авторизации).
3. Создаем правило перенаправления трафика (раздел Proxification Rules). Нам нужно перехватывать пакеты конкретной службы ККТ.
4. В поле Applications добавляем исполняемый файл транспортного модуля кассы (например, VikiDriver.exe или ComProxy.exe).
5. В поле Action выбираем созданное ранее подключение к прокси-серверу.

Proxifier будет перехватывать raw TCP трафик от службы ККТ «на лету», упаковывать его в поддерживаемый вашим прокси-сервером формат (например, HTTPS-туннель или SOCKS) и передавать во внешнюю сеть.

Разница в сетевом поведении ККТ: VCOM против RNDIS

При настройке сетевого доступа важно понимать разницу между типами подключения ККТ к компьютеру. Различные производители используют разные технологии:

• Интерфейс VCOM (Вики Принт 57 Ф, АТОЛ по умолчанию). Касса видится системой как COM-порт. Трафик генерируется службой Windows, запущенной на самом ПК. С точки зрения сети этот трафик ничем не отличается от трафика любой другой программы на этом компьютере. Настроить его проще всего через локальный проксификатор или NAT на шлюзе.
• Интерфейс RNDIS (Штрих-М, некоторые модели АТОЛ). При подключении по USB ККТ определяется операционной системой как виртуальная сетевая карта (сетевой адаптер) со своим IP-адресом (например, 192.168.137.x). В этом случае касса выступает как самостоятельное сетевое устройство. Чтобы выпустить её в интернет через ПК, администраторам приходится настраивать общий доступ к подключению к интернету (Internet Connection Sharing — ICS) или прописывать статические маршруты в операционной системе, что значительно усложняет администрирование в закрытых сетях.

Проанализировав все варианты, мы видим, что наиболее стабильным и простым в поддержке решением для касс «Вики Принт» является Решение 1 (использование статического IP-адреса ОФД в обход прокси через правила NAT на шлюзе). Оно избавляет систему от зависимости от DNS-серверов и позволяет передавать фискальные данные без задержек и сбоев.