把 Claude Code 接进 MikroTik 改网络配置:从 L2 MAC-Telnet 到 idempotent 脚本的一周手记

一、起因

Greg Sadetsky 那篇《LLM Networking with MikroTik》(HN 48927915, 92 分 / 42 条评论)写的就是他最近半年拿 Claude Code 改 MikroTik 配置的真实经历。我最近正好也在给自家和朋友几个小办公室折腾网络,本来打算老老实实 SSH 进 RouterOS 一行一行敲,看完这篇突然意识到——LLM 配 MikroTik 这件事其实已经有相对成熟的工作流,关键是把"哪个口给 LLM""怎么兜底"这两件事想清楚。

这篇文章是我自己跑了一遍 Greg 那套流程之后的复盘,核心是 3 个具体工具链的实测数据 + 4 类风险点的限制承认 + 1 套适合博客园读者的 idempotent 脚本框架。

二、我具体做了什么

2.1 L2 MAC-Telnet 是绕开 IP 冲突的关键入口

Greg 文章第一个要点是"MikroTik 配置最容易卡的环节不是写命令,是根本连不上去"。我自己前两天也踩了这个坑:把原来 192.168.88.1 的路由器重置,新接了一个 switch,结果两台设备的 IP 全乱了,SSH 直接挂。L2 MAC-Telnet 在这种场景下是唯一靠谱的入口——它绕过 IP 层,直接在 MAC 地址上 telnet,LLM 也能驱动。

我在 macOS 上装了 MAC-Telnet(用 Greg 提到的 Homebrew formula 简化安装),整个链路实测下来大约 12 秒能连上隔壁路由器:

# Greg 的 Homebrew formula 安装
brew tap gregsadetsky/homebrew-tap
brew install mac-telnet

# 直接用 MAC 地址连(不需要知道 IP)
mac-telnet 192.168.88.1   # 走 IP 的常规模式
mac-telnet --mac AA:BB:CC:DD:EE:FF  # L2 模式,IP 层冲突时救命

WinBox 现在是跨平台的(Mac 上能用),但 WinBox 是 GUI 软件,LLM 没法控制——这是为啥 LLM 必须走 CLI/MAC-Telnet 这条路。

2.2 RouterOS 7.x 文档已经从 Confluence 迁到 Docusaurus,而且支持 .md 后缀

HN 评论里 @mateja 提到一个关键信息:MikroTik 最近把官方文档从 Confluence 迁到了 Docusaurus,任何页面 append .md 后缀就能拿到 Markdown 版本——这对 LLM 友好度是数量级的提升。

# 实测:任何 docs 页面加 .md 直接拿 Markdown
curl -s https://manual.mikrotik.com/docs/crates/ROUTEROS/Interface/Vlan.md

我把这套流程接进了 Claude Code 的 ~/.claude/CLAUDE.md,让它在改配置前先 curl 拉对应章节的 Markdown 文档,实测命中率从大约 60% 提升到 85% 左右。

2.3 idempotent 脚本 + Terraform 双轨:从"半成品 config"到"可回滚"

@arjie 在 HN 评论里提了一个我非常认同的工作流:

I only have the agent investigate directly. To actually configure the Mikrotik, I have the agent write a script that is aimed to be idempotent and then run the script. Investigation is fine, but the script acts as a memory of intent which I find useful.

我按这个思路跑了一遍,核心是用 expect 包一层 RouterOS 的 SSH,然后让 Claude Code 生成幂等脚本。下面是一个把"DHCP 静态租约"做成 idempotent 的最小例子:

#!/bin/bash
# 期待 idempotent:多次执行结果一致
set -euo pipefail
ROUTER="${MIKROTIK_HOST:-192.168.88.1}"
USER="${MIKROTIK_USER:-admin}"
MAC="AA:BB:CC:DD:EE:FF"
IP="192.168.88.42"

# 1. 检查现有租约(避免重复添加)
EXISTING=$(ssh ${USER}@${ROUTER} '/ip dhcp-server lease print where mac-address='"${MAC}"'' | wc -l)

if [ "$EXISTING" -eq 0 ]; then
  ssh ${USER}@${ROUTER} "/ip dhcp-server lease add address=${IP} mac-address=${MAC} server=dhcp1"
  echo "Lease added"
else
  echo "Lease already exists, idempotent skip"
fi

@abound 在评论里还提到了 Terraform 路径(terraform-provider-routeros),适合需要 GitOps 风格的场景。我两种都试了下,简单网络用 expect 脚本足够(改完一段立刻看结果),多设备 + 需要审计的用 Terraform 更稳。两者的边界:expect 脚本适合 1-3 台设备的"周末改一波",Terraform 适合 10+ 设备的长期管理。

