Случайные TCP RST на определенных сайтах, что происходит?

Краткая версия. Одна машина Windows Server 2012 в моей сети получает постоянный, но прерывистый TCP RST при подключении к определенным веб-сайтам. Не знаю, откуда они. Проверьте журнал wirehark для моего анализа и amp; вопросы.

Длинная версия:

Мы запускаем кэширующий веб-прокси на одном из наших серверов для обслуживания нашего небольшого офиса. Сотрудник сообщил, что при подключении к определенным сайтам появляется сообщение об ошибке «Сброс соединения» или «Страница не может быть отображено», но это обновление обычно исправляет его.

Я проверил поведение браузера, а затем более непосредственно, попробовав несертифицированный браузер на самом сервере. Но pings & traceroutes для проблемных сайтов не показывают никаких проблем, проблемы, казалось, были ограничены tcp-соединениями.

Затем я сделал скрипт для проверки затронутых сайтов, отправив им запросы HTTP HEAD напрямую через cURL & проверяя, как часто они преуспевают. Типичный тест выглядит следующим образом: (это неприступно, выполняется непосредственно на плохом сервере)

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

В долгосрочной перспективе только около 60% запросов преуспевают, остальные ничего не возвращают, с кодом ошибки curl: «cURL error (56):« Ошибка при получении данных от однорангового узла » Плохое поведение согласуется с тестируемыми веб-сайтами (ни один сайт никогда не становился лучше), и он довольно настойчив. У меня есть проблемы с устранением неисправностей в течение недели, и сотрудники сообщают, что проблема существует уже несколько месяцев.

Я протестировал скрипт запроса HEAD на других компьютерах в нашей сети: никаких проблем, все подключения проходят со всеми сайтами в моем тестовом списке. Затем я настроил прокси-сервер на своем личном рабочем столе, и когда я запускаю запросы HEAD с проблемного сервера, хотя он, все соединения проходят. Так что независимо от проблемы, это очень специфично для этого сервера.

Далее я попытался изолировать, какие веб-сайты демонстрируют поведение соединения-сброса:

  • Ни один из наших сайтов интрасети (192.168.x.x) не удаляет соединения.
  • Нет сайтов ipv6, на которых я тестировал, отключает соединения. (Мы двойные стеки)
  • Только небольшое количество интернет-сайтов ipv4 отключает подключения.
  • Каждый сайт, использующий cloudflare в качестве CDN (который я тестировал), отключает соединения. (но проблема, похоже, не является исключительной для облачных сайтов)

Этот угол не развивался во что-то действительно полезное, поэтому в следующем я установил wirehark, чтобы посмотреть, что происходит, когда запрос не удался. Неудачные запросы HEAD выглядят следующим образом: (более крупный снимок экрана здесь: 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

Как я это читаю (исправьте меня, если я ошибаюсь, это не моя область):

  • Мы открываем подключение tcp к веб-серверу
  • веб-сервер ACK
  • Запрос HTTP HEAD отправляется
  • Существует пакет RST, помеченный как IP-адрес веб-сервера, который убивает соединение.
  • Веб-сервер отправляет ACK
  • Веб-сервер (пытается) реагировать на запрос HEAD с действительными данными HTTP (ответ 951 байта содержит правильный HTTP-заголовок)
  • Повторная передача Webserver (несколько раз в течение нескольких секунд) действительного ответа HTTP, но это не может быть выполнено, поскольку соединение было RST

Итак, если веб-сервер отправил действительный RST, почему он продолжает пытаться заполнить запрос? И если веб-сервер не сгенерировал RST, что он сделал?

Вещи, которые я пробовал, которые не имели эффекта:

  • Отключение сетевого взаимодействия NIC
  • Измените сетевой адаптер (как было известно, сменилась сетевая плата)
  • Назначение статического ip.
  • Отключение ipv6.
  • Отключение jumbo-кадров.
  • Запуск сервера непосредственно в наш модем за одну ночь, минуя наши коммутаторы и amp; маршрутизатор.
  • Отключение брандмауэра Windows.
  • Сброс настроек TCP через netsh
  • Отключение практически любой другой службы на сервере. (В основном мы используем его как файловый сервер, но есть apache и amp; DB).
  • Откидная голова на столе (многократно)

Я подозреваю, что что-то на сервере генерирует RST-пакеты, но для жизни меня я не могу найти. Мне кажется, что если бы я знал: почему это только этот сервер? ИЛИ почему только некоторые веб-сайты? это очень помогло бы. Хотя мне все еще любопытно, я все больше склоняюсь к ядерному оружию с орбиты и amp; начать.

Идеи /Предложения?

-Спасибо

34 голоса | спросил Morty 4 22014vEurope/Moscow11bEurope/MoscowTue, 04 Nov 2014 05:24:27 +0300 2014, 05:24:27

1 ответ


38

У вашего захвата пакетов было что-то необычное: биты ECN были установлены в исходящем пакете SYN. ​​

Явное уведомление о перегрузке - это расширение IP-протокола, которое позволяет хостам реагировать больше быстро к перегрузке сети. Он был впервые представлен в Интернете 15 лет назад, но были серьезные проблемы , отмеченные, когда он был впервые развернут. Самым серьезным из них было то, что многие брандмауэры либо отбрасывают пакеты, либо возвращают RST при получении пакета SYN с установленными битами ECN.

В результате большинство операционных систем отключили ECN по умолчанию, по крайней мере, для исходящих соединений. В результате я подозреваю, что многие сайты (и поставщики брандмауэров!) Просто никогда не исправили свои брандмауэры .

Пока не был выпущен Windows Server 2012. Microsoft включен ECN по умолчанию , начиная с этой версии операционной системы.

К сожалению, в последнее время никто не делал никаких значительных испытаний ответов интернет-сайтов на ECN, поэтому трудно определить, сохранились ли проблемы, обнаруженные в начале 2000-х годов, но я сильно подозреваю, что они есть и что ваш трафик , по крайней мере, некоторое время, проходя через такое оборудование.

После включения ECN на моем рабочем столе и последующего запуска Wireshark прошло всего несколько секунд, прежде чем я поймал пример узла, из которого я получил RST для пакета с набором SYN и ECN, хотя большинство хостов работают нормально , Возможно, я сам скачу в Интернет ...

Вы можете попробовать отключить ECN на своем сервере, чтобы узнать, очищается ли проблема. Это также сделает вас неспособным использовать DCTCP, но в небольшом офисе маловероятно, что вы это сделаете или вам нужно это сделать.

netsh int tcp set global ecncapability=disabled
ответил Michael Hampton 4 22014vEurope/Moscow11bEurope/MoscowTue, 04 Nov 2014 06:17:41 +0300 2014, 06:17:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132