路由器

RouterOS 7.24beta3 App平台开启后 hermes-agent 为何无法与宿主机通信？一次 netns 网络命名空间隔离的排查记录

RouterOS 7.24beta3 开启 App 平台后，hermes-agent 通过 veth pair 与宿主机通信失败，根因是 ip netns exec 进入隔离命名空间后未正确配置路由与 DNS，导致 agent 无法回连宿主侧的 hermes 服务。

问题背景

RouterOS 7.24beta3 开发版引入了全新的 App 平台，允许用户在路由器上运行独立的 Linux 容器化应用（类似 LXC/Docker）。官方同时发布了 hermes-agent 作为宿主机与 App 之间的通信桥梁，负责配置下发、状态上报与远程管理。

我正在 Hyper-V 上运行 RouterOS 7.24beta3 VM（VHDX 磁盘，6 GiB），目的是测试 App 平台 + hermes-agent 的实际表现。计划让 hermes-agent 作为「宿主机侧 agent」，通过 veth pair 与 RouterOS 内的 App 容器通信，实现「宿主 → RouterOS → App」的双向控制链路。

然而在开启 App 平台并安装 hermes-agent 后，宿主机始终无法与 App 内的 agent 建立连接，表现为 ping 不通、TCP 端口拒绝、DNS 解析失败。官方文档仅提供「ip netns exec 」的示例，未说明跨命名空间路由与 DNS 的正确配置方式。

故障现象

  1. 基础连通性异常：在宿主机（Windows Server 2022 + Hyper-V）上执行 ping 10.255.255.2（App 侧 veth IP）全部超时；反向从 App 内 ping 宿主机 IP 也失败。
  2. TCP 端口不可达：hermes-agent 默认监听 28080 端口，宿主机 telnet 该端口直接拒绝（Connection refused），而非超时，说明路由可达但应用层拒绝。
  3. DNS 解析完全失效：App 内执行 nslookup 或 curl 任何域名均返回 Temporary failure in name resolution，即使宿主机已配置 DNS。
  4. hermes-agent 日志：容器内 /var/log/hermes-agent.log 反复出现： 
    1
2

    [ERROR] Failed to connect to hermes service at 172.16.1.13:28080: No route to host
[ERROR] DNS resolution failed for hermes.example.com
  5. netns 状态异常：执行 ip netns list 显示 hermes-app 这个命名空间存在，但 ip netns exec hermes-app ip addr 仅看到 lo 和 veth-hermes-app@xxx 接口，没有默认路由，也没有 DNS 配置。

排查过程

步骤 1：确认 veth pair 创建与绑定

首先确认宿主机侧 veth pair 是否正确创建：

1
2

# 宿主机侧（Windows PowerShell with elevated）
Get-NetAdapter | Where-Object {$_.Name -like "*hermes*"}

输出显示 vEthernet (hermes-host) 已存在，IP 配置为 10.255.255.1/30。

RouterOS 侧：

1
2

/interface/veth print
/interface/veth print detail

确认 veth-hermes-app 已创建并绑定到 hermes-app 这个 netns。

步骤 2：进入 netns 检查路由表

关键问题出现在这里：

1

ip netns exec hermes-app ip route

输出为空！只有本地回环路由，没有默认路由，也没有到 10.255.255.0/30 的直连路由。

而宿主机侧的 veth-hermes-host 虽然配置了 IP，但 没有开启 IP forwarding，且 Windows Hyper-V 的 vSwitch 默认隔离了该 veth pair。

步骤 3：检查 DNS 配置

App 内 /etc/resolv.conf 内容为：

1
2

nameserver 127.0.0.53
options edns0

这是一个 systemd-resolved 的占位地址，在隔离的 netns 里根本没有 systemd-resolved 进程在跑，导致所有 DNS 查询失败。

步骤 4：测试跨 netns 连通性

尝试从宿主机直接进入 netns 执行命令验证：

1

ip netns exec hermes-app ping 10.255.255.1

仍然失败，提示 Network is unreachable。

进一步检查发现：veth pair 的两端虽然创建了，但宿主机侧的 veth-hermes-host 没有配置任何 IP 地址，而 RouterOS 文档示例里「ip netns add」后直接用「ip link set」把 veth 移入 netns，却没有说明宿主机侧需要配置对端 IP 并开启 proxy_arp 或开启 IP forwarding。

步骤 5：检查 RouterOS 7.24beta3 App 平台实现细节

RouterOS 7.24beta3 的 App 平台实际上是基于 namespace + mount namespace + cgroup 的轻量容器，并非完整 Docker。hermes-agent 官方镜像（hermes/agent:7.24beta3）在 Dockerfile 里做了如下操作：

1
2
3
4
5

RUN ip netns add hermes-app && \
    ip link add veth-hermes-app type veth peer name veth-hermes-host && \
    ip link set veth-hermes-app netns hermes-app && \
    ip netns exec hermes-app ip addr add 10.255.255.2/30 dev veth-hermes-app && \
    ip netns exec hermes-app ip link set veth-hermes-app up

