Tcp_tw_recycle / reuse öğesini 1 olarak ayarlamanın sonuçları nelerdir?


10

Yapılandırma dosyamda hem tcp_tw_recycle / reuse 1'i ayarladım.

Bunu yapmanın sonuçları nelerdir?

Bir tcp soketi yeniden kullanılırsa, bu bir güvenlik riski oluşturur mu? yani 2 farklı bağlantı potansiyel olarak veri gönderebiliyor mu?

Küçük bir yeniden bağlantı şansı olan kısa ömürlü bağlantılar için uygun mu?


Açık olan soru, bu değişiklikten ne kazanmayı bekliyorsunuz?
Robert Munteanu

1
@RobertMunteanu ile ilgili: serverfault.com/questions/342501/…
codecompleting

Yanıtlar:


24

Varsayılan olarak, her ikisi de tcp_tw_reuseve tcp_tw_recycledevre dışı bırakıldığında, çekirdek TIME_WAITdurumdaki soketlerin bu durumda yeterince uzun süre kalmasını sağlar - gelecekteki bağlantılara ait paketlerin eski bağlantının geç paketleriyle karıştırılmayacağından emin olmak için yeterince uzun.

Etkinleştirdiğinizde tcp_tw_reuse, TIME_WAITdurumdaki soketler zaman aşımına uğramadan kullanılabilir ve çekirdek TCP sıra numaraları ile ilgili bir çakışma olmadığından emin olmaya çalışır. Etkinleştirdiğinizde tcp_timestamps(diğer adıyla PAWS, Sarılmış Sıra Numaralarına Karşı Koruma için), bu çarpışmaların gerçekleşmeyeceğinden emin olacaktır. Ancak, TCP zaman damgalarının her iki uçta da etkinleştirilmesi gerekir (en azından benim anlayışım budur). Bkz tcp_twsk_unique tanımını kanlı detaylar için.

Etkinleştirdiğinizde tcp_tw_recycle, çekirdek çok daha agresif olur ve uzak ana bilgisayarlar tarafından kullanılan zaman damgalarında varsayımlar yapar. Bağlantısı olan her uzak ana bilgisayar tarafından kullanılan son zaman damgasını izler TIME_WAIT) ve zaman damgası doğru bir şekilde artmışsa bir soketin yeniden kullanılmasına izin verir. Ancak, ana bilgisayar tarafından kullanılan zaman damgası değişirse (yani zaman içinde geri döner), SYNpaket sessizce kesilir ve bağlantı kurulmaz ("bağlantı zaman aşımına" benzer bir hata görürsünüz). Çekirdek koduna dalmak istiyorsanız , tcp_timewait_state_process tanımı iyi bir başlangıç ​​noktası olabilir.

Şimdi, zaman damgaları asla zamanda geri gitmemelidir; olmadıkça:

  • ana bilgisayar yeniden başlatılır (ancak daha sonra geri geldiğinde, TIME_WAITsoketin muhtemelen süresi dolmuş olacaktır, bu yüzden bir sorun olmayacaktır);
  • IP adresi başka bir şey tarafından hızlı bir şekilde yeniden kullanılır ( TIME_WAITbağlantılar biraz kalacaktır, ancak diğer bağlantılar muhtemelen etkilenecek TCP RSTve bu da bir miktar alan açacaktır);
  • bağlantının ortasında ağ adresi çevirisi (veya smarty-pantolon güvenlik duvarı) yer alır.

İkinci durumda, aynı IP adresinin arkasında birden fazla ana makineye sahip olabilirsiniz ve bu nedenle, farklı zaman damgaları dizileri (veya, söz konusu zaman damgaları güvenlik duvarı tarafından her bağlantıda rastgele seçilir). Bu durumda, bazı ana bilgisayarlar rasgele bağlanamaz, çünkü bunlar TIME_WAITsunucunun grubunun daha yeni bir zaman damgasına sahip olduğu bir bağlantı noktasına eşlenir . Bu nedenle dokümanlar size "NAT cihazları veya yük dengeleyicileri ayar nedeniyle bırakma çerçeveleri başlatabilir" diyor.

