Apa yang menyebabkan flag TCP / IP reset (RST) dikirim?

123

Saya mencoba mencari tahu mengapa koneksi TCP / IP aplikasi saya terus tersendat setiap 10 menit (tepatnya, dalam 1-2 detik). Saya menjalankan Wireshark dan menemukan bahwa setelah 10 menit tidak aktif, ujung lainnya mengirim paket dengan set flag reset (RST). Pencarian google memberi tahu saya "tanda RESET menandakan bahwa penerima telah menjadi bingung dan ingin membatalkan koneksi" tetapi itu sedikit kurang dari detail yang saya butuhkan. Apa yang menyebabkan ini? Dan apakah mungkin bahwa beberapa router di sepanjang jalan yang bertanggung jawab untuk itu atau apakah ini selalu datang dari titik akhir yang lain?

Sunting: Ada sebuah router (khususnya Linksys WRT-54G) yang berada di antara komputer saya dan titik akhir lainnya - apakah ada yang harus saya cari di pengaturan router?

networking tcp

— Luke
sumber

12

Ini satu lagi: Comcast

— Tom Ritter

1

Heh untungnya saya tidak memiliki ketergantungan pada Comcast karena ini terjadi dalam LAN. Saya berharap saya bisa mengalihkan kesalahan semudah itu;)

— Luke

Apakah Anda pernah memikirkan ini? Saya tidak dapat berkomentar karena saya tidak memiliki cukup poin, tetapi saya memiliki masalah yang sama persis dengan yang Anda alami dan saya sedang mencari perbaikan.

Layanan apa yang dirujuk oleh kasus khusus ini? Dimungkinkan untuk menyetel keepalive pada soket (dari level aplikasi) sehingga periode idle yang lama tidak mengakibatkan seseorang (di tengah atau tidak) mencoba memaksa penyetelan ulang koneksi karena kurangnya sumber daya.

— arielf

"Comcast" katamu? : D Lihat repo terkait ini: github.com/tylertreat/comcast

— joonas.fi

89

Sebuah 'router' dapat melakukan apa saja - terutama NAT, yang mungkin melibatkan sejumlah bug yang dipenuhi bug dengan lalu lintas ...

Salah satu alasan perangkat akan mengirim RST adalah sebagai tanggapan atas penerimaan paket untuk soket tertutup.

Sulit untuk memberikan jawaban yang tegas tetapi umum, karena setiap kemungkinan penyimpangan telah dikunjungi pada TCP sejak awal, dan semua jenis orang mungkin memasukkan RST dalam upaya untuk memblokir lalu lintas. (Beberapa 'firewall nasional' berfungsi seperti ini, misalnya.)

— Will Dean
sumber

6

Mungkin router memiliki waktu tunggu 10 menit untuk koneksi TCP atau router telah mengaktifkan "deteksi paket pintar gateway".

— David Schwartz

2

Agak kaya untuk menunjukkan bahwa router mungkin penuh bug.

— Marquis dari Lorne

23

Jalankan packet sniffer (misalnya, Wireshark) juga di peer untuk melihat apakah peer yang mengirim RST atau seseorang di tengah.

— Alexander
sumber

14

Saya baru saja menghabiskan beberapa waktu untuk memecahkan masalah ini. Tidak ada solusi yang diusulkan yang berhasil. Ternyata sysadmin kami secara tidak sengaja menetapkan IP statis yang sama ke dua server yang tidak terkait milik grup yang berbeda, tetapi duduk di jaringan yang sama. Hasil akhirnya adalah koneksi vnc terputus, browser yang harus di-refresh beberapa kali untuk mengambil halaman web, dan hal-hal aneh lainnya.

— OutputLogic
sumber

7

Beberapa firewall melakukannya jika sambungan menganggur selama x beberapa menit. Beberapa ISP mengatur router mereka untuk melakukan itu karena berbagai alasan juga.

Di zaman sekarang ini, Anda harus dengan anggun menangani (membangun kembali sesuai kebutuhan) kondisi itu.

— Brian Knoblauch
sumber

2

Sambungan dibuat kembali dengan baik, masalahnya adalah bahwa jangka waktu pemutusan yang singkat menyebabkan peringatan yang tidak perlu.

— Lukas

1

