Interrupción irregular de Internet: ciertas imágenes y JS no se cargan


11

primera vez en ServerFault, y tengo un pequeño acertijo.

Desde hace unos meses, hemos tenido problemas con nuestra conectividad a Internet.

Ambiente:

Servers: 2 Terminal Servers as an RDSFarm running Windows Server 2008 R2
Browser: Internet Explorer 9
Test/debug browser: Chrome
AntiVirus: Avast 7.0.1455

Problema:

A intervalos irregulares, los sitios web se niegan a cargar, dando un error diciendo que la página no era accesible o que algunas imágenes no se cargan por completo. Además, después de la inspección, varios archivos .js no se pueden cargar.

ingrese la descripción de la imagen aquí

Hallazgos y lo que probamos:

Primera impresión:

Cuando uso Chrome durante ese intervalo, el sitio devuelve un net :: Error 101 o Error 103 después de algunas actualizaciones. En otras ocasiones, si no está dando el error, varias imágenes no son visibles y muestran una imagen X. IE solo dice que la página no se puede mostrar.

ingrese la descripción de la imagen aquí

Uso de las herramientas para desarrolladores de Chrome:

Muestra en la consola que varios recursos no están disponibles, pero cuando hago clic derecho en las imágenes que faltan y selecciono "Mostrar imagen", se muestran. Cuando abro las imágenes a través de una URL directa, también se muestran.

ingrese la descripción de la imagen aquí

Auditoría a través de las Herramientas para desarrolladores de Chrome:

Realicé una auditoría en una página cuando estaba en estado defectuoso, y descubrí que algunos archivos .js no se cargaban junto con algunos archivos .png, .jpg y .gif. Se cargan diferentes imágenes para Chrome e IE.

ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

Archivos JS ofuscados y Avast:

Después de verificar eso, descubrí que la mayoría de esos archivos .js son archivos JS ofuscados, y dado que estamos ejecutando Avast 7.0.1455, me preguntaba si Web Shield no estropeó las cosas.

Por otra parte, solo está sucediendo en el primer TS, no en el segundo.

Así que apagué WebShield por un día y vi si algo mejoró. No lo hizo. Volver al punto de partida.

Sin caducidad de caché en archivos:

Se indicó que varios de esos archivos que no se están cargando no tienen una caducidad de caché.

Almacenamiento en caché:

Uno de nuestros administradores de sistemas cambió el tamaño de la memoria caché de IE a 10 MB hace un tiempo, lo que pensé que podría haber sido la fuente del problema. Lo cambió de nuevo a 65 MB, pero la gente todavía tiene problemas con sus imágenes. También ocurre en 1 TS, y también en Chrome, así que no creo que la Política de grupo que dicta que la caché afecte a Chrome, ¿verdad?

ingrese la descripción de la imagen aquí

Problema de red: también pensé que podría ser un problema de red o enrutamiento, pero ambos servidores TS están en la misma NIC combinada, y el otro está funcionando bien.

¡Ayuda!

Si alguien tiene algunos consejos sobre dónde buscar problemas o necesita más información, ayúdame. Esto me ha estado molestando durante varias semanas.

EDITAR Y ACTUALIZAR

El problema aún persiste, y solo en nuestros 2 servidores de terminal.

Esto es lo que yo y un colega hicimos hasta ahora:

  • Apague el antivirus por un día en un servidor, para ver si no sucedió. El problema aún ocurrió.

  • Comprueba el tamaño de MTU
    Es la configuración predeterminada (olvidé el valor exacto: P) El problema aún ocurrió.

  • Actualizaciones de Windows instaladas, IE10 El problema aún ocurrió.

  • Comprobado si había algún proxy.
    El AV pone un proxy como el llamado WebShield. Inhabilitamos el servicio y el programa en un servidor por un día. El problema aún ocurrió.

  • Vuelva a instalar el equipo de NIC, ya que estaba en mal estado. (También reinstaló los controladores de NIC) El problema aún ocurrió.

  • Políticas de grupo revisadas Aparentemente en ambos servidores de Terminal Server, había una política de máquina local que habilitaba el modo de preferencia en IE, que tenía una personalización extraña. Desactivado eso, y ... El problema aún ocurrió.

Ahora incluso ha llegado al extremo de que las personas tienen problemas para cargar y descargar archivos de SharePoint, y muchos de los sitios que estamos utilizando no funcionan debido a esto.

Corazonadas

Tiene que ver con el WebShield que interrumpe la conexión cuando encuentra algo peculiar, pero luego no debería suceder cuando el AV está apagado.

Puede ser que los redireccionamientos estén desordenados de alguna manera, o que haya algo con el caché. Aunque es extraño que ocurra el mismo problema en Chrome, así como en IE9 e IE10.

Si alguien tiene alguna idea, sería muy apreciada.

