Pregunta Solución de problemas de sitios web dentro de la red local


Tener un sitio web externo que se abra bien en algunas PC, sin embargo, parece tener un tiempo de espera (o síntomas de tiempo de espera, pero en realidad nunca lo hace) en otras.

Parece afectar solo (algunos) de nuestros nuevos Estaciones de trabajo HP Pro 3305 MT. Todos los cuales ejecutan Win7 32bit SP1 con todas las actualizaciones. Las PC más antiguas (Win7 32bit SP1 y WinXP) no se ven afectadas.

Usar Google Chrome y Firefox no hace ninguna diferencia. Abrir el sitio web en el Modo de compatibilidad de IE9 tiene exactamente los mismos síntomas.

Todas las PC están en la misma red local (Grupo de trabajo) usando el mismo servidor DNS y puerta de enlace (interno) en la misma conexión a Internet, en la misma subred. No hay servidor proxy, no hay filtrado de contenido, no hay balanceo de carga, etc. Solo la política de grupo vigente (localmente) es para la programación de actualizaciones. Los firewalls locales son todos iguales (Kaspersky WP4) y nuestro firewall externo no tiene configuraciones IP específicas.

No tengo control sobre el sitio web externo, traceroute muestra el mismo destino en todas las PC. Es un sitio web bastante popular en nuestra industria (Horticultura) y no conozco a ninguna otra persona (incluso a otros sitios dentro de nuestras compañías hermanas) con el mismo problema.

Actualizar: ¿Fiddler2 usado para monitorear la solicitud HTTP, parece que no se está cumpliendo por alguna razón?

Solicitud enviada:

GET http://www.rhs.org.uk/ HTTP/1.1
Host: www.rhs.org.uk
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Registro de Fiddler 2 de la solicitud:

This session is not yet complete. Press F5 to refresh when session is complete for updated statistics.

Request Count:   1
Bytes Sent:      567        (headers:567; body:0)
Bytes Received:  0      (headers:0; body:0)

ACTUAL PERFORMANCE
--------------
ClientConnected:    17:02:33.720
ClientBeginRequest: 17:02:39.118
GotRequestHeaders:  17:02:39.118
ClientDoneRequest:  17:02:39.118
Determine Gateway:  0ms
DNS Lookup:         0ms
TCP/IP Connect: 46ms
HTTPS Handshake:    0ms
ServerConnected:    17:02:39.165
FiddlerBeginRequest:    17:02:39.165
ServerGotRequest:   17:02:39.165
ServerBeginResponse:    00:00:00.000
GotResponseHeaders: 00:00:00.000
ServerDoneResponse: 00:00:00.000
ClientBeginResponse:    00:00:00.000
ClientDoneResponse: 00:00:00.000


RESPONSE BYTES (by Content-Type)
--------------
~headers~:  0

Registro de una solicitud exitosa de una PC en funcionamiento (hecho esta mañana, disculpe las marcas de tiempo que son diferentes a las anteriores):

Request Count:   1
Bytes Sent:      493        (headers:493; body:0)
Bytes Received:  20,413     (headers:525; body:19,888)

ACTUAL PERFORMANCE
--------------
ClientConnected:    08:22:47.766
ClientBeginRequest: 08:22:47.766
GotRequestHeaders:  08:22:47.766
ClientDoneRequest:  08:22:47.766
Determine Gateway:  0ms
DNS Lookup:         26ms
TCP/IP Connect: 30ms
HTTPS Handshake:    0ms
ServerConnected:    08:22:47.828
FiddlerBeginRequest:    08:22:47.828
ServerGotRequest:   08:22:47.828
ServerBeginResponse:    08:22:48.905
GotResponseHeaders: 08:22:48.905
ServerDoneResponse: 08:22:48.905
ClientBeginResponse:    08:22:48.905
ClientDoneResponse: 08:22:48.905

    Overall Elapsed:    00:00:01.1388020

RESPONSE BYTES (by Content-Type)
--------------
text/html:  19,888
~headers~:  525

Así que mi pregunta se ha convertido en:

