Debit- / Kredit-Pinpad-Terminals werden nach 15 Minuten vom Netzwerk getrennt. Nach einem Fehler erneut verbinden

Wir haben ein HP Procurve-Netzwerk und ungefähr 20 der Standard-Debit- / Kredit-Pinpad-Terminals, die heutzutage jeder in fast jedem Geschäft sieht. Sie stellen eine direkte Verbindung zum LAN her und kommunizieren nur über SSL / 443 mit einer Zahlungsstelle. Keine Software oder Server in der Mitte.

Das Problem ist, dass die Geräte normalerweise beim ersten Versuch einen TCP-Verbindungsfehler verursachen. Sie werden dann eine Stunde lang gut funktionieren. Wenn sie jedoch ungefähr 10 bis 15 Minuten im Leerlauf sitzen dürfen, wird der anfängliche Fehler einmal ausgelöst.

Anfangs stammten sie alle aus einer einzigen Firma und wir dachten, dass dies etwas mit ihrem Setup oder der Marke / dem Modell zu tun hat. Aber vor kurzem haben wir einige neue Geräte von einem völlig anderen Hersteller installiert, die verschiedene Arten von Pinpads verwenden ... und sie haben den gleichen Fehler.

Wir haben versucht, statische oder DHCP-IP-Adressen zu verwenden. Wir haben die externe Zahlungsseite zu einer speziellen Firewall-Regel hinzugefügt, die es ihnen ermöglicht, ohne die normalen Bedrohungsprüfungen zu beenden. Wir haben sie auf verschiedenen Vlans ausprobiert. Wir haben versucht, sie mit verschiedenen Arten von Bereichsschaltern zu verbinden. Habe sogar eine geplante Batch-Datei ausprobiert, die sie alle 3 Minuten anpingt (hausgemachtes Stay-Alive). Nichts macht einen Unterschied. In Bezug auf Netzwerkprobleme sind die Geräte alle mit genau denselben VLANs und Bereichsschaltern verbunden wie ihre nahe gelegenen Geldcomputer / -drucker - und wir haben keine Probleme mit irgendetwas anderem. Auf den Cash-Systemen werden vollständige Client / Server / Datenbank-Apps ausgeführt. Wenn für sie das gleiche Problem aufgetreten ist, weil das Netzwerk in der Region schlecht war, würden wir schnell davon erfahren.

Die neueste Theorie, die ich in Angriff nehmen werde, bezieht sich auf Zeitüberschreitungen im Arp-Cache, aber ich fange gerade erst an.

Würde mich über Hilfe freuen ... verrückte Ideen sind ebenfalls willkommen.

W.

Ich habe in der Vergangenheit ein ähnliches Problem gesehen. Mein Problem hing damit zusammen, dass mein Gerät eine Verbindung über ein NAT-Gerät herstellte und diese Verbindung dann zu lange inaktiv blieb (nichts gesendet, nichts empfangen). Beide Enden der Verbindung hatten keine Ahnung, aber das NAT-Gerät in der Mitte entschied sich, die Verbindung wegen Inaktivität zu schließen. Wenn dann der Datenverkehr versuchte, das NAT zu durchlaufen, wurden die Pakete verworfen, da die NAT-Regel nicht mehr vorhanden war.

Ihre Geräte tun möglicherweise etwas Ähnliches. Meine Lösung bestand darin, ein Keep-Alive-Paket zwischen den beiden Geräten zu verwenden. Es würde alle 60 Sekunden ein Paket senden, und dies löste mein Problem (das System läuft seit mehreren Jahren, ohne berührt werden zu müssen). Es reichte nicht aus, nur ein Gerät aus demselben LAN zu pingen, um die NAT-Regel beizubehalten. Die Geräte MÜSSEN regelmäßig miteinander sprechen.

Ohne jedoch mehr über Ihre speziellen Systeme zu wissen, ist es schwierig zu sagen, ob dies auf Sie zutrifft.

Hoffe das hilft.

Das Problem ist, dass die Geräte normalerweise beim ersten Versuch einen TCP-Verbindungsfehler verursachen. Sie werden dann eine Stunde lang gut funktionieren. Wenn sie jedoch ungefähr 10 bis 15 Minuten im Leerlauf sitzen dürfen, wird der anfängliche Fehler einmal ausgelöst.

Das erste, was ich empfehlen würde, ist, sich eine Kopie des Handbuchs zu besorgen oder mit dem Anbieter zu sprechen, um eine Erklärung zu erhalten, was genau der Fehler bedeutet, den die Geräte erzeugen. Ich habe Zeit damit verschwendet, nach Layer-3/4-Problemen zu suchen, wenn der Fehler tatsächlich etwas anderes bedeutete. Nicht alle Anbieter verwenden die Terminologie korrekt oder konsistent.

Es hört sich so an, als würden die Geräte die Handhabung nicht senden oder nicht korrekt am Leben bleiben. Wenn keine Daten über Ihre TCP-Verbindung übertragen werden, werden diese möglicherweise geschlossen. Um dies zu verhindern, kann ein Endpunkt (oder beide) Keep-Alive-Pakete senden, um zu verhindern, dass die Verbindung beendet wird. Ich weiß, dass dies mit TCP (Layer-4) und vermutlich auch mit SSL / TLS (Layer-7) möglich ist.

Stellen Sie einen Paket-Sniffer Ihrer Wahl zwischen eines dieser Geräte und Ihre Infrastruktur und zeichnen Sie den gesamten Datenverkehr von der Zeit bis zur Nichtbeachtung auf. Schauen Sie dann durch und finden Sie heraus, wo das Gerät oder der Server, zu dem es eine Verbindung herstellt, die Beendigungssequenz startet , und sehen Sie dann, was unmittelbar davor steht. Sehen Sie sich auch den Zeitpunkt an, zu dem das Gerät den Fehler "TCP-Verbindungsfehler" auslöst. Versucht es, eine Verbindung zu verwenden, von der es glaubt, dass sie hergestellt ist, die der Server jedoch für beendet hält? Auch hier passiert etwas Seltsames: Wenn die Verbindung nicht hergestellt wird, sollte Ihr Kreditkartengerät anstelle eines Fehlers versuchen, eine neue zu erstellen (was anscheinend beim zweiten Mal erfolgreich geschieht).

Wenn Sie NAT verwenden, sollten Sie erwägen, einem dieser Geräte zu Testzwecken eine direkte Nicht-NAT-Verbindung zu geben (nehmen Sie erneut eine Paketerfassung vor). NAT kann sehr seltsame Dinge mit Anwendungen oder Protokollen tun, die vom End-to-End-Prinzip abhängen und die weit verbreitete Verwendung von NAT oder anderen zustandsbehafteten Geräten, die die Verbindung stören, nicht berücksichtigen.

Wenn Sie einen Proxy verwenden, stellen Sie sicher, dass dieser nicht beteiligt ist oder dass er für die Handhabung dieser Geräte richtig konfiguriert ist. Wir haben viele Geräte oder Prozesse, die intelligent genug sind, um die WPAD-Einstellungen ihres Host-Betriebssystems zu verwenden, aber nicht die Active Directory-Anmeldeinformationen des Benutzerkontos, das sie ausführt, mit ihren HTTP / HTTPS-Anforderungen senden, und der Proxy erwartet, dass alle Verbindungen authentifiziert werden und Daher schlägt der Prozess auf der Clientseite leise fehl.