macOS 上的 OpenVPN TAP：先检查客户端再调试

旧配置落到一台新 Mac 上，客户端照单导入，连接却掉线或始终不通流量。在花一下午折腾证书之前，先读配置里的设备行。如果写的是 dev tap，你就是在向客户端要一个以太网式接口，而在 macOS 上，这类排查大多到此为止。

第 1 步：确认配置确实要求 TAP

配置会被改名、重新打包并再次导出，所以要检查你真正导入的那份文件。查找设备指令以及可能覆盖它的任何 include。多数情况下两行输出就能定论。当 dev 和 dev-type 同时出现时，后出现的指令生效，而这正是复制来的配置容易藏住的细节。

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

如果文件里有 dev tap 或 dev tap0，客户端就必须实现 TAP 接口。如果写的是 dev tun，本文其余内容都不适用，故障在别处。

记下客户端名称与版本、macOS 版本，以及配置的来源。这三项决定下面两条路哪一条才可能走通。

第 2 步：弄清设备模式究竟改变了什么

TUN 接口承载 IP 包。客户端读写发往某个 IP 对端的包，操作系统像对待普通接口一样为其选路。

TAP 接口承载以太网帧，包括广播和 ARP。正因如此，桥接服务器才能通过 DHCP 下发地址，客户端也才能靠广播发现设备，一些老设计因此离不开它。

代价是 TAP 需要驱动把以太网接口呈现给系统。Apple 已弃用旧 Mac TAP 驱动所依赖的内核扩展模式，而替代 API 并不会凭空出现在从未更新过的客户端里。平台具备某项能力，和产品真正交付该能力，是两回事。

第 3 步：在兼容客户端与迁移之间做选择

有两条诚实的路。第一条是发行方明确声明、针对你的 macOS 版本和硬件支持所需 TAP 方案的客户端。不是四年前的论坛帖，也不是归档的安装包，而是当前声明加一次实测连接。

第二条是把服务迁到 TUN，这既是客户端改动，也是服务器改动。它需要路由式拓扑、地址池、为远端网络推送的路由，以及从这些网络返回地址池的通路。

行不通的是在本地副本里把 tap 改成 tun 然后碰运气。服务器仍在桥接，客户端却在说 IP，两边对不上。

第 4 步：改动在用的服务前先收集事实

保持原配置不动，另存一份用于试验。一分钟内能恢复的文件，比整齐的文件夹更有价值。替代方案跑通后，主动删掉副本，而不是在列表里留下两个看起来一样的配置。这个习惯能避免迁移失败后的大部分混乱。把当前行为记录下来，以便证明改了什么：隧道能否建立、能否拿到地址、能否访问一个已知主机、域名解析是否正常。

向网关所有者问三个问题。服务器用的是桥接还是路由式拓扑？哪些远端前缀应当可达？配置变更有没有维护窗口，还是要求不碰服务器就能生效？

这些答案决定了你是在今天下午解决客户端问题，还是在下周规划网络变更。

第 5 步：从两端验证迁移

服务器有了路由式配置、你也有了匹配的配置后，按这个顺序测试：隧道建立、客户端从新地址池拿到地址、远端主机有响应、通过推送的 DNS 设置能解析域名。

然后测试过去依赖以太网行为的部分。如果某个应用靠广播发现设备，走路由式隧道就找不到它们，再怎么改客户端配置也恢复不了。该应用需要已知地址、本地辅助主机，或者别的发现方式。

最后重连一次并重启一次，因为只在第一次尝试时能用的配置，通常意味着推送的路由或 DNS 设置没有在重连时生效。

仍然失败时，先读第一条错误

建不出接口的客户端会在日志里说明，通常在头几行。能建出接口却认证失败的客户端，早已越过设备问题，继续追 TAP 只是浪费这次会话。

在替代方案得到验证之前，保留原配置和可用配置。回滚客户端改动很快；重建被人凭猜测拆掉的桥接网络则不然。