Saya mengalami masalah khusus dengan peralatan Cisco PIX / ASA. Mereka memiliki waktu tunggu yang sangat singkat sebagai default. Peralatan yang lebih murah biasanya "lebih baik" dalam hal ini (karena mereka tidak kehabisan waktu dengan sangat cepat) ...

— Brian Knoblauch

1

Saya bahkan akan menambahkan bahwa TCP tidak pernah benar-benar dapat diandalkan dari sudut pandang koneksi persisten. Itu menjadi lebih terlihat dari waktu ke waktu. Contoh menarik lainnya: beberapa orang mungkin mengimplementasikan logika yang menandai klien TCP sebagai offline segera setelah penutupan atau reset koneksi terdeteksi. Dan terkadang mereka tidak mau repot-repot memberi klien kesempatan untuk terhubung kembali. Ini jelas tidak sepenuhnya benar.

— Victor Yarema

7

RST dikirim oleh sisi yang melakukan tutup aktif karena itu adalah sisi yang mengirimkan ACK terakhir. Jadi jika menerima FIN dari sisi yang melakukan penutupan pasif dalam keadaan yang salah, ia mengirimkan paket RST yang menunjukkan sisi lain bahwa kesalahan telah terjadi.

— Vishal gupta
sumber

6

Kedua belah pihak mengirim dan menerima FIN dalam penutupan normal. Tidak ada yang salah dengan situasi ini, dan karena itu tidak ada alasan bagi satu pihak untuk mengeluarkan pengaturan ulang. Kalimat pertama bahkan tidak masuk akal.

— Marquis dari Lorne

2

[RST, ACK] juga dapat dikirim oleh pihak yang menerima SYN pada port yang tidak didengarkan. Dalam kasus yang saya temui, RST / ACK muncul sekitar 60 detik setelah SYN pertama. FWIW

— Les

@ MarquisofLorne, kalimat pertama itu sendiri dapat dianggap tidak benar. Tetapi frasa "dalam keadaan yang salah" di kalimat kedua membuatnya valid.

— Victor Yarema

7

Jika ada router yang melakukan NAT, terutama router low end dengan sumber daya yang sedikit, maka sesi TCP terlama akan berusia terlebih dahulu. Untuk melakukan ini, ia menetapkan RSTbendera dalam paket yang secara efektif memberi tahu stasiun penerima untuk (sangat ungracefully) menutup koneksi. ini dilakukan untuk menghemat sumber daya.

— MKII
sumber

3

Satu hal yang harus diperhatikan adalah banyak firewall netfilter Linux yang salah konfigurasi.

Jika Anda memiliki sesuatu seperti:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

-A MAJU -p tcp -j TOLAK --tolak-dengan tcp-reset

maka penyusunan ulang paket dapat mengakibatkan firewall menganggap paket tidak valid dan dengan demikian menghasilkan setel ulang yang kemudian akan memutus koneksi yang sehat.

Penataan ulang kemungkinan besar terjadi dengan jaringan nirkabel.

Ini seharusnya:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

-A FORWARD -m state --state INVALID -j DROP

-A MAJU -p tcp -j TOLAK --tolak-dengan tcp-reset

Pada dasarnya kapan pun Anda memiliki:

... -m state --state RELATED, ESTABLISHED -j ACCEPT

itu harus segera diikuti oleh:

... -m state --state INVALID -j DROP

Lebih baik membuang paket kemudian menghasilkan protokol yang berpotensi mengganggu pengaturan ulang tcp. Penyetelan ulang lebih baik jika terbukti mengirim hal yang benar ... karena ini menghilangkan batas waktu. Tetapi jika ada kemungkinan mereka tidak valid maka mereka dapat menyebabkan rasa sakit seperti ini.

— Labirin
sumber

0

Ini karena ada proses lain di jaringan yang mengirimkan RST ke koneksi TCP Anda.

Biasanya RST akan dikirim dalam kasus berikut

Sebuah proses menutup soket saat soket menggunakan opsi SO_LINGER diaktifkan
OS sedang melakukan pembersihan sumber daya saat proses Anda keluar tanpa menutup soket.

Dalam kasus Anda, sepertinya sebuah proses sedang menghubungkan koneksi Anda (IP + port) dan terus mengirimkan RST setelah membuat koneksi.

— Ben
sumber