¿Cuál es la diferencia entre las 2 solicitudes y cómo puedo determinar por qué 1 PC no recibe una respuesta a su solicitud GET?

Actualización 2:

Vea mi respuesta a continuación. Puede que lo acepte en el futuro, pero sin poder reproducir el problema (o la solución) me gustaría dejar esta pregunta abierta.


6
2017-07-06 11:18


origen


¿Tiene algunos HP 3305 que ESTÁN funcionando normalmente o todos son exp. ¿el problema? - Paul Ackerman
He visto que los problemas de MTU causan un comportamiento de navegación errado, pero esto probablemente solo ocurra a través de un enlace WAN, no en la misma subred. Aún así, es la única vez que he visto ese tipo de comportamiento, así que pensé en mencionarlo en caso de que estés usando un MTU más pequeño y las nuevas cajas no recibieran la nota. - Paul Ackerman
Tengo 2 que están trabajando, 4 que no están ... Los 2 que están trabajando se compraron un mes antes que los otros que eran todos del mismo pedido / fecha ... ¿Todos los configuré de la misma manera? - HaydnWVN
Vería problemas de ping / DNS con cualquier cosa relacionada con MTU, ¿no? - HaydnWVN
Voy a poner un poco de información privilegiada en la mezcla aquí. Soy uno de los desarrolladores del equipo en línea de RHS (el equipo que cuida el sitio web principal). Aproximadamente una vez cada dos meses recibimos una solicitud como esta y tratamos de solucionarlo, pero el usuario generalmente deja de responder antes de descubrir qué está pasando. Estoy 99% seguro de que es un problema de Windows 7, pero aparte de eso estamos perplejos. - Piers Karsenbarg


Respuestas:


Si desea conocer la diferencia en la solicitud HTTP GET, descargue el ZAP (Zed Attack Proxy) de OWASP o algún otro proxy que le permita inspeccionar cada paquete antes de enviarlo al servidor. Esto responderá a la pregunta de "cuál es la diferencia entre las 2 solicitudes".

Si las solicitudes son las mismas, intente con otra NIC.

Lo más probable es que su NIC esté a bordo. Intente instalar una NIC PCI con los controladores apropiados y vea si puede llegar allí. Suena como problema de hardware / controlador en este punto.


1
2017-07-12 16:07



No puedo averiguar cómo usar ZAP para monitorear las solicitudes HTTP GET. ¡No tengo mucho tiempo para 'arreglar' esto, ya que mi solución es una 'solución' muy popular en este momento! - HaydnWVN


Nunca he usado Fiddler antes, pero el hecho de que "ServerGotRequest" no esté configurado en el escenario de falla implica una de tres cosas:

  1. El servidor no ha recibido la solicitud completa de la estación de trabajo (es decir, el HTTP GET no se ha completado)
  2. El servidor recibió la solicitud pero no respondió debido a un error u otro problema en el servidor.
  3. El servidor respondió, pero el paquete de respuesta no regresó.

Sé que este es un servidor alojado, ¿tiene acceso para consultar los registros del servidor o la capacidad de ejecutar un sniffer en él (es decir, WireShark) para capturar datos mientras realiza las pruebas? Si es así, observe los archivos de registro del servidor en busca de errores, y ejecute el sniffer hasta que obtenga un escenario de falla en la estación de trabajo, luego observe si el servidor recibió la respuesta completa e intentó responder.

Después de eso, verifique los registros del firewall de Kapersky para ver si se han caído algunos paquetes. ¿Es posible configurar un sniffer frente al firewall y ver si la respuesta del servidor está regresando tan lejos? Si llega al firewall, y Kaspersky no nota dejar caer nada, probablemente sea seguro asumir que lo logró.

Durante estas pruebas, sugeriría ejecutar WireShark en una de las máquinas que falla. Mostrará las conexiones de salida, además de las respuestas que reciba la NIC. Si se trata de un problema de la NIC, el rastreo del rastreador debe mostrar el paquete que se está recibiendo y, a partir de ahí, puede determinar si eso justifica una actualización de la NIC y / o del controlador.

