первый раз на ServerFault, и у меня возникла небольшая приятная головоломка.
Уже несколько месяцев у нас возникают проблемы с подключением к Интернету.
Окружающая среда:
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
Проблема:
Через нерегулярные промежутки времени веб-сайты отказываются загружаться, выдавая ошибку о том, что страница недоступна или некоторые изображения загружаются не полностью. Кроме того, после проверки серверные файлы .js не загружаются.
Результаты и что мы пробовали:
Первое впечатление:
Когда я использую Chrome в течение этого интервала, сайт после некоторых обновлений возвращает сообщение net :: Error 101 или Error 103. В других случаях, если ошибка не возникает, некоторые изображения не видны и отображают X-образ. IE просто говорит, что страница не может быть отображена.
С помощью инструментов разработчика Chrome:
В консоли отображается, что некоторые ресурсы недоступны, но когда я щелкаю правой кнопкой мыши отсутствующие изображения и выбираю «Показать изображение», они отображаются. Когда я открываю изображения по прямому URL-адресу, они также отображаются.
Аудит с помощью инструментов разработчика Chrome:
Я провел аудит страницы, когда она находилась в состоянии ошибок, и обнаружил, что некоторые файлы .js не загружаются вместе с некоторыми файлами .png, .jpg и .gif. Загружаются разные изображения для Chrome и IE.
Запутанные файлы JS и Avast:
Проверив это, я обнаружил, что большинство этих файлов .js представляют собой обфусцированные файлы JS, и, поскольку мы используем Avast 7.0.1455, мне было интересно, не испортил ли Web Shield.
Опять же, это происходит только в первом TS, а не во втором.
Поэтому я выключил WebShield на день и посмотрел, улучшилось ли что-нибудь. Это не так. В исходную точку.
Нет истечения срока действия кеша для файлов:
Было указано, что у некоторых из этих файлов, которые не загружаются, не истек срок действия кеша.
Кеширование:
Некоторое время назад один из наших системных администраторов изменил размер кэша IE до 10 МБ, что, как я думал, могло быть источником проблемы. Он изменил его обратно на 65 МБ или около того, но люди все равно сталкиваются с проблемами со своими изображениями. Это все еще происходит на 1 TS, а также в Chrome, поэтому я не думаю, что групповая политика, диктующая, что кеш будет влиять на Chrome, не так ли?
Проблема с сетью: Я также подумал, что это может быть проблема с сетью или маршрутизацией, но оба TS-сервера находятся на одном объединенном сетевом адаптере, а другой работает нормально.
Помогите!
Если у кого-то есть советы о том, где искать проблемы, или нужна дополнительная информация, пожалуйста, помогите мне. Это беспокоит меня уже несколько недель.
ИЗМЕНИТЬ И ОБНОВИТЬ
Проблема все еще сохраняется, и только на 2 наших терминальных серверах.
Вот что до сих пор делали я и мой коллега:
Выключите антивирус на день на одном сервере, чтобы убедиться, что этого не произошло. Проблема все еще возникла.
Проверил размер MTU
Это настройка по умолчанию (точное значение забыли: P) Проблема все еще возникла.
Установленные обновления Windows, IE10 Проблема все еще возникла.
Проверил, есть ли прокси.
AV вставляет прокси в качестве так называемого WebShield. Мы отключили сервис и программу на одном сервере на сутки. Проблема все еще возникла.
Переустановил NIC-команду, так как она была испорчена. (Также переустановил драйверы NIC) Проблема все еще возникла.
Проверенные групповые политики Судя по всему, на обоих терминальных серверах была политика локального компьютера, которая включала режим предпочтений в IE, в котором были сделаны некоторые странные настройки. Отключил это, и ... Проблема все еще возникла.
Сейчас дело даже дошло до того, что у людей возникают проблемы с загрузкой и скачиванием файлов из SharePoint, и многие сайты, которые мы используем, не работают из-за этого.
Предчувствия
Это либо связано с WebShield, который разрывает соединение, когда находит что-то необычное, но тогда этого не должно происходить при выключении AV.
Возможно, перенаправления каким-то образом испорчены, или что-то с кешем. Как ни странно, такая же проблема возникает в Chrome, а также в IE9 и IE10.
Если у кого-то есть идеи, мы будем очень признательны.
Спасибо HopelessN00b за помощь!
ОБНОВИТЬ:
Мы получаем некоторые ошибки в средстве просмотра событий, например на одном из наших исходных TS:
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
И иногда это всплывает, но, видимо, это из-за того, что некоторые терминалы WYSE слишком старые (мы надеемся вскоре заменить их на Raspberry Pi).
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].
Надеюсь это поможет.
Проблемы были «решены» провайдером. Все изображения, JS и тому подобное теперь появляются нормально в течение хорошей недели. Один внешний сайт, недоступный для доступа, был разрешен интернет-провайдером путем установки прокси-сервера между ними.
К сожалению, точная причина, почему или как это произошло, все еще остается загадкой, но можно с уверенностью сказать, что кое-что, что изменил мой интернет-провайдер, помогло.
Спасибо всем за поддержку, и хотя многие ответы оказались очень полезными, я не могу выбрать один из них как правильный, следовательно, мой собственный.
Еще раз спасибо за все ваше время и усилия, и я надеюсь, что никому другому не придется справляться с такой странностью сети.
Чтобы диагностировать проблему без точного сообщения об ошибке, вам необходимо запустить:
Я подозреваю, что вы найдете DNS-запрос без ответа. Если ваш интернет-провайдер фильтрует ваш трафик через прокси-сервер, вы сможете найти его следы в трафике, особенно путем сравнения захвата на стороне сервера с захватом на стороне клиента.
Если есть проблема с качеством сети, вы можете более наглядно ее обнаружить с помощью traceroute. Если сетевой дамп показывает, что связь прошла гладко, но браузер не может отобразить предоставленные данные, то ваша проблема - шутки рабочего стола на сервере терминалов.
Вы должны запустить захват пакетов на сервере терминалов, который устанавливает соединение с браузером, которое не работает.
Попробуйте без подключения сетевых адаптеров. Установите только одну сетевую карту и посмотрите, все ли работает. Если это действительно так, убедитесь, что конфигурация вашего порта коммутатора и конфигурация Teaming совпадают.