把 OpenVPN 从 TAP 迁移到 TUN：一套可行的迁移顺序

把 dev tap 换成 dev tun，改变的是隧道承载的内容，而不只是名称。TAP 接口把以太网帧交给网桥，客户端因此表现得像接入了办公室交换机。TUN 接口承载 IP 包，客户端需要路由，对端也需要回程路径。客户端、地址规划和 LAN 的回程路由都必须随这次改动一起迁移。

这次迁移是附带隧道的网络重新设计，下面的顺序让它保持可回退。

盘点真正依赖以太网的组件

列应用，而不是列主机。判断每个应用使用的是可路由的 TCP 或 UDP 服务、广播发现、来自办公 LAN 的 DHCP、非 IP 的以太网协议，还是假设两端处于同一子网。普通 IP 访问在可路由设计中依然可用。需要原始以太网帧的协议则不行，再多的路由也无法让它工作。依赖发现的应用需要在切换前确定替代机制，而不是在切换过程中才想。

这份盘点同时也是验收清单。每一个无法迁移的条目，要么成为有记录的例外，要么成为仅为该工作负载保留一小段 TAP 的理由。

制定地址与回程路由方案

选择不与 LAN、旧网桥网段或客户端已能到达的任何网络重叠的客户端前缀。子网拓扑的服务器需要类似 dev tun、topology subnet 和 server 10.78.0.0 255.255.255.0 的片段，但这只是片段，不是可用的配置。在其周围保留已批准的 TLS、身份、传输和访问策略，并使用你已验证为空闲的前缀。

然后写下客户端必须到达的目标，以及由谁提供回程路径。服务器需要开启转发并具备被允许的继续转发路径。LAN 路由器需要通往新前缀的回程路由，否则设计就需要源地址转换，并承担随之而来的可见性代价。推送给客户端的路由配置的是客户端，而不是 LAN 的应答路径。

在独立监听端口上试点

把新服务立在旧服务旁边，使用自己的端口和自己的地址段，而不是替换唯一可用的入口。通过现有的注册流程签发试点配置，这样没有人会为了迁移而重建 CA。在只启用试点路径的情况下接入一个代表性客户端，然后比较分配的地址、私有 DNS、清单中的应用，以及本应保持阻断的路径。

还要包含重连和回程流量测试。握手完成并不能说明对端能否应答。

分组迁移并保留回退方案

按足够小的分组迁移，让失败成为支持任务而不是故障。保持旧服务运行并有文档记录，直到每个分组的真实工作流通过；回退要写成切回上一个配置，而不是重建。随着每个分组迁移，更新基于地址的防火墙规则、监控，以及任何由服务器发起的访问对新前缀的配置。

分组还给你一个地方去发现没人提到的应用，而此时旧路径仍然存在，可用于对比。

验收之后才撤掉网桥

移除 TAP 设备是最后一步，而不是第一步。删除任何东西之前，先检查网桥是否仍承载服务器的管理地址、监控路径或无关的工作负载。按顺序通过各自的负责人撤掉启动依赖、网桥成员关系和 DHCP 保留，并记录移除了什么。

当可路由的访问模型对清单成立时，迁移才算完成，而不是当 TAP 接口从 ip link 的输出中消失时。