Bazı insanlar için tavsiye terk tcp_tw_recycleyalnız ama etkinleştirmek tcp_tw_reuseve alttcp_timewait_len . Ben hemfikirim :-)


büyük açıklama
yanglei

6

Bu beni ısırdı, belki birisi acı ve ıstırabımdan yararlanabilir. İlk olarak, çok fazla bilgi içeren ilgili bir bağlantı: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

Özellikle:

Bu dokümantasyon eksikliğinin tek sonucu, TIME-WAIT durumundaki giriş sayısını azaltmak için her iki ayarı da 1'e ayarlamayı öneren çok sayıda ayar kılavuzu bulmamızdır. Ancak, tcp (7) kılavuz sayfasında belirtildiği gibi, net.ipv4.tcp_tw_recycle seçeneği, aynı NAT cihazının arkasındaki iki farklı bilgisayardan gelen bağlantıları işlemeyeceği için halka açık sunucular için oldukça sorunludur; tespit ve sizi ısırmayı bekliyor:

Müşterilerin MySql NDB kümesine olabildiğince düşük gecikme süresi, haproxy bağlantısı sağlaması için oldukça etkin bir şekilde etkinleştirilmesini kullandım. Bu özel bir buluttaydı ve herhangi birinden hiçbir bağlantıya karışımda herhangi bir NAT türü yoktu. Kullanım durumu mantıklıdır, NDB'ye haproksi yoluyla isabet eden yarıçaplı müşteriler için gecikmeyi mümkün olduğunca azaltın. Öyle.

Bunu bir kamuya bakan haproxy sistemi, yük dengeleme web trafiği üzerinde, gerçekten etkiyi (aptal, doğru ?!) incelemeden yaptım ve çok fazla sorun giderme ve hayalet peşinde koştuktan sonra keşfettim:

  • NAT aracılığıyla bağlanan istemciler için kargaşa yaratacaktır.
  • Tanımlamak neredeyse imkansızdır, çünkü tamamen rastgele, aralıklı ve semptomlar müşteri A'ya, müşteri B'den tamamen farklı (veya değil) çarpacaktır.

Müşteri tarafında, bazen burada ve orada, bazen de uzun süreler boyunca SYN paketlerine artık yanıt alamadıkları süreleri göreceklerdir. Yine, rastgele.

Buradaki kısa hikaye, son zamanlardaki acı verici deneyimimde, rolüne bakılmaksızın bunları halka açık sunucularda yalnız bırakma / devre dışı bırakma!


4

'Man 7 tcp' den bunu göreceksiniz:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

Orada fazla yardım yok. Bu uestionun bazı iyi fikirleri var:

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

Ancak, yeniden kullanımın neden geri dönüşümden daha güvenli olduğu konusunda özel bilgi değil. Temel cevap şudur: tcp_tw_reuse, aynı TCP parametrelerine sahip TIME_WAIT içinde zaten bir tane varsa ve daha fazla trafik beklenmeyen bir durumda ise aynı soketin kullanılmasına izin verecektir (Bir FIN gönderildiğinde olduğuna inanıyorum) ). Diğer yandan tcp_tw_recycle, TIME_WAIT içindeki soketleri durumdan bağımsız olarak aynı parametrelerle yeniden kullanacak ve bu durum farklı paketler bekleyebilecek durumlu güvenlik duvarlarını karıştırabilir.

tcp_tw_reuse belgelenen SO_REUSEADDR yuva seçeneği ayarlayarak kodunda seçici yapılabilir man 7 socketörneğin:

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.

1
Bunun SO_REUSEADDRile bağlantılı olduğundan emin misiniz tcp_tw_reuse? Gibi bildiğim kadarıyla, SO_REUSEADDRistediğiniz zaman geçerlidir bind()ederken, tcp_tw_reuseyerel bir soket limanını yeniden çekirdek talimat verir TIME_WAIT, yeni bir giden bağlantı oluşturmak gerekiyorsa devlet.
jpetazzo

Hayır emin değilim. :-P
SpamapS
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.