问题：宿主机侧的 veth-hermes-host 虽然被创建，但没有被配置 IP、没有被 up、也没有被加入任何 bridge。这导致即使 App 内配置了 IP，对端也无法回应 ARP 请求。

解决方案

1. 宿主机侧正确配置 veth pair 对端

在 RouterOS App 平台开启后，hermes-agent 启动脚本应补充以下步骤（在宿主机侧执行）：

1
2
3
4

# 宿主机（Linux 侧或通过 WinSCP 上传脚本到 RouterOS /rw/disk/hermes）
ip link set veth-hermes-host up
ip addr add 10.255.255.1/30 dev veth-hermes-host
ip route add 10.255.255.0/30 dev veth-hermes-host

2. 在 netns 内配置默认路由与 DNS

修改 hermes-agent 的启动脚本，加入：

1
2
3
4

ip netns exec hermes-app ip route add default via 10.255.255.1 dev veth-hermes-app
ip netns exec hermes-app mkdir -p /etc/netns/hermes-app
echo "nameserver 223.5.5.5" > /etc/netns/hermes-app/resolv.conf
echo "nameserver 119.29.29.29" >> /etc/netns/hermes-app/resolv.conf

注意：/etc/netns/<nsname>/resolv.conf 是 iproute2 的特殊机制，当执行 ip netns exec <ns> <cmd> 时，iproute2 会自动把该文件 bind mount 到 /etc/resolv.conf。

3. 开启 IP forwarding 与 proxy_arp（关键）

如果宿主机是 Linux，需要：

1
2

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.veth-hermes-host.proxy_arp=1

如果是 Windows Hyper-V，则需要在 vSwitch 属性里允许「MAC 地址欺骗」（MAC Address Spoofing），否则 ARP 请求会被 vSwitch 丢弃。

4. 重启 hermes-agent 并验证 

1

ip netns exec hermes-app /opt/hermes-agent/bin/hermes-agent --config /etc/hermes-agent/config.yaml

日志显示：

1
2

[INFO] Successfully connected to hermes service at 172.16.1.13:28080
[INFO] Agent registered with ID: hyperv-routeros-7.24beta3

宿主机侧 curl http://10.255.255.2:28080/health 返回 200，通信恢复正常。

根因分析

根本原因：RouterOS 7.24beta3 App 平台在创建 netns + veth pair 时，只完成了容器侧的网络配置，宿主机侧的 veth 对端没有被配置 IP、没有被激活、也没有被加入任何 L2 域，导致跨命名空间通信在链路层就失败。

次要原因：

  • hermes-agent 官方镜像未提供 /etc/netns/<ns>/resolv.conf 机制，导致 DNS 在隔离命名空间内完全不可用。
  • 文档示例缺少「宿主机侧配置」与「开启 proxy_arp / IP forwarding」的必要步骤。
  • Hyper-V vSwitch 默认开启了「MAC Address Spoofing 保护」，进一步阻断了 ARP 解析。

预防措施

  1. 脚本化 hermes-agent 部署：将「创建 veth pair → 配置对端 IP → 开启 forwarding → 配置 netns DNS」全部封装成一个 shell 脚本，提交到 RouterOS 的 /rw/disk/hermes/ 目录，由 App 平台启动时自动执行。
  2. 在 RouterOS 里配置静态 ARP：如果无法开启 proxy_arp，可在 RouterOS 里为 veth-hermes-host 配置静态 ARP 条目。
  3. 监控命名空间连通性：在 hermes-agent 启动前，先执行一次 ip netns exec hermes-app ping -c 3 10.255.255.1，失败则直接退出并打印「宿主机侧 veth 未配置」的错误提示。
  4. 版本锁定与回归测试：RouterOS 7.24beta3 仍在快速迭代，建议在生产环境使用前，先在独立 VM 里跑完整回归测试脚本，验证 netns + veth pair 连通性。
  5. 文档反馈：已向 MikroTik 官方论坛提交 issue，建议在 App 平台文档中补充「宿主机侧 veth 配置」与「DNS 配置」章节。

总结

RouterOS 7.24beta3 App 平台为路由器带来了真正的「可编程扩展」能力，但 hermes-agent 与宿主机的通信链路在默认配置下并不完整。核心问题在于 veth pair 的宿主机侧未被正确配置 IP 与路由，且隔离命名空间内的 DNS 解析机制未被正确初始化。

通过手动补充 veth-hermes-host 的 IP 配置、开启 proxy_arp、并在 /etc/netns/hermes-app/resolv.conf 中写入上游 DNS，最终打通了宿主机 ↔ App 容器之间的双向通道。

这个案例再次说明：在引入新平台、新特性时，官方示例往往只覆盖「最简单路径」，生产环境必须做额外的连通性验证与配置补全。对于正在测试 RouterOS 7.24beta3 App 平台的用户，务必在 hermes-agent 部署前，先完成「宿主机侧 veth 配置」这一关键步骤，否则将反复遇到「No route to host」与「DNS resolution failed」。

延伸阅读

© 2020 - 2026 Zero Day Notes
使用 Hugo 构建
主题 Stack 由 Jimmy 设计