![如何诊断小型网络中的严重网络问题?](https://linux22.com/image/795555/%E5%A6%82%E4%BD%95%E8%AF%8A%E6%96%AD%E5%B0%8F%E5%9E%8B%E7%BD%91%E7%BB%9C%E4%B8%AD%E7%9A%84%E4%B8%A5%E9%87%8D%E7%BD%91%E7%BB%9C%E9%97%AE%E9%A2%98%EF%BC%9F.png)
我们的网络规模相当小,有托管和非托管交换机(Netgear GS748T、Linksys SLM2024、DGS-1008D、DES-1008D、DES-1026G、SRW224G4)、大约 8-10 台 Hyper-V 主机(带有多个虚拟机)、几台带有 VWMare 的主机以及大约 100 个本地用户和另外 100 个 vpn 用户(并非一直连接)。最近,我们在网络中引入了 Forefront TMG(使其成为中心点),并对 VLAN 进行了重大更改(从一个 192.168.1.X 网络到 5-10 个 VLAN,将网络分为测试机器、关键服务器、iSCSI、Heart Bit - 集群 HV、受信任用户、不受信任用户等)。大多数(如果不是全部)网卡都使用 Teaming、Aggregation 和 Trunk。
在过去的几周、几个月里,网络一直不稳定,晚上备份时会出现 iSCSI 问题。昨天,我们的网络在白天突然瘫痪,无法使用长达 2 个小时。在此期间,交换机死机了 2 次,需要硬重置,整个网络在此期间无法正常工作。2 小时后,一切恢复正常,但似乎很快就会恢复。
交换机提供不了太多功能monitoring capabilities
,备份 iscsi 驱动器也是如此。TMG 中的一些错误:
Forefront TMG 断开了来自 172.16.10.5 的非 TCP 连接,因为超出了此 IP 地址的连接限制。应该为链接的代理服务器和具有 NAT 关系的背对背 Forefront TMG 计算机的 IP 地址配置更大的自定义连接限制。
Forefront TMG 断开了来自 172.16.10.12 的非 TCP 连接,因为超出了此 IP 地址的连接限制。应该为链接的代理服务器和具有 NAT 关系的背对背 Forefront TMG 计算机的 IP 地址配置更大的自定义连接限制。
来自源 IP 地址 178.215.xxx.xxx 的并发 TCP 连接数超出了配置的限制。因此,Forefront TMG 将不允许从此源 IP 创建新的 TCP 连接。此 IP 地址可能属于攻击者或受感染的主机。有关 Forefront TMG 洪水缓解的更多信息,请参阅产品文档。
来自源 IP 地址 77.1xxx.xxx 的拒绝连接数超出配置的限制。这可能表明主机已感染病毒或正在尝试攻击 Forefront TMG 计算机。
Forefront TMG 断开了来自 172.16.10.10 的非 TCP 连接,因为超出了此 IP 地址的连接限制。应该为链接的代理服务器和具有 NAT 关系的背对背 Forefront TMG 计算机的 IP 地址配置更大的自定义连接限制。
Forefront TMG 断开了来自 172.16.10.16 的非 TCP 连接,因为超出了此 IP 地址的连接限制。应该为链接的代理服务器和具有 NAT 关系的背对背 Forefront TMG 计算机的 IP 地址配置更大的自定义连接限制。
来自源 IP 地址 195.ZZZ 的拒绝连接数超出配置的限制。这可能表明主机已感染病毒或正在尝试攻击 Forefront TMG 计算机。
来自源 IP 地址 85.ZZZ 的拒绝连接数超出配置的限制。这可能表明主机已感染病毒或正在尝试攻击 Forefront TMG 计算机。
Forefront TMG 断开了来自 172.16.231.12 的非 TCP 连接,因为超出了此 IP 地址的连接限制。应该为链接的代理服务器和具有 NAT 关系的背对背 Forefront TMG 计算机的 IP 地址配置更大的自定义连接限制。
Forefront TMG 无法解压缩来自 stooq.pl 的响应主体,因为响应是使用 Forefront TMG 不支持的方法压缩的。当 Web 服务器配置为提供使用 Forefront TMG 不支持的方法压缩的响应时,无论请求的压缩类型如何,都会发生这种情况。
如果您希望 Forefront TMG 阻止此类响应,请配置策略规则的 HTTP 策略以阻止响应中的 Content-Encoding 标头。否则,此类响应将在不解压的情况下转发到客户端并可能被缓存。您可以在 Forefront TMG 管理中取消或降低此事件生成的警报的频率。
连接验证程序“Farm: Sharepoint.xxx.pl - Farm”在尝试连接到 14cms.xxx.xx 时报告错误。原因:请求已超时。
连接验证器“DHCP1”在尝试连接到 DHCP1.xxx.xx 时报告错误。原因:请求已超时。
我们已经使用过 TMG,并为我们的 AD/DNS 服务器设置了一些更高的限制,因为我们之前看到过此消息,但似乎它到处都在发生。
答案1
“在此期间,交换机死机了 2 次,需要硬重置”
我并不是想在这里成为精英,但 Linksys/D-Link/Netgear 甚至不是中型硬件。iSCSI 和虚拟化需要非常稳定和快速的网络才能正常运行。
我强烈建议您购买更好的网络设备(思科、惠普等)。
答案2
查看 TMG 中与内部流量相关的错误消息(172.16.xx 是不错的起点)。确定这些消息与哪些主机相关,以及防火墙是否应该针对这些主机上的流量采取适当的措施。
绝不假设防火墙自带适当的配置尤其如果要在内部部署该防火墙。
我还建议为 iSCSI 存储网络使用单独的交换机,而不是尝试使用 VLAN 隔离流量。这样更容易理解,如果您将其用于 VM 硬盘,您确实需要正确处理 iSCSI 流量!