I terminali del pinpad di debito / credito si disconnettono dalla rete dopo 15 minuti. Riconnetti dopo un errore

Abbiamo una rete HP procurve e circa 20 dei terminali pinpad debito / credito standard che tutti sono abituati a vedere in quasi tutti i negozi in questi giorni. Si connettono direttamente alla LAN e comunicano solo a un sito di pagamento su SSL / 443. Nessun software o server nel mezzo.

Il problema è che i dispositivi di solito danno un errore di connessione TCP al primo tentativo di utilizzo. Lavoreranno quindi bene per un'ora di fila. Ma, se lasciati inattivo per 10-15 minuti (circa), lanceranno l'errore iniziale una volta.

Inizialmente, provenivano tutti da una singola azienda e abbiamo pensato che avesse qualcosa a che fare con la loro configurazione o la marca / modello. Ma recentemente, abbiamo installato alcuni nuovi dispositivi da un fornitore completamente diverso, utilizzando diversi tipi di pinpad ... e hanno lo stesso errore.

Abbiamo provato l'indirizzamento IP statico vs. DHCP. Abbiamo aggiunto il sito di pagamento esterno a una speciale regola firewall che consente loro di uscire senza i normali controlli delle minacce. Li abbiamo provati su vari Vlan. Abbiamo provato a collegarli a vari tipi di interruttori di area. Ho anche provato un file batch programmato che li esegue il ping (fatto in casa per rimanere in vita), ogni 3 minuti. Niente fa differenza. In termini di problemi di rete, i dispositivi sono tutti vincolati agli stessi identici vlans e switch di area dei loro computer / stampanti di cassa vicini - e non abbiamo problemi con nient'altro. I sistemi di cassa eseguono app client / server / database complete e se lo stesso problema di disconnessione era presente per loro perché la rete nella zona era difettosa, ne avremmo sentito parlare rapidamente.

L'ultima teoria che sto per affrontare è legata ai timeout della cache arp, ma ho appena iniziato.

Gradirei un po 'di assistenza ... Idee folli anche ben accette.

W.

Ho visto un problema simile in passato. Il mio problema era correlato al fatto che il mio dispositivo stabiliva una connessione tramite un dispositivo NAT, quindi quella connessione è rimasta inattiva per troppo tempo (niente inviato, niente ricevuto). Entrambe le estremità della connessione non avevano idea, ma il dispositivo NAT nel mezzo ha deciso di chiudere la connessione a causa dell'inattività. Quindi, quando il traffico cercava di attraversare il NAT, i pacchetti venivano eliminati perché la regola NAT non esisteva più.

I tuoi dispositivi potrebbero fare qualcosa di simile. La mia soluzione era quella di utilizzare un pacchetto keep-alive tra i due dispositivi. Invierebbe un pacchetto ogni 60 secondi e questo ha risolto il mio problema (il sistema è in esecuzione da diversi anni ormai senza che sia necessario toccarlo). Il semplice ping di uno dei due dispositivi dalla stessa LAN non era sufficiente per mantenere in posizione la regola NAT. I dispositivi DEVONO dialogare regolarmente.

Tuttavia, senza sapere di più sui tuoi sistemi particolari, è difficile dire se questo si applica a te.

Spero che sia di aiuto.

Il problema è che i dispositivi di solito danno un errore di connessione TCP al primo tentativo di utilizzo. Lavoreranno quindi bene per un'ora di fila. Ma, se lasciati inattivo per 10-15 minuti (circa), lanceranno l'errore iniziale una volta.

La prima cosa che consiglierei è ottenere una copia del manuale o parlare con il fornitore per ottenere una spiegazione di cosa significhi esattamente l'errore generato dai dispositivi. Ho perso tempo a cercare problemi di livello 3/4 quando l'errore in realtà significava qualcos'altro. Non tutti i fornitori utilizzano la terminologia in modo corretto o coerente.

Sembra che i dispositivi non stiano inviando la gestione o che mantengano correttamente in vita. Se non ci sono dati che attraversano la tua connessione TCP, alla fine verranno chiusi. Per evitare questo endpoint (o entrambi) è possibile inviare pacchetti keep-alive per impedire la chiusura della connessione. So che questo può essere fatto con TCP (Layer-4) e presumibilmente potrebbe essere fatto anche con SSL / TLS (Layer-7).

Metti uno sniffer di pacchetti a scelta tra uno di questi dispositivi e la tua infrastruttura e registra tutto il suo traffico dal momento in cui funziona fino al momento in cui non lo fa. Quindi guardalo attraverso e scopri dove il dispositivo o il server a cui si sta connettendo sta avviando la sequenza di terminazione , quindi vedi cosa precede immediatamente. Dai anche un'occhiata al momento in cui il dispositivo genera l'errore "Errore connessione TCP". Sta tentando di utilizzare una connessione che ritiene sia stata stabilita ma che il server ritiene sia stata terminata? Anche qui sta succedendo qualcosa di strano: se la connessione non viene stabilita, invece di generare un errore, il dispositivo della tua carta di credito dovrebbe tentare di crearne uno nuovo (che apparentemente accade con successo la seconda volta).

E infine se stai usando NAT, considera di dare a uno di questi dispositivi una connessione diretta, non NAT a scopo di test (di nuovo, prendi un'acquisizione di pacchetti). NAT può fare cose molto strane con applicazioni o protocolli che dipendono dal Principio end-to-end e non tiene conto dell'uso diffuso NAT o di altri dispositivi con stato che interferiscono con la connessione.

Se si utilizza un proxy, assicurarsi che non sia coinvolto o che sia configurato correttamente per gestire questi dispositivi. Disponiamo di numerosi dispositivi o processi abbastanza intelligenti da utilizzare le impostazioni WPAD del loro sistema operativo host, ma non inviare le credenziali della directory attiva dell'account utente che li esegue con le loro richieste HTTP / HTTPS e il proxy si aspetta che tutte le connessioni siano autenticate e quindi il processo fallirà silenziosamente sul lato client.