На сайте клиента сетевая группа добавила брандмауэр между клиентом и сервером. Это приводит к отключению незанятых соединений примерно через 40 минут простоя. Сетевые специалисты говорят, что у брандмауэра нет тайм-аута простоя соединения, но факт в том, что простаивающие соединения прерываются.
Чтобы обойти это, мы сначала настроили сервер (машину Linux) с включенными пакетами поддержки активности TCP с tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 и tcp_keepalive_probes = 30000. Это работает, и соединения остаются жизнеспособными в течение нескольких дней или более. Однако мы также хотели бы, чтобы сервер обнаруживал мертвых клиентов и прерывал соединение, поэтому мы изменили настройки на time = 300, intvl = 180, probes = 10, думая, что если клиент действительно жив, сервер будет проверять каждые 300 секунд. (5 минут), и клиент отвечал ACK, и это не давало брандмауэру рассматривать это как простое соединение и уничтожать его. Если клиент был мертв, после 10 зондов сервер прервал соединение. К нашему удивлению, бездействующие, но живые соединения, как и раньше, обрываются примерно через 40 минут.
Wireshark, запущенный на стороне клиента, не показывает никаких сообщений поддержки активности между сервером и клиентом, даже если пакеты поддержки активности включены на сервере.
Что здесь могло происходить?
Если настройки keepalive на сервере: time = 300, intvl = 180, probes = 10, я бы ожидал, что если клиент жив, но бездействует, сервер будет отправлять зонды keepalive каждые 300 секунд и оставить соединение в покое, и если клиент мертв, он отправит один через 300 секунд, затем еще 9 зондов каждые 180 секунд, прежде чем разорвать соединение. Я прав?
Одна из возможностей заключается в том, что брандмауэр каким-то образом перехватывает зонды поддержки активности от сервера и не может передать их клиенту, а тот факт, что он получил зонд, заставляет его думать, что соединение активно. Это обычное поведение для брандмауэра? Мы не знаем, какой это брандмауэр.
Сервер является узлом Teradata, и соединение осуществляется от клиентской утилиты Teradata к серверу базы данных, порт 1025 на стороне сервера, но мы видели ту же проблему с SSH-соединением, поэтому мы думаем, что это влияет на все TCP-соединения.
Межсетевой экран с отслеживанием состояния проверяет пакеты, а также подтверждает, живо ли соединение. Я считаю, что настройки брандмауэра должны быть точно настроены так же, как и на компьютерах. По умолчанию многие брандмауэры открывают неактивные соединения только в течение 60 минут, но это время может меняться в зависимости от поставщика.
Некоторые поставщики будут иметь такие функции, как TCP Intercept, TCP State Bypass и Dead Connection Detection, которые позволят обрабатывать особые ситуации, подобные вашей.
Другой вариант - настроить сам брандмауэр с теми же параметрами, что и на серверах, чтобы убедиться, что все согласовано.
На брандмауэре cisco у вас есть следующая команда для его настройки.
hostname (config) # timeout время функции
timeout conn hh: mm: ss - время простоя, по истечении которого соединение закрывается, от 0: 5: 0 до 1193: 0: 0. По умолчанию - 1 час (1: 0: 0).
у вас есть несколько параметров в соответствии с вашими потребностями.
Я бы посоветовал поговорить с командой, которая управляет брандмауэром, и настроить тайминги в соответствии с вашими потребностями или проверить функциональность.