Los terminales de pinpad de débito / crédito se desconectan de la red después de 15 minutos. Reconectarse después de un error

Tenemos una red procurve HP y alrededor de 20 de los terminales de pinpad de débito / crédito estándar que todos están acostumbrados a ver en casi todas las tiendas en estos días. Se conectan directamente a la LAN y solo se comunican con un sitio de pago en SSL / 443. No hay software o servidor en el medio.

El problema es que los dispositivos generalmente dan una falla de conexión TCP en el primer intento de uso. Luego funcionarán bien durante una hora consecutiva. Pero, si se les permite permanecer inactivos durante 10-15 minutos (aproximadamente), arrojarán el error inicial una vez.

Inicialmente, todos eran de una sola compañía y pensamos que tenía algo que ver con su configuración o la marca / modelo. Pero recientemente, hemos instalado algunos dispositivos nuevos de un proveedor completamente diferente, usando diferentes tipos de pinpads ... y tienen el mismo error.

Hemos probado el direccionamiento IP estático frente a DHCP. Hemos agregado el sitio de pago externo a una regla de firewall especial que les permite salir sin las comprobaciones de amenazas normales. Los hemos probado en varios Vlans. Hemos intentado conectarlos a varios tipos de interruptores de áreas. Incluso he probado un archivo por lotes programado que los hace sonar (hecho en casa), cada 3 minutos. Nada hace la diferencia. En términos de problemas de red, todos los dispositivos están conectados exactamente a los mismos vlans e interruptores de área que sus computadoras / impresoras de efectivo cercanas, y no tenemos problemas con nada más. Los sistemas de efectivo ejecutan aplicaciones completas de cliente / servidor / base de datos y si el mismo problema de desconexión estaba presente para ellos porque la red en el área era mala, nos enteraríamos de ello rápidamente.

La última teoría que estoy a punto de abordar está relacionada con los tiempos de espera de caché de arp, pero recién estoy comenzando.

Agradecería un poco de ayuda ... ideas locas también son bienvenidas.

W.

He visto un problema similar en el pasado. Mi problema estaba relacionado con mi dispositivo estableciendo una conexión a través de un dispositivo NAT, y luego esa conexión permaneció inactiva durante demasiado tiempo (nada enviado, nada recibido). Ambos extremos de la conexión no tenían idea, pero el dispositivo NAT en el medio decidió cerrar la conexión debido a la inactividad. Luego, cuando el tráfico intentaba atravesar el NAT, los paquetes se descartaban porque la regla NAT ya no existía.

Sus dispositivos podrían estar haciendo algo similar. Mi solución fue usar un paquete de mantenimiento entre los dos dispositivos. Enviaría un paquete cada 60 segundos, y esto resolvió mi problema (el sistema ha estado funcionando durante varios años sin necesidad de ser tocado). Simplemente hacer ping a cualquier dispositivo desde la misma LAN no fue suficiente para mantener la regla NAT en su lugar. Los dispositivos DEBEN hablar entre ellos regularmente.

Sin embargo, sin saber más acerca de sus sistemas particulares, es difícil decir si esto se aplica a usted.

Espero que esto ayude.

El problema es que los dispositivos generalmente dan una falla de conexión TCP en el primer intento de uso. Luego funcionarán bien durante una hora consecutiva. Pero, si se les permite permanecer inactivos durante 10-15 minutos (aproximadamente), arrojarán el error inicial una vez.

Lo primero que recomendaría es obtener una copia del manual o hablar con el proveedor para obtener una explicación de qué significa exactamente el error que generan los dispositivos. Perdí el tiempo buscando problemas de capa 3/4 cuando el error realmente significaba algo más. No todos los proveedores usan la terminología correcta o consistentemente.

Parece que los dispositivos no están enviando el manejo o haciendo el mantenimiento de vida correctamente. Si no hay datos que atraviesen su conexión TCP, eventualmente se cerrará. Para evitar esto, un único punto final (o ambos) puede enviar paquetes de mantenimiento para evitar que la conexión finalice. Sé que esto se puede hacer con TCP (Layer-4) y presumiblemente también se podría hacer con SSL / TLS (Layer-7).

Coloque un sniffer de paquetes de elección entre uno de estos dispositivos y su infraestructura y registre todo su tráfico desde el momento en que funciona hasta el momento en que no lo hace. Luego mire a través de él y encuentre dónde el dispositivo o el servidor al que se está conectando está comenzando la secuencia de terminación , luego vea qué precede inmediatamente. Observe también el momento en el que el dispositivo arroja el error "Error de conexión TCP". ¿Intenta utilizar una conexión que cree que está establecida pero que el servidor cree que ha finalizado? Aquí también está sucediendo algo extraño: si no se establece la conexión, en lugar de arrojar un error, su dispositivo de tarjeta de crédito debería intentar crear uno nuevo (que aparentemente ocurre con éxito la segunda vez).

Y finalmente, si está utilizando NAT, considere darle a uno de estos dispositivos una conexión directa que no sea NAT para fines de prueba (nuevamente, tome una captura de paquetes). NAT puede hacer cosas muy extrañas a las aplicaciones o protocolos que dependen del Principio de extremo a extremo y no tiene en cuenta el uso generalizado de NAT u otros dispositivos con estado que interfieren con la conexión.

Si está utilizando un proxy, asegúrese de que no esté involucrado o que esté configurado correctamente para manejar estos dispositivos. Tenemos muchos dispositivos o procesos que son lo suficientemente inteligentes como para usar la configuración WPAD de su sistema operativo host pero no enviar las credenciales del directorio activo de la cuenta de usuario que las ejecuta con sus solicitudes HTTP / HTTPS y el proxy espera que todas las conexiones se autentiquen y entonces el proceso fallará silenciosamente del lado del cliente.