Tidak ada respons terhadap beberapa paket SYN ketika cap waktu diaktifkan


9

Saya memiliki server TCP yang mendengarkan pada mesin ("server") yang menjalankan Ubuntu 12.04.3 (kernel 3.8.0-31-generic). Ini menerima koneksi dari 2 mesin klien yang berbeda. Mesin A menjalankan Ubuntu 12.04.4 (3.11.0-17-generik) dan mesin B menjalankan Ubuntu 11.10 (3.0.0-32-server).

Jika cap waktu TCP diaktifkan di server (sysctl net.ipv4.tcp_timestamps = 1) maka terkadang paket SYN dari mesin A "diabaikan". Menggunakan tcpdump di server (dalam mode non promiscuous) saya dapat melihat SYN tiba dengan baik dan dengan checksum yang benar - tidak ada respons - tidak ada SYN / ACK dan tidak ada RST. Mesin A mentransmisikan kembali SYN beberapa kali sebelum menyerah. Perangkat lunak klien yang berjalan pada mesin A (wget dalam kasus ini) segera mencoba kembali dengan koneksi baru dan berhasil, mendapatkan SYN / ACK instan.

Mesin B tidak memiliki masalah dengan server yang sama dan lalu lintasnya terlihat normal - ia menggunakan opsi TCP yang sama dengan mesin A juga (dari apa yang saya lihat dari file yang diambil). Menonaktifkan cap waktu TCP pada server membuat semuanya berfungsi sebagaimana mestinya.

Stempel waktu dalam paket SYN yang diabaikan tampaknya valid bagi saya, jadi saya tidak yakin mengapa mereka menyebabkan masalah atau apakah mereka yang menjadi penyebabnya.

Saya telah memasang pcap yang dianonimkan di sini https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap . Itu diambil di server (10.76.0.74) menunjukkan mesin A (10.4.0.76) berhasil melakukan HTTP GET (paket 1 hingga 10) dan kemudian 1 detik kemudian mencoba mengambil URL yang sama lagi (paket 11 hingga 17) tetapi sebagai gantinya SYN-nya diabaikan. Paket 18 hingga 27 adalah keberhasilan lain.

Saya menduga ini adalah masalah yang mirip dengan yang dijelaskan dalam " Mengapa server tidak mengirim paket SYN / ACK sebagai tanggapan terhadap paket SYN " dan sementara menonaktifkan cap waktu adalah solusi, saya ingin memahami apa yang sedang terjadi. Apakah ini hanya bug?

Tidak ada firewall lokal yang berjalan. Server menangani beberapa koneksi TCP (kira-kira 32 ribu pada satu waktu) tetapi memiliki banyak memori / CPU. Pada saat tes yang ditunjukkan di pcap tidak ada koneksi TCP lain antara mesin A dan server. Tidak ada tanda bahwa antrian penerimaan aplikasi server tiba-tiba terisi (selain itu akan mempengaruhi kedua klien saya anggap). Karena paket-paket terlihat OK dalam pcap yang diambil di server, sepertinya perangkat jaringan tidak melakukan hal-hal yang merusak.

Saya awalnya memposting ini di forum ubuntu tetapi di belakang ini mungkin lokasi yang lebih tepat. Berharap untuk mendapatkan petunjuk.

Jawaban:


5

Dalam kasus saya, perintah berikut memperbaiki masalah dengan tidak adanya balasan SYN / ACK dari server Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Saya pikir itu lebih benar daripada menonaktifkan cap waktu TCP, karena cap waktu TCP berguna setelah semua (PAWS, skala jendela, dll).

Dokumentasi pada tcp_tw_recyclesecara eksplisit menyatakan bahwa tidak disarankan untuk mengaktifkannya, karena banyak router NAT menyimpan stempel waktu dan karenanya PAWS masuk, karena stempel waktu dari IP yang sama tidak konsisten.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Semua mesin yang dipermasalahkan telah ditingkatkan dan saya yakin masalahnya tidak lagi terjadi sehingga saya tidak dapat mencoba ini sekarang. Namun dalam hal ini tidak ada NAT yang terlibat antara klien dan server. Sepertinya masih mencurigakan bagiku.
user133831
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.