☰

解决本地网络内的网站问题

tag-icon • tag-icon networking windows-7 website internet
解决本地网络内的网站问题

有一个外部网站，在某些电脑上可以正常打开，但在其他电脑上却似乎超时（或出现超时症状，但实际上从未超时）。

似乎只影响我们较新的HP Pro 3305 MT 工作站。所有电脑均运行 Win7 32 位 SP1 并安装所有更新。较旧的 PC（Win7 32 位 SP1 和 WinXP）不受影响。

使用 Google Chrome 和 Firefox 没有区别。以 IE9 兼容模式打开网站会出现完全相同的症状。

所有 PC 都位于同一个本地网络（工作组）上，使用同一个 DNS 服务器和网关（内部），位于同一个互联网连接上，位于同一个子网中。没有代理服务器、没有内容过滤、没有负载平衡等等。只有有效的组策略（本地）用于更新计划。本地防火墙都相同（卡巴斯基 WP4），我们的外部防火墙没有 IP 特定设置。

我无法控制外部网站，traceroute 在所有 PC 上显示相同的目的地。这是我们行业（园艺）中一个相当受欢迎的网站，我不知道其他人（甚至我们姊妹公司内的其他网站）有同样的问题。

更新： 使用 Fiddler2 监控 HTTP 请求，似乎由于某种原因没有得到满足？！

请求已发送：

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

从 Fiddler 2 记录请求：

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

来自工作 PC 的成功请求日志（今天早上完成，请原谅时间戳与上面的不同）：

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

所以我的问题演变成：

这两个请求之间有什么区别？我如何确定为什么 1 台 PC 没有收到对其 GET 请求的回复？

更新 2：

请参阅下面的回答。我以后可能会接受它，但如果无法重现该问题（或修复），我想保留这个问题。

答案1

如果您想知道 HTTP GET 请求中的差异，请从 OWASP 或其他代理下载 ZAP（Zed Attack Proxy），这样您就可以在将数据包发送到服务器之前对其进行检查。这将回答“这两个请求之间有什么区别”的问题。

如果请求相同，请尝试另一个 NIC。

您的 NIC 很可能是板载的。尝试安装带有适当驱动程序的 PCI NIC，看看是否可以实现。此时听起来像是硬件/驱动程序问题。

答案2

我以前从未使用过 Fiddler，但根据失败场景中未设置的“ServerGotRequest”意味着以下三件事之一：

  1. 服务器尚未收到来自工作站的完整请求（即 HTTP GET 尚未完成）
  2. 服务器收到了请求，但由于服务器出现错误或其他问题而未回复。
  3. 服务器已回复，但回复数据包未返回。

我知道这是一台托管服务器，您是否有权查看服务器日志或在其上运行嗅探器（即 WireShark）以在测试时捕获数据？如果是，请查看服务器日志文件中是否有任何错误，并运行嗅探器直到您在工作站上获得故障情况，然后查看服务器是否收到完整响应并尝试响应。

之后，检查 Kapersky 防火墙日志，看看它是否丢弃了任何数据包。是否可以在防火墙前设置嗅探器，看看服务器的响应是否能返回到那么远？如果它到达了防火墙，而 Kapersky 没有注意到丢弃了任何东西，那么可以安全地假设它已经通过了。

在这些测试期间，我建议在其中一台发生故障的机器上运行 WireShark。它将显示出站连接，此外还应显示 NIC 收到的任何响应。如果是 NIC 问题，嗅探器跟踪应显示正在接收的数据包，然后您就可以确定是否需要更新 NIC 和/或驱动程序。

由于您无法将嗅探器连接到防火墙外部，因此您需要与 ISP 合作，让他们设置监控离开路由器但从未收到响应的数据包。

一旦 ISP 确认或驳斥了您对数据包去向的假设，则有两个选项：选项 1：数据包到达防火墙，但在网络连接尝试失败期间不会到达 ISP。选项 2：数据包通过防火墙到达 ISP 网络，但永远不会收到响应。

如果可能的话，选项 1 可能是最容易更换和/或重新安装防火墙的。如果它是 ISP 提供的设备，您将希望他们保存当前配置，但在新系统上应用非常基本的配置，以确保它不是与配置相关的问题。

选项 2 很不错，因为它把问题交给他们来解决，但如果他们没有时间研究，那么您只能接受他们的答案。在这种情况下，数据包可能会离开他们的网络，并传到他们的互联网提供商那里——这又会引发另一场麻烦，需要追踪数据包消失的位置。

答案3

您能否确认工作机器和非工作机器的网卡是否是同一品牌/型号。您能否确认您的 ipv6 在所有机器上是否相同（在内部局域网上，我会完全禁用 ipv6）。最后还要检查 - 确保主机文件中没有任何可能阻止网络访问的内容（c:\windows\drivers\etc）

事实上，您已经排除了浏览器和硬件（使用实时 CD），这使我认为这一定与网络适配器有关。

如果所有这些都失败了——一定要更换硬盘，看看问题是否出在硬盘上或网卡上。

答案4

从基础开始 - 您有两个不同系列的机器，它们可能有两个不同系列的 NIC。双方是否都设置为自动协商，如果是，他们是否同意适当的速度？尝试对双方进行硬编码作为实验，看看它是否有所改善（..或者如果目前双方都进行了硬编码，则让双方协商）。

相关内容