¡Gracias a HopelessN00b por ayudarme!

ACTUALIZAR:

Recibimos algunos errores en el Visor de eventos como este en uno de nuestros TS originales:

Error: (04/04/2013 08:44:42 AM) (Source: Application Error) (User: )
Description: Faulting application name: iexplore.exe, version: 9.0.8112.16470, time stamp: 0x510c8801
Faulting module name: MSHTML.dll, version: 9.0.8112.16470, time stamp: 0x510c9046
Exception code: 0xc0000005
Fault offset: 0x002d0174
Faulting process id: 0x21728
Faulting application start time: 0xiexplore.exe0
Faulting application path: iexplore.exe1
Faulting module path: iexplore.exe2
Report Id: iexplore.exe3

Y a veces esto aparece, pero aparentemente eso es porque algunos terminales WYSE son demasiado viejos (reemplazándolos con Raspberry Pi, con suerte).

Error: (04/04/2013 11:21:46 AM) (Source: TermDD) (User: )
Description: The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.
Client IP: [IP REDACTED].

Espero que esto ayude.


1
Me recuerda los problemas que vimos desde una perspectiva completamente diferente, básicamente tenía que ver con la configuración de MTU, en algún lugar no se había tenido en cuenta la encapsulación de paquetes, y los paquetes fragmentados no se estaban volviendo a ensamblar correctamente, por lo que cualquier cosa más grande que una sola el paquete simplemente no se cargaría ... si la página fuera https, nada se cargaría.
NickW

1
No es un problema, trataría de ejecutarlo en algún lugar entre el TS y las máquinas que tienen los problemas. Tal vez su chico de la red podría reflejar el puerto donde está conectado el TS (o la máquina desde la que está probando) para que pueda pegar una máquina con cables de alambre allí para ver el tráfico.
NickW

1
Sí, eso no debería causar muchos problemas.
NickW

1
Por cierto, has
investigado

44
Hay dos cosas que probaría cuando esto suceda. Si es solo el dominio y JS, verifique las rutas a los servidores en los que se encuentran (la ruta es bastante clara allí), ya que si solo se trata de algunos elementos, vale la pena averiguar qué es lo común y por qué fallan. También hay una pequeña posibilidad de que sea una configuración incorrecta de ISP: mi ISP de casa hizo esto, y fue un verdadero dolor de cabeza rastrear, y un día lo arreglé completamente al azar
Journeyman Geek

Respuestas:


0

Intente sin vincular las NIC. Configure solo una NIC y vea si las cosas aún funcionan. En el caso de que se asegure de que la configuración del puerto de su conmutador y la configuración de Teaming estén alineadas.


Me parece que esto debería ser un comentario, en lugar de una respuesta. Buena idea, sin embargo. He visto una causa defectuosa del equipo de NIC, muchos problemas extraños en mi tiempo.
HopelessN00b

Al reinstalar el equipo de NIC, intentamos ejecutar sin un equipo, en una sola NIC. Tampoco funcionó.
blaa

0

Para diagnosticar el problema sin un mensaje de error preciso, debe ejecutar:

  • tcpdump en el lado del cliente (wireshark tiene una buena pantalla)
  • tcpdump en el lado del servidor (vea lo que el servidor está enviando realmente).
  • espera a que ocurra el problema
  • examine los paquetes y vea dónde se rompe la comunicación. Si necesita ayuda para examinar la traza, escríbala en un archivo.

Sospecho que encontrará una consulta DNS sin respuesta. Si su ISP está filtrando su tráfico a través de un proxy, debería poder encontrar rastros de él en el tráfico, especialmente comparando la captura del lado del servidor con la captura del lado del cliente.

Si hay un problema de calidad de red, puede observarlo más directamente con traceroute. Si el volcado de la red muestra que las comunicaciones se realizaron sin problemas, pero el navegador no puede mostrar los datos proporcionados, entonces su problema son las funciones de escritorio en el servidor terminal.

Debe ejecutar la captura de paquetes en el servidor de terminal que está haciendo la conexión del navegador que no funciona.


0

Los problemas han sido "resueltos" por el ISP. Todas las imágenes y JS y similares aparecen normalmente ahora durante una buena semana. El ISP resolvió el único sitio externo al que no se pudo acceder colocando un proxy entre todos.

Desafortunadamente, la razón exacta de por qué o cómo sucedió esto sigue siendo un misterio, pero es una apuesta segura que había algo que mi ISP había cambiado que funcionó.

Gracias a todos por el apoyo, y aunque muchas respuestas han sido muy útiles, no puedo elegir una de ellas para que sea la correcta, de ahí la mía.

Gracias de nuevo por todo su tiempo y esfuerzo, y espero que nadie más tenga que lidiar con tal extrañeza de redes.


1
¡Esperaba ver algo como esto algún día!
NickW
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.