一、背景#
公司的网络在前段时间非常不稳定，早上上班的时候会有打不上卡和无法浏览网页的情况。白天也会偶发网络阻塞，经测速，下行速率砍半，上行速率几乎为 0。
起初以为只是电信线路故障与园区早晚高峰网络拥堵所致，但是时间持续之久与频次之高实在令人乍舌。在领导与人事抱怨很多次之后我开始逐渐重视起这一问题。
凭借多年来的经验，我设想了以下几个原因并开始一一排除：
- 园区电信线路故障或被限速
- 早高峰设备接入量、并发量高，超出机房设备承载极限
- 随着公司人数增加，AC 与 AP 过载
- 春夏气温回升，机房设备温度过高 ++（有几台设备是依靠被动散热，确实有过热降频风险）++
二、尝试解决#
1. 更换线路#
原先公司接入的是电信200M的公网宽带，上行只有30M，而且这片园区大多用的都是电信，早高峰波动的确很大。于是在跟领导简单商量之后直接更换为了联通1000M的宽带，上行速率直接达到了100M。
这里吐个槽，联通工作人员太会挑时间了，等了一上午不见人影，离中午快下班的时候火急火燎过来两个师傅。我陪他俩加班干了一个中午，饭都没吃上热乎的，饿死我了。
更换线路的确有用，但是不大，因为第二天早上又出现了阻塞现象。
2. 监控机房设备#
机房大部分的设备的确性能已经不佳，但是令我疑惑的一点是近期公司并没有大量人员入职，并发量也没有出现激增的情况，怎么会在近期突然频繁卡顿呢。在设备后台监控 2 天有余以后，我否决了这个因素，因为硬件性能根本一半都没吃满，温度更是无稽之谈。
3. 更换 AC、AP#
公司的 AC 一直都有个问题，那就是 ++ 吞掉了将近一半的网络带宽 ++。起初因为 AC 网口较多，我将 AC 作为三层交换机来使用，一开始以为是因为 AC 承载能力不够所以导致出口带宽削弱了一半，但是当我拔掉所有不必要的跳线以后，单独测试 AC 仍然只能在局域网跑到一半的速率。索性直接向公司提预算换掉了 AC 与 AP 设备。
AC 选用的是H3C小贝优选RT-UR7208-P-E，AP 选用的是H3C EWP-UAP673。最高带机量 300，也足够公司使用了。换掉之后局域网速率确实跑上来了，也没有再出现之前吞掉局域网一半带宽的情况，但是网络阻塞情况仍然会发生。
== 所以问题到底出在哪？==
三、Clash 端口暴露#
硬件排查过之后，我开始将目光聚焦到软件上。在旁路由上查了查目前全公司的流量出口，上行流量较往月异常增加了20%~30%（++ 其实上下行流量当时拜托电信师傅帮忙在电信后台查了一下，但是师傅告诉我并没有问题，于是我在一开始也就疏忽了这一点 ++）
在观察到上行流量异常后，我开始在局域网逐个排查哪个 IP 出现了异常情况，起初以为是内部有人在利用公司宽带跑P2P或PCDN，但是一顿排查下来局域网 IP 并没有发生上行异常占用的问题，反倒是 Clash 服务列表里面多了几个公网 IP。通过 IP 反向查找域名，我发现这几个 IP 大多是俄罗斯那边的 TV 公司。带着Clash、上行流量异常、俄罗斯等关键词，我在 Github 上检索到了这样一篇求助帖。这里贴出原帖链接供大家参观
https://github.com/vernesong/OpenClash/issues/2629
::: grid {cols=2}
:::
看到这里我恍然大悟，公司的旁路由是作为 DMZ 主机来使用的，因此有许多端口暴露在公网，这次的异常上行带宽事件很大概率是被爆破病毒扫描到端口开放，从而使旁路由被当作跳板机或加速机来使用。于是我将 7890 端口关闭，且设置了防火墙规则仅允许局域网设备出口。在观察上行流量后，从 8-9M/s 渐渐的降为 200Kb/s~2M/s，同时测速网站显示上下行带宽已恢复为正常，Clash 中出现的莫名的俄罗斯 IP 也消失了。
== 所以这次的事件就暂且告一段落。==
https://www.xiaohanwu.com/thinking/66276cf3176d45931ddc9e21
四、结语#
虽然这次事件并不是病毒感染，只能算是网络漏洞，但是漏洞最终使用方竟然是俄罗斯一家规模较大的 TV 服务商，不得不让人联想到 TV 服务商与黑客勾结来获得大量非法网络 CDN 加速服务。
纵观国内也有许多不知名且号称免备案的 “高防 CDN”，其因价格低廉且免备案因此受到很多站长的推崇，当时因囊中羞涩也差点考虑这些不知名的 CDN 服务，然而这次的病毒事件让我对这些小 CDN 服务有了全新的看法。
此文由 Mix Space 同步更新至 xLog
原始链接为 https://www.xiaohanwu.com/posts/IT/3