OpenVPN 的 TUN 与 TAP：三个决定性问题

两条隧道可以承载同一次文件传输，却在线上所传的内容上截然不同。一条在两个地址之间传输 IP 数据包；另一条传输以太网帧，并且可以桥接进一个网段。正是这一差别决定了哪些应用能用、哪些客户端能连上，以及你要承担多少网络设计。

实践中，三个条件就能定下来。请按顺序检查，因为第一条通常就会结束讨论。

每种接口到底承载什么

TUN 设备是3层点到点接口：内核把 IP 数据包交给它，隧道再把这些包送到对端地址。TAP 设备是2层接口，承载以太网帧，这正是让桥接得以可能的原因，内核文档对此有说明。两者都不改变负载的加密方式，也都不是强度设置。这个选择关乎两端必须交换什么，而不是流量被保护得多好。

一个后果立刻显现：两端必须一致。为一种设备类型配置的客户端，无法加入为另一种配置的服务器，其他方面再吻合也没用。

条件一：是否真的需要二层？

当某个协议确实需要同一个广播域时，桥接才值得这份复杂度：非 IP 流量、无法跨越路由器的发现机制，或坚持要处在同一网段的应用。其余一切都属于路由问题，而路由用少得多的机制就能解决。把一个网段扩展到广域，也会扩展它的广播，于是环路防护、地址规划和故障域都成了设计的一部分。为一个单条路由就能满足的需求付出这些，代价太大。

检验很具体：说出那个在路由型隧道上失败的应用，并说明原因。如果答案是它需要广播，那么二层就是诚实的答案。如果答案是有人连不上某台服务器，那需求就是一条路由或一条防火墙规则。

条件二：客户端支持吗？

支持并不统一。桌面客户端通常两种设备类型都提供，而移动和嵌入式客户端往往只实现路由模式，一个导入时毫无怨言的配置文件，在创建接口时仍可能失败。要检查具体客户端和版本，不要从平台名称推断功能。

“不支持该选项”的报错，不是让你删掉陌生选项直到导入成功的邀请。它意味着配置文件和客户端对“什么是可能的”意见不一致，修复权在签发配置文件的运营方。为了消音而删掉一个选项，可能得到一个看似可用、却悄悄丢掉了它本该提供的属性的连接。

条件三：这真的是接口问题吗？

两个相邻的选项常替接口问题背锅。虚拟设备决定什么进入隧道，而 UDP 还是 TCP 决定外层传输的行为，两者都治不了传输卡住。当大传输卡死而小传输正常时，更该关注的是包大小与 MTU。

连上了却访问不到某一台内网主机的客户端，通常要看路由、防火墙规则，或缺失的回程路径。

托管服务就按运营方配置文件指定的接口方案来做，因为服务端本来就是围绕它搭建的。自建部署则从应用的真实需求出发选择，并把理由写在选择旁边。

问题不是哪个选项更强。而是流量真正需要哪一个。