Debido a que no puede conectar un sniffer al exterior de su firewall, deberá trabajar con su ISP para que ellos configuren la supervisión de los paquetes que salen de su enrutador, pero nunca reciben una respuesta.

Una vez que el ISP haya confirmado o refutado su hipótesis acerca de hacia dónde se dirigen los paquetes, hay dos opciones: Opción 1: el paquete llega al firewall pero NO sale al ISP durante un intento fallido de conexión a la web. Opción 2: el paquete lo hace a través del firewall en la red del ISP, pero la respuesta nunca llega.

La opción 1 podría ser más fácil de reemplazar y / o reinstalar el firewall si es posible. Si se trata de un dispositivo provisto por un ISP, querrá que guarden la configuración actual pero aplique una configuración muy básica en el nuevo sistema para asegurarse de que no sea un problema relacionado con la configuración.

La opción 2 sería agradable porque les pone un problema para solucionar, pero si no tienen tiempo para analizarlo, estás atascado con su respuesta. En este caso, podría ser que deje su red y se dirija a su proveedor de Internet, que se mete en otra lata de gusanos que intentan rastrear dónde murió un paquete.


1
2017-08-06 14:51



Wireshark muestra la solicitud GET saliendo de la máquina, pero la máquina nunca recibe nada en respuesta. Lo extraño es que no se agota el tiempo tampoco? No tengo acceso al servidor web, ¡no es mío! ¡Es solo un sitio web al que algunos usuarios ocasionalmente necesitan acceso! - HaydnWVN
Entonces, si colocas un sniffer de WireShark fuera de tu firewall, ¿ves que sale la solicitud GET? Si no es así, entonces su problema es interno y solo necesita ser rastreado. Si se apaga, deberá trabajar con su ISP y esperar que lo hagan con usted. - dan_linder
No puedo monitorear los datos salientes fuera del firewall ya que está integrado en nuestro enrutador. Solo tenemos la 1 conexión. ¿Por qué necesitaría trabajar con mi ISP? Todas las solicitudes GET (exitosas y no exitosas) se realizan a través de la misma conexión, en la misma dirección IP externa a la misma IP de destino. Esto no es un problema de enrutamiento - HaydnWVN
Estoy de acuerdo en que no parece ser un problema de enrutamiento, pero es muy posible que sea un problema de eliminación de paquetes. Al usar un detector de paquetes en el exterior del firewall, puede mostrar que las solicitudes GET que finalmente fallaron dejaron la red. Entonces tendría algunos puntos de datos para demostrar que no es un problema en su red. - dan_linder
Si este fuera el caso, ¿no veríamos un comportamiento extraño con otros sitios / correos electrónicos que faltan y datos corruptos? Este sitio web es el único con un problema. - HaydnWVN


¿Puede confirmar si las marcas en máquinas en funcionamiento y en que no funcionan son la misma marca / modelo? También podría confirmar que su ipv6 es el mismo en todas las máquinas (en un lan interno deshabilitaría ipv6 por completo). También como última comprobación: asegúrese de que no haya nada en el archivo host que pueda detener el acceso a la red (c: \ windows \ drivers \ etc)

El hecho de que haya descartado el navegador y el hardware (usando un CD en vivo) me hace pensar que debe estar relacionado con el adaptador de red.

Si todo esto falla, definitivamente cambie los discos duros y vea si el problema sigue al disco duro o al NIC.


0
2017-07-10 15:41



Las máquinas son exactamente iguales. IP6 no tiene configuraciones / está deshabilitado (no estoy seguro de cuál). El archivo de hosts está vacío. - HaydnWVN
¿Intentaste intercambiar los discos? - PJ42
Aún no, estas son máquinas en vivo y el uso de un proxy web en línea (gratuito) (lo que he hecho como un 'arreglo') puede terminar siendo mi solución. Es solo 1 sitio web, aunque uno visitado regularmente. - HaydnWVN
Debería haber preguntado esto antes: ¿utiliza un proxy de Internet? Si es así, ¿puede confirmar que las mismas cuentas de usuario y el ser utilizado? - PJ42
Como se mencionó en mi post original - sin proxy. - HaydnWVN


