实验室服务器网络问题排查

最近学校机房的服务器都受到了来自校园网内部服务器的挖矿病毒攻击，由于一开始为了方便而没有限制“只可以通过 SSH 密钥登录服务器”，导致我们实验室的服务器也中招了🫥。后续排查问题的过程中发现中招的核心原因是当时用于测试的账号忘记及时删除，导致服务器被彩虹表攻击攻破了。还好挖矿病毒只是用服务器上的两块 3090 被用来挖了几天矿，没有造成其他太大的影响（不然又得重新去机房配置一遍服务器了😌）。事后及时清理了服务器上的挖矿程序，设置了更严格的机制保障了服务器的安全，一切安好，无事发生，Very Good。

然而就在修好服务器的隔天（11 月 1 号）就有同学反应实验室服务器无法使用校园网服务。起初我以为是校园网内部服务的 API 接口发生了变化导致的相关脚本失效，然而仔细检查后发现校园网相关的服务接口实际上没有发生变化，且在我本地主机上是可以正常访问的。

问题排查

由于刚遭受了挖矿病毒的攻击，因此我首先把问题定位在了“挖矿病毒修改了服务器的网络配置”上，仔细排查了服务器的网络配置，并再次检查了挖矿病毒所登录账号的历史命令记录，想找到一些与网络配置相关的命令，最后再次确定挖矿病毒只是纯粹的部署了一个挖矿程序，仅此而已，因此可以直接排除掉是挖矿病毒的影响¹。

既然网络配置没有问题，那么可能是服务器上的代理服务出了差错，我对代理服务的状态、代理服务器的规则配置进行了排查，发现配置文件没有被修改过，代理服务器也是在正常运转的，不太可能是因为代理服务的问题。但是考虑到校园网薛定谔般的 dns 解析规则，我也尝试了将代理关闭后去使用校园网服务，发现还是无法正常访问。

之后我对 API 接口请求链路进行了排查，简单来说就是通过 curl 和 ping 命令对校园网服务和对应的服务器发送网络请求²，通过获取网络请求的发送与接收信息来分析网络问题。对于 curl 而言，在使用代理服务发送请求时网络连接会被 reset，而不使用网络代理服务发送请求则无法获取到服务的 ip 地址。考虑到无法正常获取到服务的 ip 地址，我在本机上抓到了校园网服务器的内网 ip，并在服务器上用 ping 测试了网络连通性，发现服务器无法 ping 通校园服务器。这就非常奇怪了，因为校园网服务器机房我去过几次，距离计算机楼服务器机房只隔了一百米不到，不应该会有这种问题³。通过 nslookup 尝试解析校园网服务，发现无法正常解析，对比了一下我本机的 dns 服务器地址和服务器上的 dns 地址，发现 dns 服务器地址的配置（172.19.2.1 和 172.19.2.2）是一样的，说明 dhcp 有在正常工作。

所以最终问题落在了 dns 解析上。我尝试在服务器上 ping 了几次 dns 服务器（172.19.2.1 和 172.19.2.2），发现两个服务器都可以正常 ping 通但是无法使用上面的 dns 服务。我又多 ping 了几次，发现了不对劲的地方，我明明是 ping 的 172.19.2.1，但是 ping 命令的输出却是告诉我在 ping 172.19.0.1，我越看 172.19.0.1 这个 ip 越觉得熟悉，这不就是 docker 默认分配的网段吗？我马上反应过来了：之所以无法使用校园网服务，是因为学校的新 dns 服务器的 ip 地址配置和实验室服务器上某个 docker 容器的网络地址发生了冲突⁴，docker 容器网络在创建时默认配置的 iptables 规则将发向 dns 服务器的请求转发了到了 docker 容器中。

服务器当前的网络接口情况如下，可以看到刚好有一个网络地址分配为 172.19.0.1 的容器网络，就是这个容器网络所对应的 iptables 规则转发发往了 dns 服务器的请求。

查看使用该网络的服务：

可以看到是一个无关紧要的网络，直接删除即可。删除后实验室服务器网络终于恢复了正常。

事后把这次奇妙的网络问题排查经历和实验室的同学进行了分享，有个同学提到之前在校内的虎踞龙盘论坛上有见到过吐槽新 dns 服务器地址与已有 docker 容器网络冲突的帖子，所以这个问题看来是比较普遍的。看到贴子里有网信中心的老师回复说会对这个问题进行处理，但是直到现在也没有见到结果😅。事后猜测可能学校网信中心负责搭建新 dns 服务的老师 / 同学图省事直接用 docker 部署了 dns 服务，因而产生了上面的乌龙。平时使用 docker 容器基本都是自己本机来用，没有考虑过重新配置容器的默认网络地址规则来避免冲突，这次网络问题排查也算是给自己提了个醒，以后排查网络问题的时候也可以尝试检查一下 docker 容器的网络配置。