TCP Keepalive dan firewall membunuh sesi idle


10

Di situs pelanggan, tim jaringan menambahkan firewall antara klien dan server. Ini menyebabkan koneksi idle terputus setelah sekitar 40 menit waktu idle. Orang-orang jaringan mengatakan bahwa firewall tidak memiliki batas waktu koneksi idle, tetapi kenyataannya adalah koneksi idle rusak.

Untuk menyiasatinya, pertama-tama kita mengkonfigurasi server (mesin Linux) dengan TCP keepalives dinyalakan dengan tcp_keepalive_time = 300, tcp_keepalive_intvl = 300, dan tcp_keepalive_probes = 30000. Ini berfungsi, dan koneksi tetap bertahan selama berhari-hari atau lebih. Namun, kami juga ingin server mendeteksi klien yang mati dan mematikan koneksi, jadi kami mengubah pengaturan ke waktu = 300, intvl = 180, probe = 10, berpikir bahwa jika klien benar-benar hidup, server akan menyelidiki setiap 300-an (5 menit) dan klien akan merespons dengan ACK dan itu akan menjaga firewall dari melihat ini sebagai koneksi siaga dan membunuhnya. Jika klien sudah mati, setelah 10 probe, server akan membatalkan koneksi. Yang mengejutkan kami, koneksi idle tapi hidup terbunuh setelah sekitar 40 menit seperti sebelumnya.

Wireshark yang berjalan di sisi klien sama sekali tidak menunjukkan keepalives antara server dan klien, bahkan ketika keepalives diaktifkan di server.

Apa yang mungkin terjadi di sini?

Jika pengaturan keepalive di server adalah waktu = 300, intvl = 180, probe = 10, saya akan berharap bahwa jika klien masih hidup tetapi menganggur, server akan mengirim probe keepalive setiap 300 detik dan meninggalkan koneksi sendirian, dan jika klien sudah mati, itu akan mengirim satu setelah 300 detik, kemudian 9 probe lagi setiap 180 detik sebelum mematikan koneksi. Apakah saya benar?

Salah satu kemungkinan adalah bahwa firewall entah bagaimana mencegat probe keepalive dari server dan gagal untuk meneruskannya ke klien, dan fakta bahwa itu mendapat probe membuatnya berpikir bahwa koneksi aktif. Apakah ini perilaku umum untuk firewall? Kami tidak tahu jenis firewall apa yang terlibat.

Server adalah simpul Teradata dan koneksi dari utilitas klien Teradata ke server database, port 1025 di sisi server, tetapi kami telah melihat masalah yang sama dengan koneksi SSH jadi kami pikir itu mempengaruhi semua koneksi TCP.


2
Anda kehilangan deskripsi port atau protokol apa yang digunakan klien untuk terhubung ke server. Apakah itu SSH?
ewwhite

Mengidentifikasi firewall mungkin juga membantu.
Skaperen

3
Periksa apakah keepalive diaktifkan pada soket dengan menjalankan netstat --timers -tn dan periksa kata kunci "keepalive" (karena ini harus diaktifkan oleh perangkat lunak pada soket). Informasi lebih lanjut di sini: tldp.org/HOWTO/TCP-Keepalive-HOWTO/index.html Periksa nilai timer juga, nilai pertama adalah detik hingga paket keepalive berikutnya, dan yang ketiga adalah jumlah paket keepalive luar biasa yang menunggu jawab (jika saya ingat dengan benar)
Victor Jerlin


2
Orang-orang jaringan Anda mungkin salah. Jika mereka menggunakan firewall stateful, (mereka hampir pasti) entri diperlukan untuk setiap koneksi yang dibuat. Tanpa batas waktu idle, memori pada firewall akan bocor dan firewall pada akhirnya akan habis dan rusak. Mereka pasti memiliki batas waktu idle di suatu tempat ...
James Shewey

Jawaban:


1

Firewall statefull memeriksa paket-paket dan juga mengkonfirmasi apakah koneksi masih hidup. Saya percaya bahwa firewall juga harus memiliki pengaturan yang baik seperti komputer. Secara default banyak firewall hanya membiarkan koneksi siaga dibuka selama 60 menit tetapi kali ini mungkin berubah tergantung pada vendor.

Beberapa vendor akan memiliki fitur seperti TCP Intercept, TCP State Bypass, dan Dead Connection Detection yang akan memungkinkan untuk menangani situasi khusus seperti milik Anda.

Pilihan lain adalah mengkonfigurasi firewall itu sendiri dengan parameter yang sama yang Anda miliki di server untuk memastikan semuanya konsisten.

Pada firewall cisco Anda memiliki perintah berikut untuk mengkonfigurasinya.

hostname (config) # waktu fitur batas waktu

timeout conn hh: mm: ss — Waktu idle setelah koneksi ditutup, antara 0: 5: 0 dan 1193: 0: 0. Standarnya adalah 1 jam (1: 0: 0).

Anda memiliki banyak parameter sesuai dengan kebutuhan Anda.

Saya akan menyarankan untuk berbicara dengan tim yang mengelola firewall dan sesuaikan waktunya dengan kebutuhan Anda atau periksa fungsinya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.