Os terminais pinpad de débito / crédito desconectam-se da rede após 15 minutos. Reconectar após um erro

Temos uma rede de suprimentos HP e cerca de 20 dos terminais padrão de pinpad de débito / crédito que todos estão acostumados a ver em praticamente todas as lojas atualmente. Eles se conectam diretamente à LAN e somente se comunicam com um site de pagamento no SSL / 443. Nenhum software ou servidor no meio.

O problema é que os dispositivos geralmente causam uma falha na conexão TCP na primeira tentativa de uso. Eles vão funcionar bem por uma hora seguida. Mas, se ficarem ociosos por 10 a 15 minutos (aprox.), Eles lançarão o erro inicial uma vez.

Inicialmente, eles eram todos de uma única empresa e achamos que tinha algo a ver com a configuração deles, ou a marca / modelo. Recentemente, porém, instalamos alguns novos dispositivos de um fornecedor completamente diferente, usando diferentes tipos de pinpads ... e eles têm o mesmo erro.

Tentamos o endereçamento IP estático vs. DHCP. Adicionamos o site de pagamento externo a uma regra de firewall especial que permite que eles saiam sem as verificações normais de ameaças. Nós os experimentamos em vários Vlans. Tentamos adaptá-los a vários tipos de comutadores de áreas. Até tentaram um arquivo em lote agendado que os envia (em casa, permanecem vivos), a cada 3 minutos. Nada faz diferença. Em termos de problemas de rede, todos os dispositivos são exatamente iguais aos mesmos vlans e switches de área que seus computadores / impressoras de caixa próximas - e não temos problemas com mais nada. Os sistemas de caixa executam aplicativos completos de cliente / servidor / banco de dados e, se o mesmo problema desconcertante estivesse presente para eles, porque a rede na área era ruim, ouviríamos rapidamente.

A teoria mais recente que estou prestes a abordar está relacionada aos tempos limite do cache do arp, mas estou apenas começando.

Gostaria de receber alguma ajuda ... idéias malucas também são bem-vindas.

W.

Eu já vi um problema semelhante no passado. Meu problema estava relacionado ao meu dispositivo estabelecer uma conexão através de um dispositivo NAT e, em seguida, essa conexão permaneceu inativa por muito tempo (nada enviado, nada recebido). Ambas as extremidades da conexão não tinham idéia, mas o dispositivo NAT no meio decidiu fechar a conexão devido à inatividade. Então, quando o tráfego tentava atravessar o NAT, os pacotes estavam sendo descartados porque a regra do NAT não existia mais.

Seus dispositivos podem estar fazendo algo semelhante. Minha solução foi usar um pacote keep-alive entre os dois dispositivos. Ele enviava um pacote a cada 60 segundos, e isso resolveu meu problema (o sistema está em funcionamento há vários anos sem precisar ser tocado). Simplesmente executar o ping de qualquer dispositivo da mesma LAN não foi suficiente para manter a regra NAT no lugar. Os dispositivos devem conversar regularmente.

No entanto, sem saber mais sobre seus sistemas específicos, é difícil dizer se isso se aplica a você.

Espero que isto ajude.

O problema é que os dispositivos geralmente causam uma falha na conexão TCP na primeira tentativa de uso. Eles vão funcionar bem por uma hora seguida. Mas, se ficarem ociosos por 10 a 15 minutos (aprox.), Eles lançarão o erro inicial uma vez.

A primeira coisa que eu recomendaria é obter uma cópia do manual ou conversar com o fornecedor para obter uma explicação exata do significado do erro que os dispositivos geram. Perdi tempo procurando problemas na Camada 3/4 quando o erro realmente significou outra coisa. Nem todos os fornecedores usam a terminologia de maneira correta ou consistente.

Parece que os dispositivos não estão enviando manipulação ou fazendo manutenção corretamente. Se não houver dados atravessando sua conexão TCP, eles serão fechados eventualmente. Para impedir que esse ponto final (ou ambos) possa enviar pacotes keep-alive para impedir que a conexão seja encerrada. Eu sei que isso pode ser feito com TCP (Camada 4) e, presumivelmente, também pode ser feito com SSL / TLS (Camada 7).

Escolha um sniffer de pacotes entre um desses dispositivos e sua infraestrutura e registre todo o tráfego desde o momento em que funciona até o momento em que não funciona. Em seguida, examine-o e encontre onde o dispositivo ou o servidor ao qual está se conectando está iniciando a sequência de terminação e veja o que imediatamente o precede. Veja também o momento em que o dispositivo lança o erro "Falha na conexão TCP". Ele está tentando usar uma conexão que considera estabelecida, mas que o servidor acha que foi encerrada? Algo estranho está acontecendo aqui também - se a conexão não for estabelecida, em vez de gerar um erro, seu dispositivo de cartão de crédito deve tentar criar um novo (o que aparentemente ocorre com sucesso na segunda vez).

E, finalmente, se você estiver usando NAT, considere fornecer a um desses dispositivos uma conexão direta, não NAT, para fins de teste (novamente, faça uma captura de pacote). O NAT pode fazer coisas muito estranhas aos aplicativos ou protocolos que dependem do Princípio de Ponta a Ponta e não leva em consideração o uso generalizado do NAT ou de outros dispositivos com estado que interferem na conexão.

Se você estiver usando um proxy, verifique se ele não está envolvido ou se está configurado corretamente para lidar com esses dispositivos. Temos muitos dispositivos ou processos inteligentes o suficiente para usar as configurações WPAD do sistema operacional host, mas não enviam as credenciais do diretório ativo da conta do usuário que os está executando com suas solicitações HTTP / HTTPS, e o proxy espera que todas as conexões sejam autenticadas e portanto, o processo falhará silenciosamente no lado do cliente.