Terminais de pinagem de débito / crédito desconectados da rede após 15 minutos. Reconectar após um erro

Question

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

O problema é que os dispositivos geralmente apresentam uma falha na conexão TCP na primeira tentativa de uso. Eles então funcionarão bem por uma hora consecutiva. Mas, se for permitido ficar ocioso por 10 a 15 minutos, 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 com a marca / modelo. Mas recentemente, 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. Nós tentamos conectá-los a vários tipos de switches de áreas. Já tentei um arquivo de lote agendado que pinga-los (casa feita ficar vivo), a cada 3 minutos. Nada faz diferença. Em termos de problemas de rede, os dispositivos são todos conectados exatamente às mesmas mudanças de vlans e áreas que seus computadores / impressoras de dinheiro próximos - 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 de desconexão estivesse presente para eles, porque a rede na área era ruim, ouviríamos sobre isso rapidamente.

A última teoria que estou prestes a abordar está relacionada a tempos limite de cache do arp, mas estou apenas começando.

Gostaria de receber ajuda ... ideias loucas também são bem-vindas.

W.

    

Answer 1

Eu já vi um problema semelhante no passado. Meu problema estava relacionado ao fato de meu dispositivo estabelecer uma conexão por meio de um dispositivo NAT, e essa conexão permaneceu inativa por muito tempo (nada foi enviado, nada foi recebido). Ambas as extremidades da conexão não tinham idéia, mas o dispositivo NAT no meio decidiu fechar a conexão por causa da inatividade. Então, quando o tráfego estava tentando atravessar o NAT, os pacotes estavam sendo descartados porque a regra 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á funcionando há vários anos sem precisar ser tocado). Simplesmente pingar qualquer dispositivo da mesma LAN não foi suficiente para manter a regra de NAT no local. Os dispositivos devem conversar entre si regularmente.

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

Espero que isso ajude.

    

Answer 2

The problem is that the devices usually give a TCP connection failure on the first attempted use. They'll then work fine for an hour straight. But, if allowed to sit idle for 10 - 15 mins (approx), they'll throw the initial error once.

A primeira coisa que eu recomendaria é obter uma cópia do manual ou falar com o fornecedor para obter uma explicação exata do erro que os dispositivos geram. Perdi tempo procurando por problemas de Camada 3/4 quando o erro realmente significava 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 mantendo o keep-alive corretamente. Se não houver dados passando pela sua conexão TCP, ela será fechada eventualmente. Para evitar que esse endpoint (ou ambos) possa enviar pacotes keep-alive para evitar que a conexão seja finalizada. Eu sei que isso pode ser feito com o TCP (Layer-4) e, presumivelmente, também poderia ser feito com SSL / TLS (Layer-7).

Coloque um sniffer de pacotes de escolha entre um desses dispositivos e sua infraestrutura e registre todo o tráfego desde o momento em que ele funciona até o momento em que não funciona. Então olhe através dele e encontre onde o dispositivo ou o servidor está se conectando está iniciando a seqüência de término , então veja o que precede imediatamente isso. Também observe o momento em que o dispositivo lança o erro "Falha na conexão TCP". Está tentando usar uma conexão que acha que está estabelecida, mas que o servidor pensa que está terminada? 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 acontece com sucesso na segunda vez).

E, finalmente, se você estiver usando o NAT, considere dar 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 a aplicativos ou protocolos que dependem do Princípio End-to-End e fazer Não use o NAT difundido ou outros dispositivos com informações de estado que interfiram 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 que são inteligentes o suficiente para usar as configurações WPAD do sistema operacional do host, mas não enviam as credenciais do diretório ativo da conta de usuário que as executa com suas solicitações HTTP / HTTPS e o proxy espera que todas as conexões sejam autenticadas e então o processo falhará silenciosamente no lado do cliente.