![解决本地网络内的网站问题](https://linux22.com/image/589313/%E8%A7%A3%E5%86%B3%E6%9C%AC%E5%9C%B0%E7%BD%91%E7%BB%9C%E5%86%85%E7%9A%84%E7%BD%91%E7%AB%99%E9%97%AE%E9%A2%98.png)
有一个外部网站,在某些电脑上可以正常打开,但在其他电脑上却似乎超时(或出现超时症状,但实际上从未超时)。
似乎只影响我们较新的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”意味着以下三件事之一:
- 服务器尚未收到来自工作站的完整请求(即 HTTP GET 尚未完成)
- 服务器收到了请求,但由于服务器出现错误或其他问题而未回复。
- 服务器已回复,但回复数据包未返回。
我知道这是一台托管服务器,您是否有权查看服务器日志或在其上运行嗅探器(即 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。双方是否都设置为自动协商,如果是,他们是否同意适当的速度?尝试对双方进行硬编码作为实验,看看它是否有所改善(..或者如果目前双方都进行了硬编码,则让双方协商)。