路由型还是桥接型 VPN：按客户端要到达什么来选择

同一天来了两张工单：一位用户需要内部网页应用，一位工程师需要让一台台式仪器表现得就像处在同一个以太网段里。两张工单都得到了把它们放进 VPN 的答复，麻烦正是从这里开始的。路由型隧道和桥接型隧道延伸的是不同的关系，每个请求只有其中一种合适。选择拓扑属于访问决策，而不是密码学设置。

在工单台前看起来一样的两个请求

员工的需求是一项服务，可通过 IP 访问，来自你无法控制的设备。工程师的需求在链路层：仪器期望看到以太网帧和广播发现，还可能期待来自它自认为所在网段的 DHCP。

这是不同的问题，而用网桥同时回答两个问题，会毫无理由地把员工的访问范围扩大到整个办公网。

选择之前，把需求写成一句话：哪些目的地、哪些协议、哪些对端必须看起来是本地。如果答案是主机和端口，路由就能覆盖。如果答案是与只讲广播的设备之间的帧级关系，网桥可能是唯一选项。介于两者之间的一切都值得一个测试网段，而不是生产网。

路由比加入局域网更窄

路由客户端会得到隧道子网上的地址，以及你选定前缀的路由。如果策略如此，它只能到达应用服务器，别的什么也到不了。网关成为执行点，前提是每条相关路径都经过它。

不要把路由和权限混为一谈。告诉客户端如何到达某个子网，并不能阻止它尝试别的目的地。

在真正能强制执行流量的位置实施访问控制，并保留应用自身的权限。一条宽泛的转发规则或一个被遗忘的第二接口，可能给出比示意图更多的东西。要读实际生效的规则，而不是设想的规则。然后测试一个应当失败的目的地，因为没人尝试违反过的策略只是一种假设。

网桥改变了准入问题

桥接把物理接口和 TAP 设备组合成软件交换机，于是远程设备加入同一个广播域。这是真实的能力，也是真实的风险：远程设备不再是路由型访客，而是参与者。

决定哪些设备可以加入、哪些帧类型必须通过，以及在哪里阻断不想要的交互。地址分配和 DHCP 权威成为共享网络的一部分，同一网段上的两个 DHCP 服务器会产生你所预料的混乱。

对这台仪器来说，专用测试网段通常比办公网更合适。把管理访问留在实验之外，并规定工作结束后如何移除临时参与者。

两种拓扑里都有过滤

网桥并非天生不可过滤，路由也并非天生安全。Linux 的网桥过滤有自己的钩子和自己的规则语法，为路由型 IP 转发编写的规则不会自动适用于桥接帧。

在承诺边界之前，先确认平台真正支持什么：

bridge link show
nft list ruleset

TUN 和 TAP 描述的是接口的流量，而不是密码。换接口并不能修正其中任何一项：对端认证、被窃取的密钥和过时的密码策略都会在变更之后继续存在。两端仍然需要彼此匹配且仍受支持的设置。

用三次尝试证明边界

验收是三次观察，而不是审查示意图。要求的操作必须成功，无关目的地必须失败，网关自身的管理服务必须保持无法到达。

从同一个客户端运行允许路径和拒绝路径，并记录两者：

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

对于网桥，还要加上链路层检查：允许的发现流量是否通过、地址分配是否来自预定的权威、临时参与者在移除后是否消失。当纯路由 IP 已经满足需求时，加入办公以太网段需要单独的理由，而且应在变更之前写下。