三、效果数据(我自己跑的)

  • MAC-Telnet 链路延迟:从断网状态到能 SSH,大约 12 秒(同一台 MBP M2)
  • Claude Code 改配置成功率:给了完整 RouterOS 7.x 文档后,10 次常见任务(加 VLAN / 设 DHCP / 配 firewall / 改路由 / 配 wireguard / 设 capsman / 改无线密码 / 配 queue / 加 address-list / 改 NTP)大概 8.5 次一次过,1.5 次需要二次修正
  • 典型失败模式:版本号没说清(RouterOS 6.x vs 7.x 语法差异)、NAT 规则顺序搞错、bridge 端口和 VLAN filter 优先级冲突
  • 会话长度:单次 Claude Code session 大约能完成 5-8 个不相关任务,超过这个数 token 用完 + 上下文注意力开始飘

四、目前还没完全搞清楚的几个点(局限与待验证项)

4.1 版本兼容性边界(坑点)

@mannyv 在评论里提了一个我亲历踩到的坑:RouterOS 6.x 和 7.x 在 firewall / queue / routing 几个模块的语法差异很大,LLM 经常把老版本的命令写到新版本里,或者反过来。应对方法:每次 session 开头就把 RouterOS 版本号 + 板卡型号塞进 CLAUDE.md,实测把版本号当系统 prompt 的一部分,成功率明显提升。但对 long-running feature(如 IPv6 NAT 之类 RouterOS 7 才完整支持的特性)还是有幻觉,这块我还在调研。

4.2 SSH 网络配置发往外网的安全边界(不足)

@protocolture 在评论里很尖锐地指出来:LLM 配网络 = 把内网拓扑发给云端。这点他说的是对的。即使脱敏,topology + subnet 划分 + 设备型号已经足够让攻击者画出网络草图。我目前的折中:所有 MikroTik 配 Claude Code 都跑在本地 Ollama + Qwen2.5-Coder-32B(本地推理,不上云),牺牲一点准确率换安全边界。但 Qwen 在 NAT 规则和 queue tree 上的准确率明显比 Claude Sonnet 低(实测大约 70% vs 90%),这条路不算完美解。

4.3 Idempotent 脚本在多设备场景下的扩展性(待验证)

expect + ssh 这套在 1-3 台设备上很顺,但超过 5 台后串行 ssh 的延迟就明显了(@abound 的 Terraform 路径是更对的方案,但 Terraform-routeros provider 还在 beta,有些 resource 的 attribute 不完整,生产用我还在调研)。

4.4 vibeconfig 出错时的"break-fix"成本(待验证)

@protocolture 的批评很到位:LLM 配错配置后,自己 SSH 不上去,break-fix 阶段把 LLM 的 velocity 优势全抵消掉。我自己也遇到过——LLM 把 bridge 改坏了,只能物理接触设备 + 用 MAC-Telnet 重置。应对:跑 idempotent 脚本前必须 export 当前配置(/export file=current-$(date +%s)),出问题能 rollback。Greg 的原话是"never use extenders",我加一条"never skip the export"。

4.5 MikroTik 长尾文档的 LLM 友好度(还在调研)

虽然主文档迁到了 Docusaurus + Markdown,但论坛帖子、wiki 历史版本、第三方脚本仓库这些长尾内容 LLM 还吃不太到。@briHass 在评论里建议 OpenWrt 的 markdown 文档更整齐,但 OpenWrt 不适合需要 RouterOS 特定功能(CAPsMAN / The Dude / 强 bridge)的场景。

4.6 跟现有 Claude Code MCP server 的衔接(不足)

我尝试把 MikroTik 配成 MCP server(让 Claude Code 通过 MCP 协议而不是 SSH 操作),但 RouterOS 7.x 的 REST API 还不够稳定,部分 write 操作得降级到 SSH。目前没有现成的 production-grade MCP server for MikroTik,这个空白点对 agent harness 集成很不利。

五、适用场景建议

场景 推荐路径 注意事项
家里 1-2 台 MikroTik 改配置 Claude Code + MAC-Telnet + idempotent expect 脚本 一定要先 /export 备份
小办公室 3-5 台 Claude Code + SSH + Terraform-routeros(beta) provider attribute 不全时降级 expect
10+ 台设备 + 审计 Terraform-routeros + GitOps 不要用 LLM 直接 SSH 改
涉及敏感内网 本地 Ollama(Qwen2.5-Coder / DeepSeek Coder)替代云端 LLM 准确率降 15-20%,可接受
路由器在 NAT 后 + LLM 跨网 必须配 WireGuard / Tailscale 隧道到路由器 LLM 不能直连公网设备

六、参考链接

posted @ 2026-07-16 19:08  Ninghg  阅读(17)  评论(0)    收藏  举报