一次内网BBS故障排查

创建: 2022-08-25 22:06
http://scz.617.cn:8/network/202208252206.txt

NS宇宙的古早内网BBS事实上已弃用，之所以未直接下线，考虑到大量历史技术文档还在其上，且仍有学习价值。我倒是一直为之添砖加瓦，将之用作技术文档备份基地。

上个月2022年大型那啥活动期间，该BBS临时下线。活动结束后才重新上线，却发现它经常挂掉，外在表现是浏览器访问时无响应，或提示Oops错。每次LCG重启OS后能正常一阵子，几分钟后再次挂掉。寻思之前正常了十八年，不可能是BBS本身有啥幺蛾子，找LCG要了管理员密码，远程登上去排查。

BBS的WEB部分在A机，数据库在B机。LCG之前简单排查过，每当BBS挂掉时，从A机无法访问B机1433/TCP。我RDP到A机，简单看了一下CPU、内存、硬盘使用率，无异常峰值。"telnet B 1433"确实不行，"ping B"也不行，这就有点奇怪了，一般来说B不大可能单独封禁入站ICMP。看A机上有Wireshark，准备抓包，顺带下载sysinternals工具集，却发现A机网速异常缓慢。"arp -a"看了一眼，临时起意"arp -d B"，重新"ping B"，意外发现通了，然后B机1433/TCP可达。此刻BBS已能正常访问，无需重启A机。虽然没有Wireshark抓包，也能猜个大概，可能是A机ARP缓存被污染，其中的B条目MAC地址不对。这只是猜测，我没有B机管理员账号。决定等几分钟，待其再次挂掉时重新检查A机ARP表中B条目，检查B的MAC地址是否出现过异常变动。

几分钟后BBS如期而挂，RDP上去检查A机ARP表，表中B的MAC地址未出现异常变动。至此判定问题不在A机，而是B机的ARP表出幺蛾子了。我这么想的，"arp -d"之后ping，会触发ARP请求，这种报文会刷新B机ARP表；重启A机后从A机访问B机，也会触发ARP请求，同样会刷新B机ARP表。B机ARP表中A条目正常时，BBS正常；B机ARP表中A条目异常时，A机与B机之间IP层通信受阻，外在表现包括但不限于ping不通、1433/TCP不可达。该猜测解释得通现有现象，但我没有B机管理员账号，联系LCG去检查B机ARP表。

LCG在B机ARP表中果然发现异常A条目，表中A的MAC不是A的，是一个未知MAC，我的猜测得到确认。LCG去交换机上查了该未知MAC，对应到另一台设备，后者被错误配置了A机IP。换句话说，此处存在IP冲突，但不知为何A机本身未告警，那台设备亦未告警，可能与网络拓扑相关，但我不是信管部的，不清楚具体情况。这个IP冲突致使B机ARP表中A条目不稳定，有时指向A机，有时指向另一台设备。

找到终极原因之后，解决之道显而易见，给另一台设备配置其他IP。

没啥高深技术卷入其中，只是觉得排查过程值得记一笔。以前写过另一篇类似风格的

《一次离奇的DHCP故障排查》
http://scz.617.cn:8/windows/201806181530.txt