Les terminaux pinpad de débit / crédit se déconnectent du réseau après 15 minutes. Reconnectez-vous après une erreur

Nous avons un réseau HP procurve et environ 20 des terminaux standard à clavier de débit / crédit que tout le monde a l'habitude de voir dans presque tous les magasins de nos jours. Ils se connectent directement au LAN et ne communiquent qu'avec un site de paiement sur SSL / 443. Aucun logiciel ou serveur au milieu.

Le problème est que les périphériques donnent généralement un échec de connexion TCP lors de la première tentative d'utilisation. Ils fonctionneront ensuite bien pendant une heure d'affilée. Mais, s'ils sont autorisés à rester inactifs pendant 10 à 15 minutes (environ), ils lèveront l'erreur initiale une fois.

Au départ, ils provenaient tous d'une seule entreprise et nous avons pensé que cela avait quelque chose à voir avec leur configuration, ou la marque / le modèle. Mais récemment, nous avons installé de nouveaux appareils d'un fournisseur complètement différent, en utilisant différents types de pinpads ... et ils ont la même erreur.

Nous avons essayé l'adressage IP statique contre DHCP. Nous avons ajouté le site de paiement externe à une règle de pare-feu spéciale qui leur permet de quitter sans les contrôles de menace normaux. Nous les avons essayés sur différents VLAN. Nous avons essayé de les connecter à différents types de commutateurs de zones. J'ai même essayé un fichier batch programmé qui les envoie (home made stay-alive), toutes les 3 minutes. Rien ne fait aucune différence. En termes de problèmes de réseau, les appareils sont tous connectés aux mêmes réseaux locaux virtuels et commutateurs de zone que leurs ordinateurs / imprimantes de caisse à proximité - et nous n'avons aucun problème avec autre chose. Les systèmes de caisse exécutent des applications client / serveur / base de données complètes et si le même problème de déconnexion était présent pour eux parce que la mise en réseau dans la région était mauvaise, nous en entendrions parler rapidement.

La dernière théorie que je vais aborder est liée aux délais d'expiration du cache d'arp, mais je ne fais que commencer.

J'apprécierais une aide ... des idées folles sont également les bienvenues.

W.

J'ai vu un problème similaire dans le passé. Mon problème était lié à mon appareil établissant une connexion via un appareil NAT, puis cette connexion est restée inactive trop longtemps (rien envoyé, rien reçu). Les deux extrémités de la connexion n'avaient aucune idée, mais le périphérique NAT au milieu a décidé de fermer la connexion en raison de l'inactivité. Ensuite, lorsque le trafic tentait de traverser le NAT, les paquets étaient abandonnés car la règle NAT n'existait plus.

Vos appareils font peut-être quelque chose de similaire. Ma solution était d'utiliser un paquet de maintien en vie entre les deux appareils. Il enverrait un paquet toutes les 60 secondes, et cela a résolu mon problème (le système fonctionne depuis plusieurs années sans avoir besoin d'être touché). Il ne suffit pas d'envoyer une requête ping à l'un ou l'autre appareil à partir du même réseau local pour maintenir la règle NAT en place. Les appareils DOIVENT se parler régulièrement.

Cependant, sans en savoir plus sur vos systèmes particuliers, il est difficile de dire si cela s'applique à vous.

J'espère que cela t'aides.

Le problème est que les périphériques donnent généralement un échec de connexion TCP lors de la première tentative d'utilisation. Ils fonctionneront ensuite bien pendant une heure d'affilée. Mais, s'ils sont autorisés à rester inactifs pendant 10 à 15 minutes (environ), ils lèveront l'erreur initiale une fois.

La première chose que je recommanderais est d'obtenir une copie du manuel ou de parler au vendeur pour obtenir une explication exacte de l'erreur que les appareils génèrent. J'ai perdu du temps à chercher des problèmes de couche 3/4 alors que l'erreur signifiait en fait autre chose. Tous les fournisseurs n'utilisent pas la terminologie correctement ou systématiquement.

Il semble que les appareils n'envoient pas la manipulation ou ne se maintiennent pas correctement. S'il n'y a pas de données traversant votre connexion TCP, elles seront finalement fermées. Pour empêcher ce point de terminaison (ou les deux), vous pouvez envoyer des paquets persistants pour empêcher la connexion de se terminer. Je sais que cela peut être fait avec TCP (Layer-4) et sans doute cela pourrait aussi être fait avec SSL / TLS (Layer-7).

Mettez un renifleur de paquets de choix entre l'un de ces appareils et votre infrastructure et enregistrez tout son trafic à partir du moment où il fonctionne jusqu'au moment où il ne fonctionne pas. Ensuite, regardez-le et trouvez où l'appareil ou le serveur auquel il se connecte commence la séquence de terminaison , puis voyez ce qui précède immédiatement. Jetez également un œil au moment où le périphérique génère l'erreur «Échec de la connexion TCP». Essaie-t-il d'utiliser une connexion qu'il pense établie mais que le serveur pense être terminée? Quelque chose d'étrange se produit également ici - si la connexion n'est pas établie, au lieu de lancer une erreur, votre appareil de carte de crédit devrait essayer d'en créer une nouvelle (ce qui se produit apparemment avec succès la deuxième fois).

Et enfin, si vous utilisez NAT, envisagez de donner à l'un de ces appareils une connexion directe non NAT à des fins de test (encore une fois, faites une capture de paquets). Le NAT peut faire des choses très étranges aux applications ou aux protocoles qui dépendent du principe de bout en bout et ne prennent pas en compte l'utilisation répandue du NAT ou d'autres appareils avec état interférant avec la connexion.

Si vous utilisez un proxy, assurez-vous qu'il n'est pas impliqué ou qu'il est correctement configuré pour gérer ces périphériques. Nous avons beaucoup d'appareils ou de processus suffisamment intelligents pour utiliser les paramètres WPAD de leur système d'exploitation hôte, mais ne soumettons pas les informations d'identification Active Directory du compte d'utilisateur qui les exécute avec leurs demandes HTTP / HTTPS et le proxy attend que toutes les connexions soient authentifiées et donc le processus échouera tranquillement côté client.