Rasgele TCP RST'leri belirli web sitelerinde neler oluyor?

Kısa versiyon: Ağımdaki bir Windows Server 2012 makinesi, belirli web sitelerine bağlanırken ısrarcı fakat kesintili TCP RST'leri alıyor. Dunno nereden geliyorlar? Analizlerim ve sorularım için wireshark loglarına göz atın.

Uzun versiyon:

Sunucularımızdan birinde küçük ofisimize hizmet vermek için önbellekleme web proxy'si çalıştırıyoruz. Bir iş arkadaşı, belirli sitelere bağlanırken çok fazla 'Bağlantı Sıfırlama' veya 'Sayfa görüntülenemiyor' hataları aldığını bildirdi ancak bu yenileme genellikle onu düzeltir.

Tarayıcı davranışını doğruladım ve daha sonra doğrudan sunucunun kendisinde proxy olmayan bir tarayıcı deneyerek. Ancak sorunlu sitelere ping & traceroutes herhangi bir sorun göstermez, konular tcp bağlantıları ile sınırlı görünüyordu.

Daha sonra etkilenen siteleri doğrudan cURL yoluyla HTTP HEAD istekleri göndererek ve ne sıklıkta başarılı olduklarını kontrol ederek test etmek için bir komut dosyası yaptım. Tipik bir sınama şöyle görünür: (bu, doğrudan kötü sunucuda çalışan proksuz)

C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0     Response Code: NULL (0%)
20:22:02: Length: 0     Response Code: NULL (0%)
20:22:22: Length: 0     Response Code: NULL (0%)
20:22:42: Length: 0     Response Code: NULL (0%)
20:23:02: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174  Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0     Response Code: NULL (28.57%)
20:24:03: Length: 3171  Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173  Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172  Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0     Response Code: NULL (45.45%)

Uzun vadede taleplerin yalnızca yaklaşık% 60'ı başarılı olur, geri kalan hiçbir şey bir kıvrılma hata kodu ile cevap vermez: "cURL hatası (56): Arkadaşdan veri alınırken hata oluştu" Kötü davranış, web siteleri için tutarlı Test (hiçbir site daha önce hiç iyileşmedi ') ve oldukça ısrarcı, bir haftadır sorun giderme yapıyorum ve iş arkadaşlarım sorunun görünüşte aylardır orada olduğunu bildiriyorlar.

HEAD istek betiğini ağımızdaki diğer makinelerde test ettim: sorun yok, tüm bağlantılar test listemdeki tüm sitelere gidiyor. Sonra kişisel masaüstümde bir proxy kurdum ve HEAD isteklerini sorunlu sunucudan çalıştırdığımda tüm bağlantılar geçiyor. Yani sorun ne olursa olsun, bu sunucuya çok özel.

Daha sonra hangi web sitelerinin bağlantı-sıfırlama davranışını gösterdiğini izole etmeye çalıştım:

• İntranet sitelerimizden hiçbiri (192.168.xx) bağlantı bırakmadı.
• IPv6 sitesi yok, damla bağlantılarını test ettim. (Biz çift yığınlıyız)
• İnternetin küçük bir azınlık IPv4 sitesi bağlantıyı keser.
• Cloudflare'u CDN olarak kullanan her site (test ettiğim) bağlantıları keser. (ancak sorun cloudflare sitelerine özel görünmüyor)

Bu açı gerçekten işe yarayacak bir şey değildi, bu yüzden bir istek başarısız olduğunda neler olup bittiğini görmek için wireshark'ı kurdum. Başarısız bir HEAD isteği şöyle görünür: (burada daha büyük ekran görüntüsü: http://imgur.com/TNfRUtX )

127 48.709776000    192.168.1.142   192.33.31.56    TCP 66  52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000    192.33.31.56    192.168.1.142   TCP 66  http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000    192.168.1.142   192.33.31.56    TCP 54  52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000    192.168.1.142   192.33.31.56    HTTP    234 HEAD / HTTP/1.1 
131 48.740917000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000    192.33.31.56    192.168.1.142   TCP 60  http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000    192.33.31.56    192.168.1.142   TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000    192.33.31.56    192.168.1.142   TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897

Bunu okudum yolu (yanılıyorsam beni düzelt, bu gerçekten benim alanım değil):

