Losowe TCP RST na niektórych stronach internetowych, co się dzieje?

Krótka wersja: Jeden komputer z systemem Windows Server 2012 w mojej sieci staje się trwały, ale sporadyczny, gdy połączenia RST TCP są połączone z pewnymi stronami internetowymi. Nie wiem skąd pochodzą. Sprawdź dziennik wireshark dla mojej analizy i pytań.

Długa wersja:

Na jednym z naszych serwerów uruchamiamy buforujący serwer proxy w celu obsługi naszego małego biura. Współpracownik zgłosił występowanie wielu błędów „Resetuj połączenie” lub „Nie można wyświetlić strony” podczas łączenia się z niektórymi witrynami, ale odświeżenie zazwyczaj to naprawia.

Sprawdziłem zachowanie przeglądarki, a następnie bardziej bezpośrednio, wypróbowując przeglądarkę bez serwera proxy na samym serwerze. Ale pingi i traceroute do kłopotliwych stron nie wykazują żadnych problemów, wydawało się, że problemy ograniczają się do połączeń TCP.

Następnie stworzyłem skrypt do testowania dotkniętych stron, wysyłając im żądania HTTP HEAD bezpośrednio przez cURL i sprawdzając, jak często się to udaje. Typowy test wygląda następująco: (to nie przeszkadza, działa bezpośrednio na złym serwerze)

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%)

W dłuższej perspektywie tylko około 60% żądań się udaje, reszta nic nie zwraca, z kodem błędu zwijania się: „błąd cURL (56): Błąd podczas odbierania danych od elementu równorzędnego” Złe zachowanie jest spójne dla stron I test (żadna strona nigdy nie „poprawiła się”) i jest dość trwała, rozwiązuję problemy już od tygodnia, a współpracownicy zgłaszają, że problem istniał od miesięcy.

Testowałem skrypt żądania HEAD na innych komputerach w naszej sieci: bez problemów, wszystkie połączenia przechodzą do wszystkich stron na mojej liście testów. Następnie konfiguruję serwer proxy na moim osobistym pulpicie i kiedy uruchamiam żądania HEAD z problematycznego serwera, wszystkie połączenia przechodzą. Niezależnie od problemu, jest on bardzo specyficzny dla tego serwera.

Następnie próbowałem ustalić, które strony internetowe zachowują się podczas resetowania połączenia:

• Żadna z naszych witryn intranetowych (192.168.xx) nie odrzuca połączeń.
• Żadna witryna ipv6, w której testowałem, nie usuwa połączeń. (Mamy podwójny stos)
• Tylko niewielka część internetowych witryn ipv4 zrywa połączenia.
• Każda witryna, która korzysta z CloudFlare jako CDN (który testowałem) porzuca połączenia. (ale problem nie wydaje się występować wyłącznie w witrynach chmurowych)

Ten kąt nie przekształcił się w nic naprawdę pomocnego, więc następnie zainstalowałem wireshark, aby zobaczyć, co się dzieje, gdy żądanie nie powiedzie się. Nieudane żądania HEAD wyglądają tak: (większy zrzut ekranu tutaj: 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

Sposób, w jaki to czytam (popraw mnie, jeśli się mylę, to nie jest moja dziedzina):

• Otwieramy połączenie TCP z serwerem WWW
• ACK serwera sieci
• Żądanie HTTP HEAD zostało wysłane
• Istnieje pakiet RST, oznaczony jako z adresu IP serwera WWW, który zabija połączenie.
• Serwer WWW wysyła ACK
• Serwer WWW próbuje odpowiedzieć na żądanie HEAD prawidłowymi danymi HTTP (odpowiedź w bajcie 951 zawiera poprawny nagłówek HTTP)
• Serwer WWW retransmituje (kilka razy w ciągu kilku sekund) prawidłową odpowiedź HTTP, ale nie może się powieść, ponieważ połączenie zostało wykonane RST

Jeśli więc serwer sieciowy wysłał prawidłowy RST, dlaczego wciąż próbuje wypełnić żądanie? A jeśli serwer nie wygenerował RST, co do cholery zrobił?

Rzeczy, których próbowałem, nie przyniosły efektu:

• Wyłączanie zespołu kart sieciowych
• Wymiana karty sieciowej (wiadomo, że działała zastępcza karta sieciowa)
• Przypisywanie statycznego adresu IP.
• Wyłączanie ipv6.
• Wyłączanie ramek jumbo.
• Podłączanie serwera bezpośrednio do naszego modemu jednej nocy, omijając nasze przełączniki i router.
• Wyłączanie zapory systemu Windows.
• Resetowanie ustawień TCP przez netsh
• Wyłączanie praktycznie każdej innej usługi na serwerze. (Używamy go głównie jako serwera plików, ale jest apache i kilka baz danych)
• Walić głową w biurko (wielokrotnie)

Podejrzewam, że coś na serwerze generuje pakiety RST, ale przez całe życie nie mogę tego znaleźć. Czuję się, jakbym wiedział: dlaczego to tylko ten serwer? LUB dlaczego tylko niektóre strony internetowe? bardzo by to pomogło. Chociaż wciąż jestem ciekawy, coraz bardziej mam ochotę nuke z orbity i zacząć od nowa.

Pomysły / sugestie?

-Dzięki

Przechwytywanie pakietów miało coś niezwykłego: bity ECN zostały ustawione w wychodzącym pakiecie SYN.

Wyraźne powiadomienie o przeciążeniu jest rozszerzeniem protokołu IP, który pozwala hostom szybciej reagować na przeciążenie sieci. Po raz pierwszy wprowadzono go do Internetu 15 lat temu, ale zauważono poważne problemy podczas jego pierwszego wdrożenia. Najpoważniejszym z nich było to, że wiele zapór ogniowych albo upuszczało pakiety, albo zwracało RST po otrzymaniu pakietu SYN z zestawem bitów ECN.

W rezultacie większość systemów operacyjnych domyślnie wyłączała ECN, przynajmniej dla połączeń wychodzących. W rezultacie podejrzewam, że wiele witryn (i dostawców zapór ogniowych!) Po prostu nigdy nie naprawia swoich zapór ogniowych .

Do czasu wydania Windows Server 2012. Microsoft włączony domyślnie ECN, zaczynając od tej wersji systemu operacyjnego.

Niestety nikt w niedawnej pamięci nie przeprowadził żadnych znaczących testów odpowiedzi stron internetowych na ECN, więc trudno jest ocenić, czy problemy zaobserwowane na początku XXI wieku nadal występują, ale mocno podejrzewam, że tak jest i że ruch jest przynajmniej czasami przechodząc przez taki sprzęt.

Po włączeniu ECN na pulpicie i uruchomieniu Wiresharka minęło zaledwie kilka sekund, zanim złapałem przykład hosta, z którego dostałem RST do pakietu z zestawem SYN i ECN, chociaż większość hostów wydaje się działać dobrze. Może sam pójdę zeskanować Internet ...

Możesz spróbować wyłączyć ECN na serwerze, aby sprawdzić, czy problem zniknie. Uniemożliwi to również korzystanie z DCTCP, ale w małym biurze jest bardzo mało prawdopodobne, abyś to robił lub miał taką potrzebę.

netsh int tcp set global ecncapability=disabled