Earlier we upgraded the core switch of Skyworks’ serverroom to a Cisco Nexus 92160YC-X, a 48-port 25GbE datacenter switch. We also upgraded the connection of Skyworks’ gateway to the switch from 2x10GbE to 2x25GbE LACP. Days ago, I upgraded my server from 1x25GbE to 2x25GbE LACP. Dolphin told me that despite the 50Gbps aggregated bandwidth, iperf3 tests can reach to only about 41Gbps. He and 6dx suspected a saturated CPU on the server, but when I ran the test, I got similar results, with not a single 100% busy core.

UDP tests yeilded approximately the same result, which make me think: what’s the root of the problem, were it not CPU saturation? Here is the investigation.

TL, DR: Web browsers send Sec-Fetch-Mode: navigate header when accessing a page, while curl does not. With STATIC_FILES bindings in Cloudflare Workers:

1
2
3
4
5

"assets": {
  "directory": "./public/",
  "not_found_handling": "404-page",
  "binding": "STATIC_FILES"
}

Cloudflare will directly serve static files with Sec-Fetch-Mode: navigate present and return 404 if file not found, without invoking the Worker script. Without this header, Cloudflare will invoke the Worker script, which may return 200.

The solution: add "run_worker_first": ["/Ajax.gpg*"] to ask Cloudflare to always invoke the Worker script first for matching paths.

这篇博客简单介绍了一下 Cloudflare 的 mTLS 功能, 以及如何配置.

这周一, 我在更新交流群二维码的时候发现 app.cs.tsinghua.edu.cn (以下简称 app.) 502 了, 登录进去之后发现 Tinc VPN 出现了奇怪的问题, 遂进行了一些配置调整; 周三, 我校园卡没钱了, 用 APP 充值失败, 我发现又 502 了, 遂晚上调查, 发现多个 “无害” 更新共同作用, 产生了奇怪的后果: 我自己写的蜜罐封禁了我自己的 IP.

最近课题组里面要用 QCAT 分析一些从手机里面采集出来的高通基带的数据. 这个 “重任” (其实当时我们并不觉得这是什么重任, 毕竟就是个用 QCAT 导出数据的活) 落到了我头上. 于是我用一个小数据样本开始折腾 QCAT 导出. 在小样本上, 导出还算顺利; 但最终当我们需要在所有 (~300GB) 的 log 中导出数据的时候, 我们遇到了显著的问题, 无法一次性打开这些文件 (QCAT 会慢的要死, 打开所有的文件可能需要半个小时? 但是谁知道 QCAT 到底有没有动, 是不是直接就死掉了), 需要一个一个完成. 既然如此, 写脚本就是必要的了. 于是我和 QCAT 的脚本斗争了两三天, 气得要死; 在和学长讲应该如何使用的时候, 学长表示,

你这应该记录下来, 不然过个几个月就又没有人知道该咋整了.

故作此.

我们用到过很多种 VPN (和混淆) 的手段. WireGuard, Tinc, OpenVPN, SSLVPN, VMess, VLESS, Xray… 它们各自有各自的优势, 但又或多或少都有一些问题. 为了一些独特 (感觉并不独特) 的需求和一些人炫技的小心思 (反正不是我就对了), 我们提出了 QUICAP - 一个基于 QUIC 隧道的, 采用 PKI 系统鉴权的, 可以方便地进行修改和混淆的, 可以同时启用或选用二层隧道 / 三层隧道或应用层代理的, 能够自动优化路由以应对拓扑变更的网状 VPN 方案.

We have utilized a variety of VPN and obfuscation solutions, including WireGuard, Tinc, OpenVPN, SSLVPN, VMess, VLESS, and Xray. Each offers distinct advantages but also presents certain limitations. To address specific requirements and enhance flexibility, we introduce QUICAP—a mesh VPN solution built on QUIC tunneling, featuring PKI-based authentication. QUICAP is designed for easy modification and obfuscation, supports both Layer 2 and Layer 3 tunneling as well as application-layer proxying, and can automatically optimize routing in response to network topology changes.

今天闲得慌, 就手痒痒想给 Nginx 上 QUIC, 于是小小折腾了一番, 兼论如何正确配置监听…

在过去的两个月里我系统性的对我 (其实是我们实验室) 感兴趣的部分目标进行了细致的网络测绘, 以期更好地理解其网络结构和运行方式, 找到潜在的问题, 指导未来的研究与工程实践. 在此过程中, 我写了一大坨功能各异的脚本, 使用了各种工具, 遇到了一大堆的问题, 积累了一些经验. 本文希望记录这些问题, 免得自己忘了. 此工作尚未发表, 因此这里隐去我们的实际的目标, 仅对方法和工具做讨论.

这篇文章可能会随着进一步的测绘工作而持续更新.

两三个星期前, 杨敬找到我, 问我有没有时间. 我当时就觉得不妙, 肯定没好事 肯定又是什么东西要配网了 (我真不想用那一套老掉牙的思科了). 我没有拒绝 (这学期事情也不是太多吧, 你清可能也确实找不到另外一个有我这个资源, 经验和手段的人…), 于是我就糊里糊涂变成了网络负责人. THUPC 圆 满 结 束 了, 是时候做一个总结了.

在 之前的文章 里我们讨论了开放代理可能带来的问题. 由于 Docker Registry 被墙了, 我又不想自己贡献自己的梯子, 又想做一个可用的 Registry Mirror, 于是我决定利用一下之前发现的问题, 于是有了这篇文章. 这篇文章讨论了实现的技术难点与解决方案. 本方案已经稳定运行了 3 个月, 代码开源于 我的 Github 仓库.