TCP Keepalive i firewall zabijają bezczynne sesje

W witrynie klienta zespół sieci dodał zaporę ogniową między klientem a serwerem. Powoduje to rozłączenie bezczynnych połączeń po około 40 minutach bezczynności. Ludzie z sieci twierdzą, że zapora nie ma limitu czasu bezczynnego połączenia, ale faktem jest, że bezczynne połączenia ulegają zerwaniu.

Aby obejść ten problem, najpierw skonfigurowaliśmy serwer (komputer z systemem Linux) z włączonymi utrzymywaniami TCP z tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 i tcp_keepalive_probes = 30000. Działa to, a połączenia pozostają opłacalne przez kilka dni lub dłużej. Chcielibyśmy jednak również, aby serwer wykrywał martwych klientów i zabijał połączenie, dlatego zmieniliśmy ustawienia na time = 300, intvl = 180, sondy = 10, myśląc, że gdyby klient rzeczywiście żył, serwer sprawdzałby co 300s (5 minut), a klient odpowie ACK, dzięki czemu zapora ogniowa nie zobaczy tego jako bezczynnego połączenia i nie zabije go. Gdyby klient nie żył, po 10 sondach serwer przerwałby połączenie. Ku naszemu zdziwieniu, bezczynne, ale żywe połączenia zostają zabite po około 40 minutach jak poprzednio.

Wireshark działający po stronie klienta w ogóle nie wyświetla żadnych zachowań między serwerem a klientem, nawet jeśli na serwerze są włączone zachowania.

Co może się tu dziać?

Jeśli ustawienia podtrzymania na serwerze to czas = 300, intvl = 180, sondy = 10, oczekiwałbym, że jeśli klient żyje, ale jest bezczynny, serwer będzie wysyłał sondy podtrzymania co 300 sekund i pozostawi połączenie w spokoju, a jeśli klient nie żyje, wysyła jeden po 300 sekundach, a następnie 9 kolejnych sond co 180 sekund przed zabiciem połączenia. Czy mam rację?

Jedną z możliwości jest to, że zapora sieciowa w jakiś sposób przechwytuje sondy podtrzymujące aktywność z serwera i nie przekazuje ich klientowi, a fakt, że dostał sondę, sprawia, że ​​myśli, że połączenie jest aktywne. Czy to typowe zachowanie zapory? Nie wiemy, jaki rodzaj zapory sieciowej jest zaangażowany.

Serwer jest węzłem Teradata, a połączenie pochodzi z narzędzia klienta Teradata do serwera bazy danych, port 1025 po stronie serwera, ale widzieliśmy ten sam problem z połączeniem SSH, więc uważamy, że wpływa on na wszystkie połączenia TCP.

Zapora stanowa sprawdza pakiety, a także potwierdza, czy połączenie jest aktywne. Uważam, że zapora ogniowa powinna również dokładnie dostosować ustawienia w taki sam sposób, jak komputery. Domyślnie wiele zapór sieciowych pozostawia otwarte bezczynne połączenia tylko przez 60 minut, ale ten czas może ulec zmianie w zależności od dostawcy.

Niektórzy dostawcy będą mieli takie funkcje, jak TCP Intercept, TCP State Bypass i Dead Connection Detection, które pozwolą poradzić sobie w szczególnych sytuacjach, takich jak Twoja.

Inną opcją jest skonfigurowanie samej zapory ogniowej z tymi samymi parametrami, które masz na serwerach, aby upewnić się, że wszystko jest spójne.

W zaporze cisco masz następujące polecenie, aby ją skonfigurować.

nazwa hosta (config) # limit czasu funkcja czas

timeout conn hh: mm: ss - Czas bezczynności, po którym połączenie zostanie zamknięte, między 0: 5: 0 a 1193: 0: 0. Domyślna wartość to 1 godzina (1: 0: 0).

masz wiele parametrów zgodnie ze swoimi potrzebami.

Radzę porozmawiać z zespołem zarządzającym zaporą ogniową i dostosować czasy w zależności od potrzeb lub sprawdzić funkcjonalność.