TCP Keepalive та брандмауер вбивають простої сесії

На сайті клієнта команда мережі додала брандмауер між клієнтом і сервером. Це спричиняє відключення непрацюючих з’єднань приблизно через 40 хвилин простою. Люди в мережі говорять, що у брандмауера немає часу очікування з'єднання в режимі очікування, але факт полягає в тому, що з'єднання в режимі очікування порушуються.

Щоб обійти це, ми спершу налаштували сервер (машину Linux) із увімкненими кепальниками TCP з tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 та tcp_keepalive_probes = 30000. Це працює, і з'єднання залишаються життєздатними протягом днів і більше. Однак ми також хотіли б, щоб сервер виявив мертвих клієнтів і вбивство з'єднання, тому ми змінили налаштування на час = 300, intvl = 180, зонди = 10, думаючи, що якби клієнт був дійсно живий, сервер пробував би кожні 300 секунд (5 хвилин), і клієнт відповів би ACK, і це не дозволило брандмауеру бачити це як неробочий зв’язок і вбивати його. Якщо клієнт був мертвий, через 10 зондів, сервер перервав би з'єднання. На наш подив, простої, але живі зв’язки вбиваються приблизно через 40 хвилин, як раніше.

Wireshark, що працює на клієнтській стороні, не показує взагалі збереження між сервером і клієнтом, навіть якщо на сервері включено збереження.

Що може статися тут?

Якщо параметри keepalive на сервері час = 300, intvl = 180, зонди = 10, я б очікував, що якщо клієнт живий, але не працює, сервер буде надсилати зонди keepalive кожні 300 секунд і залишати з'єднання в спокої, і якщо клієнт мертвий, він надсилатиме один через 300 секунд, потім ще 9 зондів кожні 180 секунд, перш ніж вбити з'єднання. Чи правий я?

Можливість полягає в тому, що брандмауер якимось чином перехоплює датчики збереження з сервера і не передає їх клієнту, а той факт, що він отримав зонд, змушує думати, що з'єднання активне. Це звичайна поведінка для брандмауера? Ми не знаємо, який саме брандмауер задіяний.

Сервер - це вузол Teradata, і з'єднання здійснюється від клієнтської утиліти Teradata до сервера баз даних, порт 1025 на стороні сервера, але ми спостерігали ту ж проблему з SSH-з'єднанням, тому ми думаємо, що це впливає на всі TCP-з'єднання.

Державний брандмауер перевіряє пакети, а також підтверджує, чи з'єднання активне. Я вважаю, що брандмауер повинен також налаштовувати налаштування так само, як і комп'ютери. За замовчуванням багато брандмауерів залишають відкритими лише з'єднання в режимі очікування протягом 60 хвилин, але цей час може змінитися залежно від постачальника.

Деякі постачальники матимуть такі функції, як TCP Intercept, TCP State Bypass та Dead Connection Detection, які дозволять обробляти такі особливі ситуації, як ваша.

Інший варіант - налаштувати сам брандмауер з тими ж параметрами, що і у вас на серверах, щоб переконатися, що все відповідає.

На брандмауері cisco у вас є така команда, щоб налаштувати її.

ім'я хоста (конфігурація) # час очікування функції

timeout conn hh: mm: ss - час простою, після якого з'єднання закривається, між 0: 5: 0 і 1193: 0: 0. За замовчуванням - 1 година (1: 0: 0).

у вас є кілька параметрів відповідно до ваших потреб.

Я б радив поговорити з командою, яка керує брандмауером і регулює таймінги відповідно до ваших потреб або перевіряє функціональні можливості.