• Web sunucusuyla bir tcp bağlantısı açtık
• web sunucusu ACK'lar
• HTTP HEAD isteği gönderildi
• Web sunucusu IP adresinden işaretlenen ve bağlantıyı kesen bir RST paketi var.
• Web sunucusu ACK gönderdi
• Web sunucusu, HEAD isteğine geçerli HTTP verileriyle yanıt vermeye çalışır (951 bayt yanıtı doğru HTTP başlığını içerir)
• Web sunucusu geçerli HTTP yanıtını yeniden iletir (birkaç saniye boyunca birkaç kez), ancak bağlantı RST olduğundan başarılı olamaz

Öyleyse, web sunucusu geçerli bir RST göndermişse, neden isteği doldurmaya çalışıyor? Web sunucusu RST'yi oluşturmadıysa, ne halt etti?

Denediğim hiçbir şeyin etkisi olmadı:

• NIC takımını devre dışı bırakma
• Ağ adaptörünü değiştirmek (yedek NIC'nin çalıştığı biliniyordu)
• Statik bir ip atama.
• İpv6'yı devre dışı bırakma.
• Jumbo çerçevelerin devre dışı bırakılması.
• Anahtarlarımızı ve yönlendiricimizi atlayarak sunucuyu bir gece doğrudan modemimize takmak.
• Windows güvenlik duvarını kapatma.
• TCP ayarlarını netsh ile sıfırlama
• Sunucudaki diğer tüm hizmetleri hemen hemen devre dışı bırakın. (Biz çoğunlukla dosya sunucusu olarak kullanıyoruz, ancak apache ve birkaç tane DB var)
• Masaya vurarak kafa (arka arkaya)

Sunucudaki bir şeyin RST paketlerini oluşturduğundan şüpheleniyorum , ancak hayatım boyunca bulamıyorum. Biliyormuşum gibi hissediyorum: neden sadece bu sunucu? VEYA neden sadece bazı web siteleri? çok yardımcı olurdu. Hala merak etmeme rağmen, giderek artan bir şekilde yörüngeden çıkmaya başladım ve başlıyorum.

Fikirler / Öneriler?

-Teşekkürler

Paket yakalama işleminizde olağandışı bir durum vardı: ECN bitleri, giden SYN paketinde ayarlandı.

Açık tıkanıklık bildirimi , ana makinelerin ağ tıkanıklığına daha hızlı tepki vermesini sağlayan IP protokolünün bir uzantısıdır. İlk önce 15 yıl önce İnternet’e tanıtıldı, ancak ilk konuşlandırıldığında dikkat çeken ciddi sorunlar vardı . Bunlardan en ciddi olanı, birçok güvenlik duvarının ECN bitleri ayarlanmış bir SYN paketi alırken paketleri düşürmesi veya bir RST döndürmesiydi .

Sonuç olarak, çoğu işletim sistemi ECN'yi varsayılan olarak devre dışı bıraktı, en azından giden bağlantılar için. Sonuç olarak, birçok sitenin (ve güvenlik duvarı satıcısı!) Güvenlik duvarlarını hiçbir zaman sabitlemediğinden şüpheleniyorum .

Windows Server 2012 piyasaya sürülünceye kadar. Microsoft bu işletim sistemi sürümünden başlayarak varsayılan olarak ECN'yi etkinleştirdi .

Maalesef, son hafızada hiç kimse İnternet sitelerinin ECN'ye verdiği yanıtları önemli bir şekilde test etmedi, bu yüzden 2000'li yılların başında görülen sorunların hala devam edip etmediğini ölçmek zor, ama bunun ve trafiğinizin en azından olduğundan şüpheleniyorum. zaman zaman, böyle bir ekipmandan geçerek.

Masaüstümde ECN'yi etkinleştirdikten ve Wireshark'ı çalıştırdıktan sonra, çoğu ana bilgisayar iyi çalışıyor gibi görünse de, RN aldığım bir ana bilgisayar örneğini yakalamamdan birkaç saniye önceydi. Belki gidip interneti kendim tararım ...

Sorunun çözülüp çözülmediğini görmek için sunucunuzda ECN'yi devre dışı bırakmayı deneyebilirsiniz. Bu ayrıca sizi DCTCP'yi kullanamaz hale getirecek, ancak küçük bir ofiste bunu yapmanız ya da yapmanız gerekme olasılığı çok düşük.

netsh int tcp set global ecncapability=disabled