TCP / IP sıfırlama (RST) bayrağının gönderilmesine ne sebep olur?

123

Uygulamamın TCP / IP bağlantısının neden her 10 dakikada bir (tam olarak 1-2 saniye içinde) kesintiye uğradığını anlamaya çalışıyorum. Wireshark'ı çalıştırdım ve 10 dakikalık hareketsizlikten sonra diğer ucun sıfırlama (RST) bayrağı ayarlanmış bir paket gönderdiğini keşfettim. Bir Google araması bana "RESET bayrağı alıcının kafasının karıştığını ve bu nedenle bağlantıyı kesmek istediğini gösterir" diyor, ancak bu ihtiyacım olan ayrıntıdan biraz daha az. Buna ne sebep olabilir? Ve yol boyunca bir yönlendiricinin bundan sorumlu olması mümkün mü yoksa bu her zaman diğer uç noktadan mı gelir?

Düzenleme: Bilgisayarımla diğer uç nokta arasında oturan bir yönlendirici (özellikle bir Linksys WRT-54G) var - yönlendirici ayarlarında aramam gereken bir şey var mı?

networking tcp

— Luke
kaynak

13

İşte bir tane daha: Comcast

— Tom Ritter

1

Neyse ki, bu bir LAN içinde gerçekleştiği için Comcast'e bağımlılığım yok. Keşke suçu bu kadar kolayca değiştirebilseydim;)

— Luke

Bunu hiç çözdün mü? Yorum yapamam çünkü yeterince puanım yok, ama bende seninle aynı sorun var ve bir düzeltme arıyorum.

Bu özel durum hangi hizmeti ifade ediyor? Yuvada (uygulama düzeyinden) canlı tutmayı ayarlamak mümkün olabilir, bu nedenle uzun boşta kalma süreleri, kaynak eksikliği nedeniyle bir kişinin (ortada veya değil) bir bağlantıyı sıfırlamaya zorlamasına neden olmaz.

— arielf

"Comcast" mi diyorsun? : D Bu ilgili depoya

— göz atın

89

Bir 'yönlendirici' herhangi bir şey yapıyor olabilir - özellikle NAT, trafikle herhangi bir miktarda hata içeren karışıklık içerebilir ...

Bir cihazın RST göndermesinin bir nedeni, kapalı bir soket için bir paket almaya yanıttır.

Kesin ama genel bir cevap vermek zordur, çünkü başlangıcından beri TCP üzerinde olası her sapkınlık ziyaret edilmiştir ve her türden insan trafiği engellemek için RST'leri ekliyor olabilir. (Örneğin, bazı 'ulusal güvenlik duvarları' bu şekilde çalışır.)

— Will Dean
kaynak

6

Yönlendiricinin TCP bağlantıları için 10 dakikalık bir zaman aşımı vardır veya yönlendiricide "ağ geçidi akıllı paket algılama" etkinleştirilmiştir.

— David Schwartz

2

Bir yönlendiricinin hatalarla dolu olabileceğini öne sürmek biraz zengin.

— Lorne Markisi

23

RST'yi gönderenin eş mi yoksa ortadaki biri mi olduğunu görmek için eşte bir paket dinleyicisi (örneğin, Wireshark) çalıştırın.

— Alexander
kaynak

14

Bu sorunu gidermek için epey zaman harcadım. Önerilen çözümlerin hiçbiri işe yaramadı. Sistem yöneticimizin yanlışlıkla aynı statik IP'yi farklı gruplara ait, ancak aynı ağda oturan iki alakasız sunucuya atadığı ortaya çıktı. Son sonuçlar, zaman zaman kesilen vnc bağlantıları, web sayfasını getirmek için birkaç kez yenilenmesi gereken tarayıcı ve diğer garip şeylerdi.

— OutputLogic
kaynak

7

Bazı güvenlik duvarları, bir bağlantı x dakika boyunca boşta kalırsa bunu yapar. Bazı ISS'ler, yönlendiricilerini de çeşitli nedenlerle bunu yapacak şekilde ayarlar.

Bu gün ve çağda, bu durumu incelikle halletmeniz (gerektiğinde yeniden kurmanız) gerekecektir.

— Brian Knoblauch
kaynak

2

Bağlantı yeniden kuruldu, sorun şu ki, kısa süreli bağlantı kesilmesi gereksiz bir uyarıya neden oluyor.

— Luke

1

Özellikle Cisco PIX / ASA ekipmanıyla ilgili sorunlar yaşadım. Varsayılan olarak özellikle kısa zaman aşımlarına sahiptirler. Daha ucuz ekipman bu açıdan genellikle "daha iyidir" (çünkü çok hızlı zaman aşımına uğramazlar) ...

