TCP RST aleatorios en ciertos sitios web, ¿qué está pasando?

Versión corta: una máquina Windows Server 2012 en mi red se está volviendo TCP RST persistentes pero intermitentes cuando se conecta a ciertos sitios web. No sé de dónde vienen. Consulte el registro de Wirehark para ver mis análisis y preguntas.

Versión larga:

Ejecutamos un proxy web de almacenamiento en caché en uno de nuestros servidores para dar servicio a nuestra pequeña oficina. Un compañero de trabajo informó haber recibido muchos errores de 'Restablecimiento de conexión' o 'No se puede mostrar la página' al conectarse a ciertos sitios, pero esa actualización generalmente lo soluciona.

Verifiqué el comportamiento del navegador, y luego más directamente probando un navegador no proxy en el servidor. Pero los pings y traceroutes a sitios problemáticos no muestran ningún problema, los problemas parecían estar limitados a las conexiones tcp.

Luego hice un script para probar los sitios afectados enviándoles solicitudes HTTP HEAD directamente a través de cURL y comprobando con qué frecuencia tienen éxito. Una prueba típica se ve así: (esto no tiene proxy, se ejecuta directamente en el servidor defectuoso)

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

A largo plazo, solo alrededor del 60% de las solicitudes tienen éxito, el resto no devuelve nada, con un código de error curl de: "error cURL (56): error al recibir datos del igual" El mal comportamiento es consistente para los sitios web I prueba (ningún sitio ha "mejorado") y es bastante persistente, he estado solucionando problemas durante una semana y los compañeros de trabajo informan que el problema ha estado allí durante meses aparentemente.

Probé el script de solicitud HEAD en otras máquinas de nuestra red: no hay problemas, todas las conexiones pasan a todos los sitios en mi lista de prueba. Luego configuré un proxy en mi escritorio personal, y cuando ejecuto las solicitudes HEAD del servidor problemático, todas las conexiones pasan. Cualquiera sea el problema, es muy específico para este servidor.

Luego intenté aislar qué sitios web exhiben el comportamiento de restablecimiento de conexión:

• Ninguno de nuestros sitios de intranet (192.168.xx) interrumpe las conexiones.
• Ningún sitio ipv6 que he probado deja caer las conexiones. (Somos de doble pila)
• Solo una pequeña minoría de sitios de internet ipv4 desconecta conexiones
• Cada sitio que usa cloudflare como CDN (que he probado) deja caer las conexiones. (pero el problema no parece ser exclusivo de los sitios de Cloudflare)

Este ángulo no se estaba convirtiendo en algo realmente útil, por lo que luego instalé wireshark para ver qué sucedía cuando fallaba una solicitud. Las solicitudes HEAD fallidas se ven así: (captura de pantalla más grande aquí: 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

La forma en que estoy leyendo esto (corrígeme si me equivoco, esta no es realmente mi área) es que:

• Abrimos una conexión TCP al servidor web
• servidor web ACK's
• Se envía la solicitud HTTP HEAD
• Hay un paquete RST, marcado como desde la IP del servidor web, que mata la conexión.
• El servidor web envía ACK
• El servidor web (intenta) responder a la solicitud HEAD con datos HTTP válidos (la respuesta de 951 bytes contiene el encabezado HTTP correcto)
• El servidor web retransmite (varias veces durante varios segundos) la respuesta HTTP válida, pero no puede tener éxito ya que la conexión ha sido RST

Entonces, si el servidor web ha enviado un RST válido, ¿por qué sigue intentando completar la solicitud? Y si el servidor web no generó el RST, ¿qué diablos hizo?

Cosas que he probado que no han tenido efecto:

• Deshabilitar el equipo de NIC
• Cambio del adaptador de red (se sabía que la NIC de reemplazo funcionaba)
• Asignación de una ip estática.
• Deshabilitar ipv6.
• Deshabilitar marcos jumbo.
• Conectando el servidor directamente a nuestro módem una noche, evitando nuestros conmutadores y enrutadores.
• Desactivar el firewall de Windows.
• Restablecer la configuración de TCP a través de netsh
• Desactivar prácticamente cualquier otro servicio en el servidor. (Principalmente lo usamos como servidor de archivos, pero hay apache y un par de bases de datos)
• Golpeando la cabeza en el escritorio (repetidamente)

Sospecho que algo en el servidor está generando los paquetes RST, pero por mi vida no puedo encontrarlo. Siento que si lo supiera: ¿por qué es solo este servidor? ¿O por qué solo algunos sitios web? Ayudaría mucho. Aunque todavía tengo curiosidad, estoy cada vez más inclinado a atacar desde la órbita y comenzar de nuevo.

Ideas / Sugerencias?

-Gracias

La captura de su paquete tenía algo inusual: los bits ECN se configuraron en el paquete SYN saliente.

La notificación explícita de congestión es una extensión del protocolo IP que permite que los hosts reaccionen más rápidamente a la congestión de la red. Se introdujo por primera vez en Internet hace 15 años, pero se notaron problemas serios cuando se implementó por primera vez. El más grave de ellos fue que muchos firewalls soltarían paquetes o devolverían un RST al recibir un paquete SYN con los bits ECN establecidos.

Como resultado, la mayoría de los sistemas operativos desactivaron ECN de forma predeterminada, al menos para las conexiones salientes. Como resultado, sospecho que muchos sitios (¡y vendedores de cortafuegos!) Simplemente nunca arreglaron sus cortafuegos .

Hasta que se lanzó Windows Server 2012. Microsoft habilitó ECN de manera predeterminada a partir de esta versión del sistema operativo.

Desafortunadamente, nadie en la memoria reciente ha realizado pruebas significativas de las respuestas de los sitios de Internet a ECN, por lo que es difícil evaluar si los problemas observados a principios de la década de 2000 todavía existen, pero sospecho firmemente que lo son y que su tráfico es, al menos parte del tiempo, pasando por dicho equipo.

Después de habilitar ECN en mi escritorio y luego encender Wireshark, pasaron solo unos segundos antes de que captara un ejemplo de un host del que obtuve un RST a un paquete con SYN y ECN configurado, aunque la mayoría de los hosts parecen funcionar bien. Tal vez iré a explorar Internet yo mismo ...

Puede intentar deshabilitar ECN en su servidor para ver si el problema desaparece. Esto también hará que no pueda usar DCTCP, pero en una oficina pequeña es muy poco probable que lo esté haciendo o que tenga alguna necesidad de hacerlo.

netsh int tcp set global ecncapability=disabled