Устранение проблем с веб-сайтом в локальной сети

Я никогда раньше не использовал Fiddler, но на основании того, что "ServerGotRequest" не установлен в сценарии сбоя, подразумевает одно из трех:

1. Сервер не получил полного запроса от рабочей станции (т.е. HTTP GET не завершен)
2. Сервер получил запрос, но не ответил из-за ошибки или другой проблемы на сервере.
3. Сервер ответил, но ответный пакет не вернулся.

Я знаю, что это размещенный сервер, есть ли у вас доступ для просмотра журналов сервера или возможность запускать на нем сниффер (например, WireShark) для сбора данных во время тестирования? Если да, просмотрите файлы журнала сервера на предмет ошибок и запускайте сниффер, пока не получите сценарий отказа на рабочей станции, затем посмотрите, получил ли сервер полный ответ и попытался ли он ответить.

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

Во время этих тестов я бы предложил запустить WireShark на одной из отказавших машин. Он покажет исходящие соединения, плюс он также должен показать все ответы, которые получает NIC. Если это проблема с сетевым адаптером, трассировка сниффера должна показывать получаемый пакет, и оттуда вы можете определить, требует ли это обновления сетевого адаптера и / или драйвера.

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

После того, как интернет-провайдер подтвердит или опровергнет вашу гипотезу о том, куда направляются пакеты, есть два варианта: Вариант 1: пакет попадает на брандмауэр, но НЕ выходит к провайдеру во время неудачной попытки веб-подключения. Вариант 2: пакет проходит через брандмауэр в сеть провайдера, но ответа не приходит.

Вариант 1 может быть самым простым - заменить и / или переустановить брандмауэр, если это возможно. Если это устройство, предоставленное интернет-провайдером, вы захотите, чтобы они сохранили текущую конфигурацию, но применили очень простую конфигурацию в новой системе, чтобы убедиться, что это не проблема, связанная с конфигурацией.

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

Если вы хотите узнать разницу в запросе HTTP GET, загрузите ZAP (Zed Attack Proxy) из OWASP или другого прокси, который позволит вам проверять каждый пакет перед его отправкой на сервер. Это ответит на вопрос «в чем разница между двумя запросами».

Если запросы совпадают, попробуйте другой сетевой адаптер.

Скорее всего, ваш сетевой адаптер уже установлен. Попробуйте установить PCI NIC с соответствующими драйверами и посмотрите, сможете ли вы их получить. Похоже, на данный момент проблема с оборудованием / драйверами.

Я бы сравнил маски сети и адреса шлюзов на проблемных системах и сравнил их с рабочими системами.

Я видел проблему раньше, и это была причина - неправильный (но все еще несколько рабочий) адрес шлюза.

Можете ли вы подтвердить, что ниши в рабочих машинах и неработающих принадлежат одной и той же марке / модели. Также не могли бы вы подтвердить, что ваш ipv6 одинаков на всех машинах (во внутренней сети я бы вообще отключил ipv6). Также в качестве последней проверки - убедитесь, что в файле хоста нет ничего, что могло бы остановить доступ к сети (c: \ windows \ drivers \ etc)

Тот факт, что вы исключили браузер и оборудование (используя live cd), заставляет меня думать, что это должно быть связано с сетевым адаптером.

Если все это не удается - обязательно замените жесткие диски и посмотрите, связана ли проблема с жестким диском или ником.

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

Есть большой разрыв между

ClientConnected:    17:02:33.720

...и...

ClientBeginRequest: 17:02:39.118

Либо вы теряете пакеты, либо программное обеспечение безопасности на стороне клиента не работает. Тестирование первого с помощью Wireshark тривиально - и даже если вы не видите меньше пакетов (повторных передач), вы можете определить направленность введенной задержки.

На сегодняшний день эта проблема «исправлена».

Я работал (по электронной почте) с Пирс Карсенбарг по нескольким различным путям разрешения, все безрезультатно. На веб-сайте ничего не изменилось, и на машинах ничего не изменилось, кроме некоторых обновлений Windows. Не могу отблагодарить Пирса за то, что он вмешался в проблему и потратил много времени на ее решение!

Пирс связал меня с этот у которого есть все симптомы (но ни одна из причин) на этих машинах (т.е. нет шрифтов типа 1). Но это является возможно обновление Windows (или некоторое обновление Adobe) фиксированный проблема - я думаю заменил или удалил шрифты Type 1. Дополнительную информацию можно найти Вот и Вот.