从 iNode 到 systemd：我如何指挥 Codex 处理一次真实网络排障#

先搭一条不会死的路#

我一开始的目标很简单：N100 不装桌面，不装 Windows，只作为长期运行的 Ubuntu Server。

问题也很直接：学校有线网使用 H3C/iNode 客户端认证，网络中心明确说不支持 Linux 客户端。Windows 上可以点 iNode，Ubuntu Server 上没有这个按钮。

这时最容易犯的错，是急着让 Codex 开始“破解”校园网认证。

Codex 没有这么做。它先要求我建立一条救命管理链路。

最终现场是这样：

1
R7000 笔记本 Wi-Fi 上网
2
R7000 有线口直连 N100 的 enp2s0
3
Windows ICS 提供 192.168.137.0/24
4
N100 固定为 192.168.137.2
5
N100 的 enp1s0 再接校园墙口做实验

这一步不性感，但它决定了后面能不能安全试错。

如果没有这条管理线，每次改路由、重启网络服务、测试 DHCP 都可能把自己锁在机器前。Codex 能做很多事，但它不能替我把网线插回去，也不能在 SSH 断掉以后凭空继续操作。

所以第一件事不是写脚本，而是给 Codex 一个不会让它失明的现场。

人负责边界，Codex 负责收敛#

这次排障里，我最深的感受是：人不需要亲手做每个技术动作，但必须知道 Codex 解决问题真正需要什么。

它需要稳定的控制通道。

它需要清楚的接口角色。

它需要命令输出、抓包、日志、路由表、服务状态，而不是“好像不通”“应该是这个口”。

它还需要明确的约束：什么可以动，什么不能动；什么能重启，什么要先确认；真实账号、密码、MAC、pcap 不能进公开仓库。

我给 Codex 的不是“帮我联网”这类模糊愿望，而是一组现场条件：

• enp2s0 是管理口，必须保 SSH。
• enp1s0 是校园口，允许实验。
• 默认路由不能随便被校园口抢走。
• 任何可能断开 R7000、Codex 或 N100 SSH 的操作，都要先停下来确认。
• 账号、密码、MAC 只在本机私有配置里使用。

有了这些边界，Codex 才能大胆地做执行工作。

它会先只读检查，再小步修改。它会在每次行动前说明影响范围。它会在命令超时后回头确认状态，而不是猜“应该成功了”。它会把失败当成证据，而不是当成挫败。

这才是我觉得 Codex 最有价值的地方。

抓包终止了猜测#

校园网认证一开始有很多可能方向。

也许是普通 PEAP/MSCHAPv2？也许 wpa_supplicant 写个配置就行？也许某个开源 H3C 客户端能直接用？

Codex 没有停在这些猜测上。它让我先做被动抓包，再做受控主动探测。校园口不拿 IP，不改默认路由，只看二层发生了什么。

第一次被动抓包几乎没有东西。主动发 DHCP 只有 Discover，没有 Offer。然后主动发 EAPOL-Start，交换机终于返回了 Identity 请求。继续回应 Identity 后，关键包出现了：

1
EAP Request Identity
2
EAP Response Identity
3
EAP Request Type 7
4
EAP Response Type 7
5
EAP Success / Failure

这一步把方向定死了：不是普通 PEAP/MSCHAPv2，而是 iNode/H3C 的 Type 7 流程。

后面 Codex 拉了几个开源实现做静态分析，也尝试了低风险握手。但通用实现都失败了。它没有继续撞真实账号，而是要求我回到 Windows iNode，抓一次成功认证包。

这里的分工很典型。

Codex 能告诉我应该抓什么、怎么抓、哪些字段关键、哪些工具没用。比如 Charles 抓不到 EAPOL，因为那是二层帧，不是 HTTP 流量。

但我必须提供硬件现场：把 R7000 的网线从 N100 拔下来，接到校园墙口；关闭 ICS，让 Windows 有线口恢复普通 DHCP；启动 iNode；认证成功后再把线切回 N100。

Codex 负责看包，我负责让它看得到包。

误判不断出现，但都被证据拉回来#

这次过程里出现过很多看起来合理的误判。

比如最初 Windows iNode 也认证失败，很容易以为是 Type 7 算法不对。后来抓包和日志说明，问题更像是有线账号的 MAC 绑定不匹配。协议走到了 Type 7，但服务器直接回 EAP Failure。

比如 N100 上 ping 192.168.137.1 不通，也容易以为 R7000 管理线没通。Codex 从 R7000 侧反向测试，发现 192.168.137.2 能 ping，ARP 也解析到了 N100 的 MAC，22 端口也开着。最后判断只是 Windows 防火墙不回 ICMP。

比如我一度怀疑 BBR3 导致网络异常。Codex 先看内核参数，发现当时拥塞控制还是 cubic，可用算法里也没有 BBR。更关键的是，BBR 只影响已有 IP 连通之后的 TCP 拥塞控制，管不到 EAPOL、DHCP、ARP。

这些场景让我意识到：复杂排障里，最危险的不是不知道，而是太快相信一个顺耳的解释。

Codex 的价值不是永远正确，而是它会持续把解释拉回可验证证据。

