为什么共享 TAP VPN 仍然需要门户上的 HTTPS
TAP VPN 认证的是对端，而不是它背后的服务。在门户上保留主机名验证，并隔离你不信任的邻居。
两台设备持有有效的 VPN 凭据，并共享同一个桥接以太网段。按理只应由其中一台代表办公门户应答，但另一台仍可在该网段上冒用门户地址。隧道尽到了它的职责：认证了两个对端，并加密了到服务器的每条路径。它没有做到的，是证明二者中谁拥有某个服务名；正是这个缺口，使门户仍然需要一张有效证书。
VPN 实际认证的是什么
VPN 握手只回答一个问题：哪个对端以哪份密钥材料完成了这条隧道。这个答案只针对该对端和该次连接，对之后该对端暴露的服务一无所知。在 TAP 网段上，对端甚至不是单一地址，因为它可以呈现网桥愿意学习的任意 MAC 和任意 IP。认证止于隧道端点，而不触及应用。
把三个问题分开，而不是合并成一个。它们各有各的机制，也各有各的失效方式。
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
一次部署完全可能拥有认证得无可挑剔的隧道，而其背后的服务毫无认证。也可能存在这样的情况：主机上的证书已验证，但它的二层地址正被另一个对端冒用。这正是为什么两种控制都应写入设计，而不是用一种去替代另一种。上面的表格用三行讲完了整个论证。
共享网段上的 ARP 不是目录
ARP 把 IPv4 地址映射到本地链路上的 MAC，并接受该链路上任何人的应答。在宽松的桥接网段里，一个对端可以冒用属于另一台设备的地址，网桥则把帧转发给最近应答的那一方。加密每个客户端到服务器的路径并不能改变这一点，因为帧在到达网桥之前就被解密了。ARP 的信任边界是网段，而不是隧道。
看看主机实际学到了什么：ip neigh show 列出当前的映射及其状态；在正常运行中来回翻转于两个 MAC 地址之间的条目，是值得追查而非忽视的症状。在健康的小型网段里，这类条目会长期保持稳定。
对端隔离和网桥策略正是为这种情况而存在的。当服务只走 IP、设备之间根本没有理由看到彼此帧的时候，路由式设计通常是更好的答案。
把证书验证留在服务所在之处
应用的 TLS 回答了隧道无法回答的问题：这是我要访问的服务吗。浏览器用证书核对主机名，而这项核对是整条链上唯一指向门户而不是对端的一环。
在断定警告只是外观问题之前，先看看服务器到底出示了什么。openssl s_client -connect portal.example.internal:443 -servername portal.example.internal 会打印证书链和主体备用名称。如果你输入的域名不在那份列表里，警告就是对的，需要修的是证书。教会用户点过警告，只会把一个有效的控制变成装饰。
OpenVPN 桥接指南 介绍了以太网模型以及围绕它的策略选项，是判断网段应当允许什么的正确参考。在放宽某条网桥规则之前先读它，因为上文每项检查都以它描述的模型为前提。
决定这些对端究竟该不该共享同一个网段
最省事的修法通常是：当需求只是 IP 可达时，干脆不再共享二层。路由式 VPN 给每个客户端自己的地址，取消共享广播域，并把对端之间的流量变成一项策略决定，而不是默认放行。这样一来，门户只有一个地址需要保护，也没有能冒用它的邻居。
如果网段必须保留，就检查服务器端那个允许客户端互通的设置：grep -n client-to-client /etc/openvpn/server.conf。禁用它时，客户端流量会经过服务器，可以在那里过滤；启用它时，对端直接通过网桥交换帧，你的过滤点就变成网桥和主机防火墙。
写下每台主机实际依赖哪些保护：隧道认证、网段隔离，还是应用 TLS。三者都依赖的主机没问题。只依赖第一项、并假定另外两项随之而来的主机，才是最终提供错误内容的那个。