Через 15 минут терминалы дебетовых / кредитных панелей отключаются от сети. Переподключиться после одной ошибки

У нас есть прокативная сеть HP и около 20 стандартных терминалов для дебетовых / кредитных панелей, которые сегодня привыкли видеть практически в каждом магазине. Они подключаются напрямую к локальной сети и общаются только с платежным сайтом по SSL / 443. Нет программного обеспечения или сервера в середине.

Проблема заключается в том, что устройства обычно дают сбой соединения TCP при первой попытке использования. Они будут работать нормально в течение часа подряд. Но если разрешить сидеть без дела в течение 10 - 15 минут (приблизительно), они выдадут первоначальную ошибку один раз.

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

Мы попробовали статическую IP-адресацию против DHCP. Мы добавили внешний платежный сайт в специальное правило брандмауэра, которое позволяет им выходить без обычных проверок угроз. Мы пробовали их на разных Vlans. Мы попытались связать их с различными типами областей коммутаторов. Даже попробовал запланированный пакетный файл, который пингует их (самодельный оставшийся в живых), каждые 3 минуты. Ничто не имеет значения. Что касается проблем с сетью, то все устройства подключены к тем же коммутаторам VLAN и областей, что и их близлежащие кассовые компьютеры / принтеры - и у нас нет проблем ни с чем другим. Кассовые системы работают с полными приложениями клиент / сервер / база данных, и если для них возникла та же проблема с отключением, потому что сеть в этом районе была плохой, мы бы услышали об этом быстро.

Последняя теория, которой я собираюсь заняться, связана с тайм-аутами arp-кэша, но я только начинаю.

Был бы признателен за помощь ... сумасшедшие идеи также приветствуются.

W.

Я видел подобную проблему в прошлом. Моя проблема была связана с тем, что мое устройство устанавливало соединение через устройство NAT, а затем это соединение слишком долго не использовалось (ничего не отправлено, ничего не получено). Оба конца соединения не имели понятия, но устройство NAT посередине решило закрыть соединение из-за неактивности. Затем, когда трафик пытался пройти через NAT, пакеты отбрасывались, потому что правило NAT больше не существовало.

Ваши устройства могут делать что-то подобное. Моим решением было использовать пакет поддержки активности между двумя устройствами. Он будет посылать пакет каждые 60 секунд, и это решило мою проблему (система работает уже несколько лет без необходимости прикасаться). Простое эхо-тестирование любого устройства из одной и той же локальной сети было недостаточно для поддержания правила NAT на месте. Устройства ДОЛЖНЫ регулярно общаться друг с другом.

Однако, не зная больше о ваших конкретных системах, трудно сказать, относится ли это к вам.

Надеюсь это поможет.

Проблема заключается в том, что устройства обычно дают сбой соединения TCP при первой попытке использования. Они будут работать нормально в течение часа подряд. Но если разрешить сидеть без дела в течение 10 - 15 минут (приблизительно), они выдадут первоначальную ошибку один раз.

Первое, что я бы порекомендовал, это получить копию руководства или поговорить с продавцом, чтобы получить точную информацию о том, что означает ошибка, создаваемая устройствами. Я потратил время на поиск проблем уровня 3/4, когда ошибка на самом деле означала что-то другое. Не все поставщики используют терминологию правильно или последовательно.

Похоже, что устройства не отправляют обработку или поддерживают корректную поддержку активности. Если по вашему TCP-соединению данные не пересекаются, оно в конечном итоге будет закрыто. Для предотвращения этого одна конечная точка (или обе) может отправлять пакеты keep-alive для предотвращения разрыва соединения. Я знаю, что это можно сделать с помощью протокола TCP (уровень 4), и, вероятно, это можно сделать также с помощью протокола SSL / TLS (уровень 7).

Поместите перехватчик пакетов между одним из этих устройств и вашей инфраструктурой и запишите весь его трафик с момента его работы до момента, когда он не работает. Затем просмотрите его и найдите, где устройство или сервер, к которому оно подключается, запускает последовательность завершения , а затем посмотрите, что непосредственно предшествует этому. Также обратите внимание на момент времени, когда устройство выдает ошибку «сбой соединения TCP». Он пытается использовать соединение, которое, по его мнению, установлено, но сервер считает, что оно прервано? Здесь также происходит что-то странное - если соединение не установлено, вместо сообщения об ошибке ваше устройство кредитной карты должно попытаться создать новое (что, по-видимому, успешно происходит во второй раз).

И, наконец, если вы используете NAT, рассмотрите возможность предоставления одному из этих устройств прямого соединения, отличного от NAT, для целей тестирования (снова выполните захват пакета). NAT может делать очень странные вещи с приложениями или протоколами, которые зависят от сквозного принципа и не учитывают широко распространенное использование NAT или других устройств с отслеживанием состояния, мешающих соединению.

Если вы используете прокси-сервер, убедитесь, что он не задействован или правильно настроен для работы с этими устройствами. У нас есть много устройств или процессов, которые достаточно умны, чтобы использовать настройки WPAD своей операционной системы, но не отправляют учетные данные активного каталога учетной записи пользователя, которая их запускает, с их запросами HTTP / HTTPS, и прокси-сервер ожидает, что все подключения будут аутентифицированы и так что процесс будет спокойно провалиться на стороне клиента.