跳到正文
文章 · 2026年8月

macOS上无法连接Zerotier网络上的其他设备

0xtiger5 6 分钟阅读

macos·zerotier·网络

问题摘要

Zerotier网络部署后，网段为10.3.242.0/24，所有设备均在线。

执行命令：

Terminal window
/sbin/ping -c 3 10.3.242.173

系统自带 Terminal 可以收到响应，而 iTerm2 返回：

ping: sendto: No route to host
Request timeout for icmp_seq 0

但在 iTerm2 中改用 root 执行又可以成功：

Terminal window
sudo /sbin/ping -c 3 10.3.242.173

问题出在 macOS 的 Local Network Privacy（本地网络隐私）和底层 NECP 网络策略

本案例运行在 macOS 27.0 beta。

问题分析

ping 的错误来自 socket 系统调用返回的 EHOSTUNREACH。传统情况下它确实可能表示没有路由，但 macOS 的网络隐私和 NECP 策略也可能用相同错误拒绝连接。

NECP 的全称是 Network Extension Control Protocol。苹果将其描述为一个控制“哪些程序能够使用哪些网络接口”的网络栈子系统。 它不只服务于 LNP，还参与 Network Extension、Packet Tunnel VPN、App ProxDNS Proxy、按应用 VPN 以及接口作用域和路径选择等等。

例如，一个 VPN Provider 自己连接 VPN 服务器时，NECP 会阻止这条连接再次进入它创建的 VPN 隧道，否则会形成无限回环。 NECP 没有面向普通开发者的完整公开管理 API。它会在日志里表现为：

SO_NECP_ATTRIBUTES
nw_protocol_socket_set_necp_attributes

本案例的系统路由实际存在：

10.3.242/24        link#26            UC      feth1513
10.3.242.158       96:20:8a:6c:7b:cb  UHLWIi  feth1513
10.3.242.173       96:ff:fe:20:a9:46  UHLWIi  feth1513

这些信息说明：

  1. 10.3.242.0/24 有明确的直连路由；
  2. 路由指向正确的 ZeroTier 虚拟以太网接口 feth1513；
  3. 目标 .158 和 .173 的二层邻居地址已经解析；
  4. 同一个目标可以从系统 Terminal 或 root 访问。

macOS 执行本地网络隐私检查时，不只看最终执行文件。例如，iTerm2 启动 zsh，再由 zsh 启动 /sbin/ping，系统会向上追溯发起操作的“负责应用”。

在本案例中：

iTerm2
  -> iTermServer
     -> login
        -> zsh
           -> /sbin/ping

最终负责应用仍可能被识别为 iTerm2，而不是单独的 /sbin/ping。

Apple 官方文档还规定了几个关键例外：

  • 系统自带 Terminal 启动的命令行工具自动允许访问本地网络；
  • 通过 SSH 启动的命令行工具自动允许；
  • root 进程自动允许；
  • 普通第三方 GUI 应用及其子进程需要自己的本地网络授权。

推荐诊断流程

第一步：强制使用同一个可执行文件

在 Terminal 和 iTerm2 中都运行：

Terminal window
/sbin/ping -c 3 10.3.242.173

使用绝对路径可以排除 alias、函数和 PATH 差异。

第二步：在 iTerm2 中进行 root 对照测试

Terminal window
sudo /sbin/ping -c 3 10.3.242.173

判断方式：

  • 普通失败、sudo 成功：优先调查 Local Network Privacy/NECP；
  • 普通和 sudo 都失败：继续调查路由、ZeroTier 服务、邻居解析和防火墙，这不在本篇的范围内；
  • Terminal 和 iTerm2 都成功：故障可能已经被状态刷新消除。

第三步：检查 ZeroTier 接口和路由

Terminal window
ifconfig feth1513
netstat -rn -f inet
arp -an

应确认：

  • feth1513 为 UP、RUNNING、active；
  • 存在 10.3.242.0/24 指向 feth1513 的路由；
  • 目标地址已有 MAC，或在通信后能够解析。

第四步：检查 ZeroTier 服务

Terminal window
sudo zerotier-cli info
sudo zerotier-cli listnetworks
sudo zerotier-cli peers

服务应为 ONLINE，网络状态应为 OK。Peer 使用 DIRECT 还是 RELAY 会影响性能，但通常不会解释“Terminal 成功、iTerm2 失败”。

第五步：确认 iTerm2 会话确实在本机

Terminal window
hostname
tty
ps -p $$ -o pid,ppid,command

用于排除 iTerm2 会话实际位于 SSH、容器或其他宿主环境中的情况。

解决方案

方案一：给 iTerm2 开启本地网络权限

打开：

系统设置 -> 隐私与安全性 -> 本地网络 -> iTerm2

启用后完全退出 iTerm2，再重新打开。仅关闭窗口不一定会退出 iTermServer 等后台进程。

可以先保存正在运行的任务，然后使用菜单中的“退出 iTerm2”。重新打开后再次测试：

Terminal window
/sbin/ping -c 3 10.3.242.173

这是稳定版 macOS 上应优先采用的正常解决方式。

方案二：让系统重新触发授权

短生命周期命令可能在系统显示授权提示前就已经退出。Apple 在 TN3179 中记录了这类问题。因此，可以让测试命令持续运行一段时间，并观察系统是否弹出本地网络授权：

Terminal window
/sbin/ping 10.3.242.173

授权后按 Control-C 停止，再完全退出并重开 iTerm2。

方案三：系统级地址例外

Apple 提供了两个系统级配置项：

  • AllowedEthernetLocalNetworkAddresses
  • AllowedWiFiLocalNetworkAddresses

示例：

Terminal window
sudo defaults write com.apple.network.local-network \
  AllowedEthernetLocalNetworkAddresses -array "10.3.242.0/24"


sudo defaults write com.apple.network.local-network \
  AllowedWiFiLocalNetworkAddresses -array "10.3.242.0/24"


sudo defaults read com.apple.network.local-network
sudo reboot

安全风险：系统级地址例外会让本机所有应用访问指定网段时绕过本地网络隐私检查

回滚配置：

Terminal window
sudo defaults delete com.apple.network.local-network \
  AllowedEthernetLocalNetworkAddresses


sudo defaults delete com.apple.network.local-network \
  AllowedWiFiLocalNetworkAddresses


sudo reboot