In un sito cliente, il team di rete ha aggiunto un firewall tra il client e il server. Ciò causa la disconnessione delle connessioni inattive dopo circa 40 minuti di inattività. Le persone della rete affermano che il firewall non ha alcun timeout di connessione inattiva, ma il fatto è che le connessioni inattive vengono interrotte.
Per ovviare a questo, abbiamo prima configurato il server (una macchina Linux) con keepalive TCP attivati con tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 e tcp_keepalive_probes = 30000. Funziona e le connessioni rimangono valide per giorni o più. Tuttavia, vorremmo anche che il server rilevi i client morti e interrompa la connessione, quindi abbiamo modificato le impostazioni in time = 300, intvl = 180, probes = 10, pensando che se il client fosse effettivamente attivo, il server effettuerebbe il sondaggio ogni 300 secondi (5 minuti) e il client avrebbe risposto con un ACK e ciò avrebbe impedito al firewall di vedere questo come una connessione inattiva e ucciderlo. Se il client era morto, dopo 10 sondaggi, il server avrebbe interrotto la connessione. Con nostra sorpresa, le connessioni inattive ma vive vengono uccise dopo circa 40 minuti come prima.
Wireshark in esecuzione sul lato client non mostra alcun keepalive tra il server e il client, anche quando i keepalive sono abilitati sul server.
Cosa potrebbe succedere qui?
Se le impostazioni keepalive sul server sono time = 300, intvl = 180, probe = 10, mi aspetterei che se il client è vivo ma inattivo, il server invierà probe keepalive ogni 300 secondi e lascerebbe la connessione da solo, e se il il client è morto, ne invierebbe uno dopo 300 secondi, quindi altre 9 sonde ogni 180 secondi prima di interrompere la connessione. Ho ragione?
Una possibilità è che il firewall stia in qualche modo intercettando le sonde keepalive dal server e non riesca a passarle al client, e il fatto che abbia ottenuto un probe fa pensare che la connessione sia attiva. Questo comportamento comune è per un firewall? Non sappiamo che tipo di firewall è coinvolto.
Il server è un nodo Teradata e la connessione avviene da un'utilità client Teradata al server di database, porta 1025 sul lato server, ma abbiamo riscontrato lo stesso problema con una connessione SSH, quindi pensiamo che influisca su tutte le connessioni TCP.