从“跑通一次”到“重启后还在”#

第一次拿到 EAP Success 时，其实还远远没结束。

认证成功之后，要 DHCP。DHCP 成功之后，要路由。路由正确之后，要 DNS。DNS 正常之后，还要 systemd 重启后自动恢复。

更麻烦的是，校园交换机会周期性发起身份检查。我们最初的脚本可以认证成功，但它每隔一段时间主动发 EAPOL-Start，反而和交换机自己的保活流程撞车。结果就是过一会儿收到 EAP Failure，链路又掉了。

最后稳定下来的策略很克制：

• 未认证时，每 5 秒重试 EAPOL-Start。
• 认证成功后，停止主动 Start。
• 平时只响应交换机发来的 Identity 和 Type 7。
• 收到 Failure 后，回到未认证状态重新开始。
• 认证成功后写入 /run/sufe-8021x-authenticated。
• DHCP 服务等待这个状态文件，而不是赌一个固定 sleep。
• DHCP 拿不到租约时干净失败，不继续写错误默认路由。

这不是“AI 一次性生成了完美脚本”。

真实过程是：跑通，重启，失败；看日志，改状态机；再重启，再观察；发现周期性 Failure，再抓包；改 EAPOL-Start 策略；最后等待 90 秒、再重启验证。

Codex 在这里像一个有耐心的工程同事。它不嫌烦，也不会因为“刚才成功过”就提前宣布结束。

我真正做了什么#

如果把这次实践简化成“Codex 写了一个 802.1X 脚本”，那就漏掉了大半价值。

我真正做的是现场总控。

我准备了 R7000、N100、两根网线、显示器键盘、Windows iNode、Wireshark/tshark、校园墙口和可用账号。

我在关键时刻换线、开关 ICS、关闭 TUN、输入 sudo 密码、确认 UAC、决定是否重启、判断能不能临时伪装授权 MAC。

我也负责不断提醒边界：不要断 SSH，不要暴露服务，不要把真实账号密码写进仓库，不要为了方便把服务器直接裸露到校园网。

这些事听起来不如写代码酷，但它们正是 Codex 做好工作的前提。

Codex 能把排障步骤推进得很快，前提是我能提供一个可操作、可观测、可回滚的环境。

我不需要做什么#

我不需要从头背 802.1X 协议。

我不需要手动比较每个 EAP payload。

我不需要自己去读一堆 H3C 开源客户端源码。

我也不需要把每条 ip route、resolvectl、tcpdump 命令都记下来。

这些工作交给 Codex 就行。

人的精力更应该放在判断上：现在缺的是抓包，还是日志？是认证没过，还是 DHCP 没来？是校园口问题，还是 R7000 ICS 问题？这个改动会不会断掉管理线？这个结论有没有被重启验证过？

当我把问题问清楚，把现场搭好，把边界说清楚，Codex 就能承担大量具体劳动。

最后跑起来的样子#

最终重启后，网络形态稳定成这样：

1
sufe-8021x.service active/running
2
sufe-campus-dhcp.service active/exited
3
enp1s0 10.x.x.x/xx
4
enp2s0 192.168.137.2/24
5
default via campus-gateway dev enp1s0 metric 50
6
default via management-gateway dev enp2s0 metric 500

校园口负责主出口。R7000 管理口保留为低优先级备用。Tailscale 可用后，甚至可以拔掉 R7000 管理线，用 Tailscale IP 直接 SSH。

同时，校园网口没有暴露 SSH、1Panel、Jellyfin、Immich 等服务。管理入口保留在可信管理网和 Tailscale 上。

这台 N100 从一台“没有桌面、没有校园网客户端、随时可能失联”的裸 Ubuntu Server，变成了一台可以继续部署服务的实体服务器。

这次经历给我的方法论#

以后我再让 Codex 处理类似问题，会先问自己几个问题。

我有没有给它一条不会断的控制通道？

我有没有把实验面和管理面隔离开？

我有没有把目标拆成可验证的小阶段？

我给它的是现象描述，还是足够的证据？

每个修复有没有清晰的回滚方式？

最后有没有从干净重启状态验证？

这套方法不只适用于校园网，也适用于很多现实世界里的系统问题。

人不必和 Codex 抢具体执行权。更有效的分工是：人负责统筹、边界、现场资源和最终判断；Codex 负责持续执行、验证、记录和收敛。

当问题足够复杂时，真正重要的不是“AI 会不会某个命令”，而是你能不能把现实世界组织成它可以工作的样子。

代码和文档#

公共脚本和操作指南整理在这个仓库里：K1ndredzzz/sufe-linux-8021x。

真实账号、密码、绑定 MAC、原始 pcap 和 iNode 日志不会进入仓库。

仓库里保留的是可复用的部分：最小 Type 7 认证脚本、DHCP/路由脚本、systemd 单元、排障手册和抓包分析笔记。

如果以后重启后断网，我不会再从头猜。先看管理口 SSH 是否还在，再重启两项服务：

1
sudo systemctl restart sufe-8021x.service
2
sudo systemctl restart sufe-campus-dhcp.service

然后看服务状态、地址、路由和 DNS。复杂问题最后能变成这几条命令，才算真正被收束过。