Compararía las máscaras de red y las direcciones de las puertas de enlace en los sistemas problemáticos y compararía esto con los sistemas en funcionamiento.

He visto el problema antes y esta fue la causa: una dirección de puerta de enlace incorrecta (pero todavía algo funcional).


0
2017-07-10 15:47



Todos son iguales (es decir, correctos). Aquí solo tenemos 1 puerta de enlace y utilizamos 255.255.0.0 como máscara de subred. Su respuesta no explica por qué solo debería ocurrir en este sitio web (todos los demás están bien) sin ningún error. - HaydnWVN
¿Verificaste la configuración de IP del servidor web? - jftuga
El servidor web / sitio host está totalmente fuera de mi control. Los resultados DNS de ambas máquinas para la dirección se resuelven en la misma IP de destino. - HaydnWVN


Comience con lo básico: tiene dos series diferentes de máquinas que probablemente tienen dos series diferentes de NIC. ¿Están ambos lados preparados para la negociación automática y, en caso afirmativo, están acordando la velocidad adecuada? Intente codificar ambos lados como un experimento para ver si mejora (..o si está codificado en ambos lados actualmente, entonces permita que ambos lados negocien).


0
2017-08-06 14:21



No es un problema de hardware. No estoy seguro de qué es, pero definitivamente no es eso. - Piers Karsenbarg
Entonces, ¿ha confirmado que los contadores en el puerto del switch no muestran ningún tipo de error? - rnxrx
¿Código difícil? ¿Contadores en el interruptor? Elaborar por favor! - HaydnWVN
Mis comentarios tienen que ver con el conmutador Ethernet que está utilizando. Si puede ver los contadores en busca de varios errores, puede encontrar que las máquinas en cuestión están viendo cómo suben estos contadores. Esto sería indicativo de un problema con la configuración de las interfaces de red. - rnxrx
Es un conmutador no administrado básico sin interfaz para que pueda comprobar algo así. ¿Qué tipo de configuración de red? ¿Y por qué sería solo con 1 sitio y nada más? - HaydnWVN


Hay una gran brecha entre

ClientConnected:    17:02:33.720

...y...

ClientBeginRequest: 17:02:39.118

O está perdiendo paquetes o el software de seguridad del lado del cliente está roto. Es trivial probar el primero con Wireshark, e incluso si no ve el paquete menos (retransmisiones), puede determinar la direccionalidad de la latencia inyectada.


0
2017-08-06 22:33



Probará más, ¿alguna idea de por qué esto solo estaría sucediendo con 1 sitio web y nada más? - HaydnWVN
No se pierden paquetes de ninguna máquina (afectados y no afectados). La brecha entre Connect y BeginRequest puede ser de 3 a 9 segundos en cualquier tipo de PC. Que quieres decir con "the client side security software is broken"¡Como puedo controlarlo / arreglarlo! ¿Alguna idea de lo que se puede romper? - HaydnWVN
Si puede obtener los mismos resultados con diferentes navegadores en las máquinas afectadas, esto demostraría que su firewall / software de seguridad está causando el problema, intente desinstalarlo (o mejor aún, una instalación nueva sin el software). - symcbean


A partir de esta mañana este problema está 'arreglado'.

He trabajado (por correo electrónico) con Muelles karsenbarg En varias vías diferentes de resolución, todo en vano. No se ha cambiado nada en el sitio web ni se ha cambiado nada en las máquinas, excepto algunas actualizaciones de Windows. ¡No puedo agradecer a Piers lo suficiente por involucrarse con el problema y pasar mucho tiempo de calidad tratando de resolverlo!

Piers me vinculó a esta que tiene todos los síntomas (pero ninguna de las causas) en estas máquinas en cuestión (es decir, no hay fuentes de tipo 1). Pero es posible una actualización de Windows (o alguna actualización de Adobe) fijo El problema: creo que reemplazé o eliminé las fuentes Type 1. Más información se puede encontrar. aquí y aquí.


0
2017-08-29 15:37