— uğramazlar

1

Kalıcı bağlantılar açısından TCP'nin hiçbir zaman tamamen güvenilir olmadığını bile eklemek isterim. Zaman zaman daha belirgin hale geliyor. Bir başka ilginç örnek: Bazı kişiler, bağlantı kapanması veya sıfırlama algılanır algılanmaz bir TCP istemcisini çevrimdışı olarak işaretleyen mantığı uygulayabilir. Ve bazen bir müşteriye yeniden bağlanma şansı verme zahmetine girmezler. Bu açıkça tam olarak doğru değil.

— Victor Yarema

7

RST, son ACK'yı gönderen taraf olduğu için aktif kapatmayı yapan taraf tarafından gönderilir. Bu nedenle, pasif kapatmayı yanlış bir durumda yapan taraftan FIN alırsa, diğer tarafa bir hatanın oluştuğunu belirten bir RST paketi gönderir.

— Vishal Gupta
kaynak

6

Her iki taraf da normal bir kapanışta FIN gönderir ve alır. Bu durumda yanlış bir şey yok ve bu nedenle bir tarafın sıfırlama yapması için bir neden yok. İlk cümle mantıklı bile değil.

— Lorne Markisi

2

[RST, ACK], dinlenmeyen bir bağlantı noktasında SYN alan taraf tarafından da gönderilebilir. Karşılaştığım bir durumda, RST / ACK ilk SYN'den yaklaşık 60 saniye sonra geldi. FWIW

— Les

@MarquisofLorne, ilk cümlenin kendisi yanlış kabul edilebilir. Ama ikinci cümlede geçen "yanlış durumda" ifadesi onu bir şekilde geçerli kılıyor.

— Victor Yarema

7

NAT yapan bir yönlendirici, özellikle de az kaynak içeren düşük uçlu bir yönlendirici varsa, önce en eski TCP oturumlarını yaşlandıracaktır. Bunu yapmak için RST, paketteki, alıcı istasyona bağlantıyı kapatmasını (çok dikkatsizce) etkin bir şekilde söyleyen bayrağı ayarlar . bu kaynakları korumak için yapılır.

— MKII
kaynak

3

Dikkat edilmesi gereken bir nokta, birçok Linux ağ filtresi güvenlik duvarının yanlış yapılandırılmış olmasıdır.

Şuna benzer bir şeye sahipseniz:

-BİR İLERİ -m devlet - İLGİLİ, KURULUŞTURULDU -j KABUL

-A İLERİ -p tcp -j REDDET - tcp-reset ile reddetme

daha sonra paketlerin yeniden sıralanması, güvenlik duvarının paketlerin geçersiz olduğunu düşünmesine ve dolayısıyla sıfırlamalar oluşturmasına neden olabilir ve bu da aksi takdirde sağlıklı bağlantıları keser.

Yeniden sıralama, özellikle kablosuz bir ağda olasıdır.

Bunun yerine şöyle olmalıdır:

-BİR İLERİ -m devlet - İLGİLİ, KURULUŞTURULDU -j KABUL

-BİR İLERİ -m durum - durum GEÇERSİZ -j DÜŞTÜ

-A İLERİ -p tcp -j REDDET - tcp-reset ile reddetme

Temelde sahip olduğunuz her zaman:

... -m durum - İLGİLİ durum, KURULDU -j KABUL

hemen ardından gelmelidir:

... -m durum - durum GEÇERSİZ -j DAMLA

Bir paketi bırakmak, ardından tcp sıfırlamasını engelleyen potansiyel bir protokol oluşturmak daha iyidir. Sıfırlamalar, gönderilecek doğru şey olduklarında daha iyidir ... çünkü bu, zaman aşımlarını ortadan kaldırır. Ancak geçersiz olma ihtimalleri varsa, bu tür bir acıya neden olabilirler.

— Labirent
kaynak

0

Bunun nedeni, ağda TCP bağlantınıza RST gönderen başka bir işlem olmasıdır.

Normalde aşağıdaki durumda RST gönderilir

SO_LINGER seçeneğini kullanan soket etkinleştirildiğinde bir işlem soketi kapatır
İşletim sistemi, işleminiz soketi kapatmadan çıktığında kaynak temizliğini yapıyor.

Sizin durumunuzda, bir işlem bağlantınızı (IP + bağlantı noktası) bağlar ve bağlantı kurduktan sonra RST göndermeye devam eder.

— Ben
kaynak