Есть у меня софтинка, называется оптимизатор. Суть рассматриваемой проблемы в том, что ей необходимо поддерживать соединение от сервера БД до моего сервера, несмотря на то, что соединение простаивает. А соединение упрямо рвалось через одинаковые промежутки времени где-то в час.
Рассматривались разные варианты. Сначала - самый распространенный, что забывает о соединении шлюз, обеспечивающий NAT. Поскольку одним из шлюзов был мой компьютер, то сказать, что я перевернул всю конфигурацию ядра в отношении сети - ничего не сказать. Менял и убирал net.core. и ipv4. параметры до посинения. Не помогло. Решение неочевидное, но для памяти запишу, что именно помогло.
1) Со стороны сервера оптимизатора, пока клиентская часть спит в ожидании ответа от БД, раз в 5 минут шлется команда "!" (клиент ее игнорирует в любом случае, как бессмысленную), чтобы создавать видимость занятости канала, т.е. keep-alive. Поскольку совсем не хотелось переписывать клиента так, чтобы он ожидал команд по сети в параллели с ожиданием ответа от БД, т.е. в двупоточный, то расчет шел на буфер сетевого соединения и команда состояла из нескольких байт. 12 раз в час посылать такие небольшие пакеты - буфер не должен переполняться. Во-вторых, командой tcpdump -i eth1 -v \(port 7654 host ...\) выловилось, что со стороны клиента приходит пакет ask, даже если клиент "висит" в ожидании. Прохождение пакетов в обе стороны должно подпитывать уверенность шлюзов, что соединение еще живо.
2) Из конфига iptables шлюза были убраны строки:
Код:
#echo Drop bogus TCP packets
#$IT -A INPUT -p tcp -m tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT --reject-with tcp-reset
#$IT -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j REJECT --reject-with tcp-reset
#$IT -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset